Problem/Motivation

Identified problem detailed in #962664-9: Taxonomy Index for unpublished entities:

It is possible to query by field value in views. One of the drawbacks is, by default, you can only query by TID, not Term Name. Having the values in the taxonomy_index table gets around this issue.

And #962664-47: Taxonomy Index for unpublished entities:

In Drupal prior to 7.x there was an easy way to get all the terms associated with a particular node. In 7.x and beyond, it is very difficult, if not impossible, to get that list of terms. I maintain the tac_lite module, which controls access to nodes based on the terms they are tagged with. Currently there are edge cases where tac_lite cannot learn all the terms a node is tagged with.

And described in #962664-50: Taxonomy Index for unpublished entities:

So a relationship bewteen the contents and taxonomy terms is only recognized within a view, when the contents are published, which looks like a bug to me though. I didn't want my contents to be available as separate pages, but only as the source for the view(s). Since there is the filter criteria "Content: Published (Yes/No)" for views, they seem to be designed to support the output of the not published contents as well, so I think the relations to taxonomy terms should work for such not published contents as well.

Please note that a contrib module was also introduced to fix this in #962664-16: Taxonomy Index for unpublished entities:

I have written http://drupal.org/project/taxonomy_entity_index in the meantime to index all entities regardless of published or not. I've opened an issue to add views integration for it.

Per #962664-27: Taxonomy Index for unpublished entities:

Well, I think leaving out unpublished nodes was a design feature to reduce overhead, since this table can get crazy-big on a large site. Technically you could use the EFQ to look up unpublished nodes by taxonomy--fetch a list of all fields, look for taxonomy fields, look up which bundles have these fields, and loop to query against values in all these fields. But that's kinda wild.

Drupal 7 version of this issue: #2878046: D7 Taxonomy Index for unpublished entities

Steps to reproduce

I believe this edge-case is defined in #962664-50: Taxonomy Index for unpublished entities best:

So a relationship bewteen the contents and taxonomy terms is only recognized within a view, when the contents are published, which looks like a bug to me though. I didn't want my contents to be available as separate pages, but only as the source for the view(s). Since there is the filter criteria "Content: Published (Yes/No)" for views, they seem to be designed to support the output of the not published contents as well, so I think the relations to taxonomy terms should work for such not published contents as well.

Proposed resolution

Proposed change should update the taxonomy index for unpublished entities. Example use case is where editors manipulate the taxonomy terms of unpublished nodes to be used by a view that searches unpublished nodes by taxonomy term name (as opposed to tid, which can be search by taxonomy_field_name_instance).

Remaining tasks

See #962664-179: Taxonomy Index for unpublished entities:

We need to check the views query on taxonomy/term/{term} pages before and after the patch (with a lot of records in the index table), and compare the before/after EXPLAIN.

And per @xjm on Slack:

• the taxonomy API, and Drupal overall, is very, very different than it was when this issue was proposed, so we really need people to think seriously about whether it makes sense anymore

User interface changes

@tbd

API changes

@tbd

Data model changes

Change record as seen in #962664-159: Taxonomy Index for unpublished entities: https://www.drupal.org/node/3133343

Release notes snippet

@tbd

Problem/Motivation

This is the meta-issue for fulfillment of deliverables for the winning "Pitch-Burgh" proposal shown here. It will be updated as subtasks are identified/completed.

Completed tasks

• Get a cache committed to core that can handle redirects: #2551419: Abstract RenderCache into a separate service that is capable of cache redirects in a non-render array-specific way
• Centralize all permission checks in core: #3347873: Centralize permission checks in a service

Remaining tasks

• #3376843: Add the access policy API
• #3376846: Implement the new access policy API
• #3381453: Document the new access policy API

I am using the following ways to access views view row fields inside views-view-unformatted.html.twig

{% for row in rows %}

{{ row.content['#view'].style_plugin.render_tokens[ loop.index0 ]['{{ YOUR_FIELD_NAME }}'] }}

{% endfor %}

or

{% for row in rows %}

{{ row.content['#row']._entity.YOUR_FIELD_NAME[0].value }}

{% endfor %}

I output all my content-type values in the custom template for unformatted.html.twig. Here I have a field for inputting the link to a website and I wanted to get that link only in the A href tag. This is not returning the URL. How can I get the URL value only with out any styling?

Problem/Motivation

By default the entity_autocomplete for user entity works just with usernames. If you look for a user on a such kind of form field, provided results are just the ones that match the name condition.

Anyway, it's even more common that email addresses are used as username, so in my opinion it would be extremely useful to have the mail as a search condition too, available by default.

Steps to reproduce

Look for a user typing its email address on a form field with type "entity_autocomplete" and target_type "user".

Proposed resolution

Update the UserSelection plugin in order to include the user email address as a 'or" condition into the entity query.
Attached the patch with a proposed solution.

Problem/Motivation

When you have a custom field, you might want to index the value column. There are currently several issue that prevents this.

1. If you attempt to modify an existing field config yaml file and run config import, and error is thrown in updateDedicatedTableSchema, because `dropIndex` (and later `addIndex`) is called on the revision table even if the field is not revisionable. This throws an exception.

2. If you attempt to use any of the "extra" field columns, only deleted works properly, as getFieldColumnName usesgetReservedColumns to determine whether to prefix the field name to the column. That function only contains deleted, unlike getExtraColumns, which has entity_id and the other columns.

Steps to reproduce

1. config import the following custom field:

langcode: en
status: true
dependencies:
  module:
    - user
id: user.custom_id
field_name: custom_id
entity_type: user
type: string
settings:
  max_length: 255
  case_sensitive: false
  is_ascii: false
module: core
locked: false
cardinality: 1
translatable: true
indexes: {  }
persist_with_no_fields: false
custom_storage: false

2. Let's add an index, and try running config import again, using the following:

langcode: en
status: true
dependencies:
  module:
    - user
id: user.custom_id
field_name: custom_id
entity_type: user
type: string
settings:
  max_length: 255
  case_sensitive: false
  is_ascii: false
module: core
locked: false
cardinality: 1
translatable: true
indexes:
  custom_id_entity_id:
    - value
    - entity_id
persist_with_no_fields: false
custom_storage: false

Expected result: The index is added to the custom user field table.

Actual result: multiple exceptions are encountered.

Proposed resolution

1. Don't attempt to drop/add indexes on the revision table in updateDedicatedTableSchema if there is no revision table.
2. Don't prepend the field name on any of the "extra" columns.

Language negotiation in core changed from Drupal 9 to 10, breaking things.

I have a piece of code in an openid_connect module to generate an internal URL, like this:

    $language_none = \Drupal::languageManager()
      ->getLanguage(LanguageInterface::LANGCODE_NOT_APPLICABLE);

    $redirect_uri = Url::fromRoute(
      'openid_connect.redirect_controller_redirect',
      [
        'openid_connect_client' => $this->getPluginId(),
      ],
      [
        'absolute' => TRUE,
        'language' => $language_none,
      ]
    )->toString(TRUE);

Which in Drupal 9 generated something as "https://mysite.com/openid_connect/acm-idm". I have language negotiation active, but the LanguageInterface::LANGCODE_NOT_APPLICABLE killed the language prefix.

I updated to Drupal 10 and then the behaviour changes: I get as output "https://mysite.com/nl/openid_connect/acm-idm" (note the "nl" prefix).

Looking at the code I end up in "Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUrl.php" in function "processOutbound":

In Drupal 10 there's code in there like this:

    if (!isset($options['language']) || ($options['language'] instanceof LanguageInterface && in_array($options['language']->getId(), [
      LanguageInterface::LANGCODE_NOT_SPECIFIED,
      LanguageInterface::LANGCODE_NOT_APPLICABLE,
    ]))) {
      $language_url = $this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_URL);
      $options['language'] = $language_url;
    }

In Drupal 9 the in_array() part above is not present.

If the language option I set is "LanguageInterface::LANGCODE_NOT_APPLICABLE" I do not want the language prefix to be added. If the LanguageInterface::LANGCODE_NOT_APPLICABLE is removed from the array above all is ok again.

Part of #3371246: [Meta, Plan] Pitch-Burgh: Policy based access in core

Summary

We want to convert the Flexible Permissions module into core code. This will allow for any access policy to be translated into a set of permissions so that access checks can run. These permissions are calculated once during a build phase and then pulled through an alter phase. After both phases are complete, the end result is poured into an immutable value object and cached.

This value object can then be used by a permission checker (such as the one introduced here #3347873: Centralize permission checks in a service) to verify if an account has permission to a given access check.

A key aspect that may not seem useful to core is the use of scopes. By default, all access policies will return permissions for the "drupal" scope, but to make it so access modules in contrib don't have to copy all of this logic, the use of scopes will allow them to define permissions in other scopes, such as Group, Domain, Commerce Stores, etc. where the calculated permissions will only have effect within the scope of, say, one domain or group.

Overview of new API

New concept: Build and alter phase

The goal is to loop over all access policies in a build phase and come up with a set of permissions that are from then on immutable. These permissions respect cache contexts (and are thus added to the variation cache), so you could be getting a different set depending on the time of day, your user roles, etc. The reason the permissions have to be immutable is because we still cache everything by user.permissions and if your permissions could change during runtime, that would quickly become a security nightmare.

Right before we turn the built permissions into this immutable object, however, we allow all policies to have a final alter pass of the fully built permissions. This adds some extra flexibility for people who want to alter other modules' (or core's) access policy behavior from the outside. After the alter pass, the immutable object is built and cached.

New concept: Scopes and identifiers

Furthermore, these permissions are built for a given scope and identifier within said scope. For Drupal core, both of these simply default to AccessPolicyInterface::SCOPE_DRUPAL and seemingly do nothing, but it's contrib where the addition of this concept will truly shine. You see, for Group, Domain, or similar we don't necessarily care about what permissions you have across the entire website, but rather what you can do within a subset, e.g. a single domain.

The main question then becomes "To what do these permissions apply?" Because Group is a bit complex to explain here (it has 3 scopes), let's use Domain as an example: If you want to discern who can make changes to content on an individual domain (whether active or not), then you would hand out those permissions in SCOPE_DOMAIN, where the identifier is the machine name of the domain. Doing this would for example allow the "Belgian team" to change the content of the ".be" website, but not the ".nl".

AccessPolicyProcessor and VariationCache

This is where the AccessPolicyProcessor (APP) and VariationCache (part of core) come into play. The APP is a service collector that looks for services which are tagged as access_policy. It then asks all of these policies what they initially vary by (i.e. cache contexts) and evaluates what they end up varying by at the end of the permission processing. This concept of "initial cache contexts" and "final cache contexts" is what powers cache redirects and is required to store something in the variation cache.

Before any of this runs, however, it first asks each individual access policy whether it applies to the scope and does not do anything with those that don't. So any Group or Domain specific access policies will not interfere with your sitewide Drupal permissions or vice versa.

(Refinable)CalculatedPermissions and CalculatedPermissionsItem

These value objects simply represent all of what was described above. The CalculatedPermissions object holds entries for an infinite amount of identifiers across an infinite amount of scopes. Keep in mind: In case of Drupal core it would be one scope and one identifier.

At each scope-identifier address sits a CalculatedPermissionsItem that indicates what permissions you should get for a given identifier within a scope and whether or not you have admin rights (i.e. all permissions) there. If you try to add multiple CPI to the same address, they get merged or overwritten depending on a parameter in the RefinableCalculatedPermissions::addItem() method.

Which leads to the next point: The difference between RefinableCalculatedPermissions and CalculatedPermissions. Simply put, the former allows you to make changes and is passed around during the build phase, the latter is immutable and passed around to those services who request what your fully built permissions are.

Permission checkers

This is not part of the new API but I'll explain it here rather than the implementation issue. How do you use these built permissions? Well, you use a central permission checker such as the one introduced in #3347873: Centralize permission checks in a service and call the AccessPolicyProcessor. Then you ask for the permission item at the scope-identifier (SCOPE_DRUPAL/SCOPE_DRUPAL for core) address you seek and simply run hasPermission() on it.

Here's what that would look like (taken from the implementation issue):

  /**
   * {@inheritdoc}
   */
  public function hasPermission(string $permission, AccountInterface $account): bool {
    $item = $this->processor->processAccessPolicies($account)->getItem();
    return $item && $item->hasPermission($permission);
  }

Sane defaults

See anything missing in the example above? We didn't have to specify AccessPolicyInterface::SCOPE_DRUPAL anywhere because the system defaults to the drupal scope and identifier. Contrib scopes would have to specify these parameters in the processAccessPolicies() and getItem() call.

To make life easier on people wanting to add an access policy to core from within a contrib module (such as office hours), CalculatedPermissionsItem also defaults to adding permissions to the SCOPE_DRUPAL/SCOPE_DRUPAL address. This should make access policies aimed at core easier on the eyes.

Here's what that would look like (taken from the implementation issue):

    foreach ($user_roles as $user_role) {
      $calculated_permissions
        ->addItem(new CalculatedPermissionsItem($user_role->getPermissions(), $user_role->isAdmin()))
        ->addCacheableDependency($user_role);
    }

Problem/Motivation

Follow up issue for #2904899: Invalid argument exception when changing language of node with menu link to und or zxx, originally proposed there in comment #7 by @esolitos

In certain cases you need to check, if a language is a pseudo language (i.e. und or zxx). This is quite complicated:

if (!in_array($node->language()->getId(), [LanguageInterface::LANGCODE_NOT_APPLICABLE, LanguageInterface::LANGCODE_NOT_SPECIFIED], TRUE)) {
  // do something
}

For better DX, we should add a method to Drupal\Core\Language\LanguageInterface to simplify this check:

if (!$node->language()->newMethod()) {
  // do something
}

Steps to reproduce

n/a

Proposed resolution

tbd

Remaining tasks

1. Decide on good method name.
2. Implement changes to the interface.
3. Write change record.

User interface changes

None.

API changes

New method to check, if a language is a pseudo language.

Data model changes

None.

Release notes snippet

tbd

Hi

I face following problem: I have a site with two languages.

I have a page "frontpage" (set as standard front page) i can call correct with "mysite.tld/frontpage" and "mysite.tld/en/frontpage". The language switcher handles the links ok. So that works.

But when i klick the "Home" link, either in the branding block or the main menu or from admin_toolbar, all urls with a prefix like "mysite.tld/en/" end up on a white page reading "Forbidden. You don't have permission to access this resource."

It does not matter what settings i change (e.g. different front page), these links are always end up "forbidden".

Any tipp what this can cause and what to do? I tried this in a clean fresh set up, no other modules enabled…

Thanks!

Problem/Motivation

Drupal's "File Size" views formatter (\Drupal\file\Plugin\Field\FieldFormatter\FileSize) has a hardcoded behaviour that it can only display field definition where the field name is "filesize". This obstructs the formatter being used for file size fields attached to a Media object definition.

This is important for media metadata extraction, see #2928798: Add extractors: mimetype & filesize. It also permits this useful formatter being used in other contexts where there is a bytesize measurement stored in a Drupal field.

Steps to reproduce

• Create a new Drupal 9.3.x site
• Enable Media, Media Library
• At /admin/structure/media/manage/image/fields/add-field configure a field for storage of filesize. The name isn't significant; the default machine name will be prefixed with field_ which is sufficient to demonstrate this issue.
• At /admin/structure/media/manage/image under Field Mapping, map "File size" to your new field then press Save.
• At /admin/content/media/image add a new image. Do not input a value to the filesize field.
• Post-upload, you should see your image listed at /admin/content/media. Click back to the image to verify that the filesize field was correctly populated by Media.
• At /admin/structure/views/view/media/edit/media_page_list add a Field to the view to display the file size field.
• On "Configure field: Media: ", select "File size" for "Formatter"
• The Views UI behaves inconsistently at this point. While it will preserve the value of Formatter selection, Formatter settings will not be preserved; if you change "Thousand marker" to "comma", it will be "- None -" when revisisted. (NB: Thousand marker is likely only visible if the underlying storage is numeric.)
• The view will continue to display the filesize value as though the Formatter was set to "Unformatted"; no file size formatting is applied.

Proposed resolution

Allow this formatter for all fields of type "integer". The integer constraint is applied via existing annotation.

Remaining tasks

- Review
- Merge!

User interface changes

1. The "File size" formatter will be re-labelled "Byte size" to consider other usages (eg fields representing length of an encoded value, or amount of data consumed in downloads)
2. "Byte size" formatter will become available for fields of type "integer".

API changes

None

Data model changes

None

Problem/Motivation

On an existing site with content translation and content moderation (mandatory), if you change an existing field to required then you can no longer update your existing translations.

Steps to reproduce

1. On a translatable content-type add a 'Test date' date field that is not translatable and not required
2. Create a node, translate that node
3. Edit the "Test date" field configuration and set the field to required
4. Edit your translated node and hit save

The save will be blocked with a message that the "Test date" field is required even though it is not shown on the form. I have also tested the on EntityReference fields and they are also affected by the problem.

If you update your default language and populate the required date field then the translation can be updated. However, in the case of an entity reference you are not so lucky as it will WSOD with:
InvalidArgumentException: Value is not a valid entity. in Drupal\Core\Entity\Plugin\DataType\EntityReference->setValue() (line 106 of core/lib/Drupal/Core/Entity/Plugin/DataType/EntityReference.php).

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When I have a tag in ckeditor5, the editor breaks and 'Source' button doesn't work anymore.
It is reproducible in demo as well https://ckeditor.com/ckeditor-5/demo/html-support/
Enter following code in source editing mode and see if you can toggle source button anymore.
<template id"test"><h1>Hi</h1></template>

Steps to reproduce

1. Edit a content that has ckeditor5 editor
2. Enable source editing mode.
3. Enter html code with tag.
4. Disable source editing mode and enable again.
5. You can see console error throwing.

Problem/Motivation

When creating a node, you can choose to provide a menu link. It would be nice to have the option to provide a menu link when creating a node by default if desired.

Proposed resolution

I propose adding a checkbox under Menu settings when editing a Content type, which would control if a menu link is automatically provided when creating a node of that content type.

Problem/Motivation

Split from #3238652: [policy] Decide how long major Drupal versions should be supported since we have just agreed to this at the core committer offsite. The issue summary on #3238652: [policy] Decide how long major Drupal versions should be supported will be reworked to reflect the remaining decisions to be made. If you have strong concerns about this issue, please read the other two issues first where those concerns are likely to have already been raised and discussed in depth.

Symfony is our biggest overall dependency, with the most predictable release cycle. Major releases come out every two years in November, followed by three minor releases, with a total support cycle of six years.

i.e. Symfony 6.0, November 2021
Symfony 6.4, and 7.0 November 2023
Symfony 6.4 EOL, November 2027

We released Drupal 10 in 2022 with three possible windows, June, September, December.

This allowed us to get onto Symfony 6 within a year of Symfony 6.0 (but also at least six months after its release), to have a theoretical maximum support timeline of 5.5 years. It also allowed us to require PHP 8.1 6-12 months after its release.

Other dependencies do not have as predictable release cycles, but a two year cycle for core gives us more options than, for example, a four year release cycle and skipping a Symfony release each major as were discussed as options on previous issues.

Proposed resolution

Amend https://www.drupal.org/about/core/policies/core-release-cycles/schedule to something like this:

From Drupal 10 onwards, major releases are scheduled every two years.

Each major release has three possible windows, in June, September and December, to allow for some flexibility with Drupal core's dependencies.

Drupal 10 - June/September/December 2022

Drupal 11 - June/September/December 2024

Drupal 12 - June/September/December 2026

etc.

Remaining tasks

Exactly how long to then support each major release for is discussed in #3238652: [policy] Decide how long major Drupal versions should be supported and is out of scope of this issue.

Problem/Motivation

I've downaloaded a new module and want to enable it, but get fatal error. I've tried to enable several different modules and every time get this error:

$ drush en honeypot 
>  [notice] Checked fr translation for honeypot.
>  [notice] Checked nl translation for honeypot.
>  [error]  The specified file 'temporary://fileie34b1' could not be copied because the destination directory 'translations://' is not properly configured. This may be caused by a problem with file or directory permissions. 
>  [error]  Unable to download translation file https://ftp.drupal.org/files/translations/all/honeypot/honeypot-2.1.1.fr.po. 
>  [warning] fopen(translations://honeypot-2.1.1.fr.po): Failed to open stream: "Drupal\locale\StreamWrapper\TranslationsStream::stream_open" call failed PoStreamReader.php:154
>  [error]  TypeError: fgets(): Argument #1 ($stream) must be of type resource, bool given in fgets() (line 248 of /app/docroot/core/lib/Drupal/Component/Gettext/PoStreamReader.php) #0 /app/docroot/core/lib/Drupal/Component/Gettext/PoStreamReader.php(248): fgets(false)
> #1 /app/docroot/core/lib/Drupal/Component/Gettext/PoStreamReader.php(186): Drupal\Component\Gettext\PoStreamReader->readLine()
> #2 /app/docroot/core/lib/Drupal/Component/Gettext/PoStreamReader.php(217): Drupal\Component\Gettext\PoStreamReader->readItem()
> #3 /app/docroot/core/lib/Drupal/Component/Gettext/PoStreamReader.php(155): Drupal\Component\Gettext\PoStreamReader->readHeader()
> #4 /app/docroot/core/modules/locale/src/Gettext.php(56): Drupal\Component\Gettext\PoStreamReader->open()
> #5 /app/docroot/core/modules/locale/locale.bulk.inc(213): Drupal\locale\Gettext::fileToDatabase(Object(stdClass), Array)
> #6 /app/docroot/core/modules/locale/locale.batch.inc(191): locale_translate_batch_import(Object(stdClass), Array, Object(DrushBatchContext))
> #7 /app/vendor/drush/drush/includes/batch.inc(261): locale_translation_batch_fetch_import('honeypot', 'fr', Array, Object(DrushBatchContext))
> #8 /app/vendor/drush/drush/includes/batch.inc(206): _drush_batch_worker()
> #9 /app/vendor/drush/drush/includes/batch.inc(100): _drush_batch_command('414')
> #10 /app/vendor/drush/drush/src/Drupal/Commands/core/BatchCommands.php(22): drush_batch_command('414')
> #11 [internal function]: Drush\Drupal\Commands\core\BatchCommands->process('414', Array)
> #12 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
> #13 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #14 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #15 /app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(350): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #16 /app/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #17 /app/vendor/symfony/console/Application.php(1027): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #18 /app/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #19 /app/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #20 /app/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #21 /app/vendor/drush/drush/src/Runtime/Runtime.php(48): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
> #22 /app/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
> #23 /app/vendor/drush/drush/drush(4): require('/app/vendor/dru...')
> #24 /app/vendor/bin/drush(120): include('/app/vendor/dru...')
> #25 {main}. 

Steps to reproduce

1. You should have a multilingual site.
2. Add a new module, e.g: composer install drupal/honeypot.
3. Enable it: drush en honeypot.

Expected result: module is successfully enabled, no errors.

Actual result: module is enabled, but there was a php error on translations import during module install.

Proposed resolution

After some investigation it turned out that we can modify just 1 line in PoStreamReader::readLine() to fix the issue, see a patch below.

Failing database updates after upgrading from 10.0.10 to 10.1.1

system_post_update_timestamp_formatter() will exit with an error in some circumstances, most commonly when the configuration references a plugin which is not available.

After upgrading from 10.0.10 to 10.1.1 try to run database updates

Profile used: minimal
drush updatedb -y error details
[notice] Update started: system_post_update_timestamp_formatter
[error] Update aborted by: system_post_update_timestamp_formatter
[error] Finished performing updates.

Problem/Motivation

This issue is a follow up for #3372316: Adjust design implementation for the field types to replace usages of CSS variables from Claro in modules/field_ui/css

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce

• Enable more than two languages
• Create a revision based view
• Create a revision back to the view
• Add the "content revision: title" field
• You end up a with a SQL error

Proposed resolution

Problem

• \Drupal\views\Entity\Render\TranslationLanguageRenderer::query calls to $storage->getTableMapping()->getFieldTableName($langcode_key) which at the moment returns the normal data table for revision views, so later views cannot find the right join, as the relationship defined above is explicit.
• The solution is to make getFieldName revision aware as pass along whether we want to get revisions or not.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The comment.type.comment.yml config which is shipped with the standard profile has an undeclared dependency on its target entity type..

How to reproduce

1. Install Drupal with the Standard profile.
2. Head over to /admin/modules/uninstall.
3. Uninstall the History and Taxonomy modules.
4. Uninstall the Node module.
5. Visit /admin/structure/comment/manage/comment/delete.

You should see PluginNotFoundException: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "node" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition()

Proposed resolution

Add dependencies from the comment field and the target entity type.

Remaining tasks

1. Update tests
2. Patch.

User interface changes

User is expected to see dependency information when attempting to delete.

API changes

Nil

Data model changes

Nil