Problem/Motivation

It is not possible to navigate to level 1 menu items (secondary items) if they have children (level 1 is referring to the code level which is 0 indexed, 0 being the top level). The user must navigate to the level 2 menu item first (tertiary item) then back up a level via the breadcrumb.

Examples

Contrib: Simple Blocks
The Simple Blocks menu item is a child of Structure > Block Layout. Thus the Block Layout page can't be reached anymore!

Contrib: Paragraphs
Paragraphs module adds the menu items Structure > Paragraphs > Add paragraph type, where the menu item Paragraphs leads to the paragraphs overview page which now can't be reached anymore.

Steps to reproduce

1. Install drupal 11.x (via simplytestme)
2. Login as admin
3. Enable navigation
4. Try to click on Structure > Display modes, which does not bring you to its menu item link /admin/structure/display-modes

Proposed resolution

When a secondary menu link has children, the child list of menu links should be preceded by an "Overview" link. The "Overview" link should link the user to the secondary menu link. The rest of the secondary menu links' children are listed below the "Overview" link.

Figma: https://www.figma.com/design/VCPAxetieAC2pzw7hgX3ij/Drupal-Admin-UI---De...

Note that the word "Overview" is still under consideration. Looking to resolve that before we finish up here. Other candidates currently include "See All".

Also, keep in mind that it's likely we'll add support for a fourth level of links. That is the subject of #3425084: Support Deeper Navigation Levels. It's equally likely that the "Overview" link implemented here for the second level, will carry forward to the tertiary level if applicable as well.

Remaining tasks

• ☐ Decide on UX alternatives to "Overview", or settle on it Add overview as per "User Interface Changes" below. Anything else via follow-ups to not let perfect be the enemy of good here.
• ☑ Implement the approach shown in the above screenshot as well as the Figma.

Outstanding Merge Requests

MR 10900 implements the Overview links with additions to the render array returned by the build() method in NavigationMenuLinkTree. This MR needs test coverage.

MR 12148 implements the Overview links with a new menu manipulators service NavigationMenuLinkTreeManipulators in the navigation menu. Adding the links with a menu manipulator provides additional options to contrib and custom modules that may want to alter the overview links, either by:

• decorating the manipulator service or altering the service in a service provider
• implementing hook_navigation_menu_link_tree_alter()
• implementing hook_block_view_alter() or its variants

MR 12148 has unit test coverage for the manipulator service and kernel test coverage for the navigation menu block output, though if the approach in MR 10900 is preferred, presumably the kernel test coverage can be ported there.

Neither MR currently seems to support the addition of overview links at a third level (or beyond), which would need to be a consideration for #3425084: Support Deeper Navigation Levels, depending on which issue moves forward first.

User interface changes

When secondary menu items have children, precede the child menu list by an "Overview" link that take the user to the second level menu link.

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Users can now directly navigate to secondary menu items directly from the navigation.

Problem/Motivation

I get the following error when I try to add default values to a multi-value formatted text field:

Error: Cannot use object of type Drupal\Core\StringTranslation\TranslatableMarkup as array in Drupal\text\Plugin\Field\FieldType\TextFieldItemList->defaultValuesFormValidate() (line 24 of /app/web/core/modules/text/src/Plugin/Field/FieldType/TextFieldItemList.php).

The "add_more" button is handled as a submitted value and that is causing an error in the allowed_formats check.

Steps to reproduce

1. Add a formatted text field to a node type
2. Select "Text (formatted)" as the field type
3. Make sure at least one format is selected in the "Allowed formats" list
4. Click the "Add item" button to add another default value

Proposed resolution

Check if the value "add_more" is set and remove it if so.

Problem/Motivation

If for some reason, the notifications.email value is a string, it will produce an error on the update settings page.

Steps to reproduce

1. drush -y cex
2. Edit update.settings.yml and change notifications.email to a string. It is an array after a fresh install of Standard
3. drush -y cim
4. Go to admin/reports/updates/settings

The website encountered an unexpected error. Please try again later.
TypeError: implode(): Argument #1 ($pieces) must be of type array, string given in implode() (line 92 of core/modules/update/src/UpdateSettingsForm.php).
implode('', NULL) (Line: 92)
Drupal\update\UpdateSettingsForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 534)
Drupal\Core\Form\FormBuilder->retrieveForm('update_settings', Object) (Line: 281)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 68)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 49)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Proposed resolution

Change

  #default_value' => implode("\n", $notification_emails)

for

'#default_value' => is_array($notification_emails) ? implode("\n", $notification_emails) : $notification_emails,

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Also bumped into a similar issue as it was reported at #3525727: Recipe Composer plugin: support wikimedia/composer-merge-plugin and the Composer root package and composer.json match did not really helped with understanding what is going on. I would suggest improving the output when the assert fails and providing detail on what was the unexpected state.

Steps to reproduce

Proposed resolution

Instead of:

In RootComposer.php line 142:

  [AssertionError (1)]
  Composer root package and composer.json match

Display:

In RootComposer.php line 144:
                                                                                       
  [AssertionError (1)]                                                                 
  Composer root package and composer.json missmatch detected.                          
  require: drupal/better_exposed_filters requires leongersen/nouislider (== 15.5.1.0)  
  require-dev: OK                                                                      
                                                                                      

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

In system_theme_suggestions_maintenance_page(), a template suggestion is provided for maintenance-page--offline.html.twig:

if ($offline) {
  $suggestions[] = 'maintenance_page__offline';
}

However, this template is not picked up when the system is offline. This results in a generic, unstyled exception page (i.e. a WSOD), creating a poor user experience. This is functionality that did exist and work in Drupal 7, and an attempt was made to have this functionality ported to Drupal 8, but appears to not have been completed/successful.

This is a major issue because it has no workaround and is a regression from Drupal 7.

Cause a significant admin- or developer-facing bug with no workaround.

Steps to reproduce

Scenario A (when core/includes/errors.inc is used):

1. Set correct database credentials in settings.php
2. Clear cache: drush cr
3. Set $config['system.logging']['error_level'] = 'hide' in settings.php
4. Set $settings['maintenance_theme'] = 'bartik' in settings.php
5. Set incorrect database credentials in settings.php (for example invalid username)
6. Refresh the page.
7. There is a plain text message: "The website encountered an unexpected error. Please try again later."

Scenario B (when \Drupal\Core\EventSubscriber\FinalExceptionSubscriber is used):

1. Make sure that $settings['hash_salt'] in set in settings.php
2. Clear cache: drush cr
3. Set $config['system.logging']['error_level'] = 'hide' in settings.php
4. Set $settings['maintenance_theme'] = 'bartik' in settings.php
5. Comment out $settings['hash_salt'] in settings file
6. Refresh the page.
7. There is a plain text message: "The website encountered an unexpected error. Please try again later."

Proposed resolution

Adds a way to render a template when in a fatal error context first by trying to get the maintenance theme in settings and then by the slower extension discovery if the that fails. Finally it falls back to a WSOD like fatal message.

Scenario A is addressed by calling the new static method in errors.inc.
Scenario B is addressed by calling the new static method in FinalExceptionSubscriber.

These scenarios are addressed in a new browser test.

Remaining tasks

• Manually test the merge request
• Review the merge request

User interface changes

Fatal errors will be attempted to be rendered using the maintenance theme "offline" template. This would cause previously displaying a WSOD to potentially show a themed page instead.

API changes

• New public method Drupal\Core\Utility\Error::renderFatalError

Data model changes

N/A

Release notes snippet

This is a patch (bugfix) for a regression due to incomplete porting of functionality from Drupal 7 to Drupal 8 (and now Drupal 9). Drupal 7 allowed for the implementation of maintenance-page--offline.tpl.php, a template that to be shown when the site was offline and unable to connect to the database. The porting of this functionality to Drupal 8 and 9 was incomplete, and the equivalent Twig template, maintenance-page--ofline.html.twig, was not picked up, resulting in a generic, unstyled exception page (i.e. a WSOD) with a poor user experience. This but has now been fixed, and site themers can implement maintenance-page--ofline.html.twig on Drupal 8 and 9 sites.

Who this affects

This bugfix affects Drupal theme developers. Theme developers will now be able to create a template page to be displayed when Drupal is unable to reach the database, providing an improved user experience.

How to Implement

1. Copy core/modules/system/templates/maintenance-page.html.twig to the theme to be used when your site is offline.
2. (Optional) Edit the template to provide the HTML you would like visitors to see when the site is offline
3. Edit settings.php, uncomment the line $settings['maintenance_theme'] = 'bartik';, and change the value from bartik to the machine name of the theme you chose in step one above.
4. Clear your registry

How to test the template

After performing the steps above, the way to test that the template is working is to force a fatal error on your site. Warning: it is strongly advised to not test this on a production server. Fatal errors can be forced as follows:

1. Set $config['system.logging']['error_level'] = 'hide'; in settings.php
2. Set incorrect database credentials in settings.php (for example invalid username)
3. Refresh the page
4. Confirm that the template has been picked up

Problem/Motivation

While creating a view, user requested to see all records on 1 page. The previous pager setting was 'Display a specified number of items" and a value of 10.

I left the pager type as it was and set the pager value to '0' (which Views field Items Per Page 'help' text suggests). The result on the views screen says "Display a specific number of items | 0 items". I completely understand why and how but for human readability it is nonsensical. When the value is '0' this should exception to 'All' items.

Steps to reproduce

Create a view.
Set Pager to : Use Pager: Display a specified number of items. Accept the defaults (10 items with skip of 0).
From view click on the pager '10 items' hyperlink and set the value to 0.

Proposed resolution

If the user sets the pager type to "Display number of items" and

1. offset is set to 0, the number items is set to 0, display text string 'All' instead of numeric 0.
2. offset is set to 0, the number items is set is not 0, display text string 'All items except first @offset'.

For all the other combinations, the display text on the pager option link remains unchanged.
This does not change the existing logic and behaviour of the pagination which and also clears the confusion about the behaviour.

Remaining tasks

See the tags and the MR
Followup for #24

User interface changes

Before

After

API changes

Data model changes

Release notes snippet

Problem/Motivation

After digging deeper into the form api, I found out that it might be possible to simplify some form handling.

Proposed resolution

The new approach improves form handling by:

Reducing form rebuilding overhead
Better preserving user input during form interactions
Improves reliability when handling errors after drag-and-drop operations
Aligns with Drupal's standard form API patterns for weight handling

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Package Manager has fixed its two outstanding beta blockers as a core module. It was committed with alpha stability a while ago, but has been kept in core's code base as a one-time exception to normal policy because it was necessary in order to test updating core using the Automatic Updates module (which relies on Package Manager).

Although Package Manager has quite a few stable blockers and needs triage, its API can now be considered stable. No changes are needed to the module itself in order to mark it as beta.

Release notes snippet

Package Manager is now a beta module in Drupal core. It doesn't do anything on its own, but provides the foundational APIs used by Project Browser and Automatic Updates. Those APIs are stable and will be backwards-compatible, so it is now considered safe to rely on this module and build other projects on top of it.

Background information

This was originally logged as a private issue to the security team, but was cleared to be moved to the public queue

• security.drupal.org private issue: https://security.drupal.org/node/182951
  (included for reference. Please do not report access denied as an error.)

Problem/Motivation

The unserialize() function should never be used without specifying allowed classes.

Proposed resolution

Remaining tasks

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

N/A

Problem/Motivation

There was a failure when converting install time hooks so I moved converting that to this issue.

Steps to reproduce

Convert experimental_module_requirements_test_requirements to InstallRequirements.php

Proposed resolution

Convert this as install time only
This is only tested in core/modules/system/tests/src/Functional/Module/NonStableModulesTest.php so there is no need to run this check in runtime or update.

Remaining tasks

Should we remove the state change, I think that was due to another test that this module is no longer used in.
This test is marked as experimental, but it literally only tests that it cannot be installed with the requirements error, we have other test coverage, should this be changed to actually test something to do with experimental.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

If you do a config import which removes a bundle, such as a vocabulary entity or a node type, and entities of that bundle exist, the import fails with this message:

> Entities exist of type %entity_type and %bundle_label %bundle. These entities need to be deleted before importing.

This is confusing because 'importing' refers to the whole import process, but what's actually causing this problem is an attempt to *delete* something.

Steps to reproduce

Proposed resolution

Make the message clearer about what's going on - the config import is trying to delete the bundle %bundle.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow on from #3379794: Add symfony mailer transports to Dependency Injection Container (mail delivery layer). The original issue added the 4 base transports by creating explicit services. Sites that wish to use other transports would need to add extra services. Likely there will be Contrib modules to help with that, however it's awkward because creating the service will fail if the transport isn't installed, and each site will have a different set of transports. For example we could have a sub-module for each transport, containing only a single service definition.

Symfony is aware of a further 14 (at time of writing) 3rd-party transports. These can be accessed using the function Transport::getDefaultFactories(), which returns only the transports that are installed.

Proposed resolution

We can automatically create services for these 3rd-party transports if a service doesn't already exist. This is simple because they all follow exactly the same template like this.

  Symfony\Component\Mailer\Transport\NullTransportFactory:
    parent: Symfony\Component\Mailer\Transport\AbstractTransportFactory
    tags:
      - { name: mailer.transport_factory }

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Deleting a checkpoint deletes all checkpoints up to the checkpoint asked to be deleted.
But checkpoints have a reference to their parent and when checkpoints are deleted the now oldest checkpoint has its parent still set to the deleted one instead of null.
This creates a whole bunch of problems, for example one can not get parents and thus also not add a new checkpoint to the storage.

Steps to reproduce

create more than one checkpoint, delete any except the current one. Try to add a new checkpoint or get parents.

Proposed resolution

fix the delete method

Remaining tasks

write patch

User interface changes

none

Introduced terminology

none

API changes

none

Data model changes

none

Release notes snippet

-

Problem/Motivation

The current implementation of ChainedFastBackend and DatabaseCacheTagsChecksum are not efficient when dealing with changes - writes to the cache backends.

- DatabaseCacheTagsChecksum heavily relies on the database to do validate cache item checksum so ChainedFastBackend is completely avoiding the use of tags on the fastBackend.

- ChainedFastBackend is invalidating the complete fastBackend on every cache write - both for the current head and other heads.

This implementation behaviour is penalizing applications where data changes a lot. ChainedFastBackend even had to be disabled during the install process where cache writes happen all the time. We don't won't a Drupal that will only work for read-only applications.

Proposed resolution

- Create a new Cache API (CacheRawBackend) that is simpler, faster and lighter than the current one. This new API saves data as-is in the storage backend so that it can leverage native funcionalities such as counter() (apc_inc for example) and touch(). This new Cache API is not tag aware.

- Create a new ChainedFastBackend (ChainedRawFastBackend) on top of the new Cache API. The old implementation of ChainedFastBackend cannot be used on the new Cache API because this new API is not able to store cache metadata such as the created timestamp, so it needs a new invalidation strategy. As the new Cache API, the new ChainedRawFastBackend is not tag aware.

- Implement an alternative to DatabaseCacheTagsChecksum that is built on top of the new ChainedRawFastBackend.

- Improve the current ChainedFastBackend to not invalidate the fastBackend for it's own webhead. It should only invalidate the fastBackend for other heads/processes.

- Bring back the usage of tags for the fastCache backend in ChainedFastBackend. This is needed to prevent the complete invalidation of the fastBackend when something changes. It should not be a problem now that cache tags are backed by a fast in-memory storage backend.

- Bring back ChainedFastBackend during the install process. It should actually be faster than not using ChainedFastBackend at all.

Remaining tasks

Profile before doing any further work and decide if it is worth the effort
Review all the code. I've already spoted some bugs in it
Write test coverage - lots of them

User interface changes

None

API changes

No API changes, only new APIs and changes in implementation details.

Data model changes

None.

Problem/Motivation

Always had issues with Views aggregation; but this is a new one.

This is a "Group content" view; doubt that it matters.

I have a view which is a list of users in groups. It therefore requires a relationship to "Group content user". I list the Group names (table grouped on this); and within each group i list the user's name and the roles they are in. Easy enough, this works as expected. I was trying to figure out a way to have the 1 user in that group that has an extra role stick at the top of each group (i.e. the group's coordinator). I have added aggregation and then a sort on count(roles). This also works as expected. Great.

But, later i needed to add a class to the roles field. When i edit the field i see that the Relationship selector is now missing. Only on this field though. All other fields still have the relationship selector. If i save the role field it now shows as empty in my results (which makes sense as i have now saved it without the required relationship).

The only way to fix this is to disable aggregation and then go back and re-save the role field (which now has the relationship selector).

Steps to reproduce

Using just core:

1. Install Drupal with standard profile
2. Edit the default Content view at /admin/structure/views/view/content
3. Add the Roles field using the Author relationship
4. Enable aggregation under Advanced > Other > Use aggregation
5. Click on the Roles field and see that the relationship selector is missing

Without aggregation enabled:

With aggregation enabled:

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Updated: Comment #206

Problem/Motivation

Twig debugging output is supposed to show all template suggestions. Currently, the debug output does not show all the template suggestions that the Drupal render system knows about.

Here are a few examples where this feature fails:

• Views (a core feature used in many places) templates do not show any template suggestions. For example, go to /admin/content and look at the Filter form at the top of the page; Twig debug shows: 'views_exposed_form', but Drupal's theme system is given this list of suggestions: ['views_exposed_form__content__page_1', 'views_exposed_form__page_1', 'views_exposed_form__default', 'views_exposed_form__content__page', 'views_exposed_form__page', 'views_exposed_form__content', 'views_exposed_form'] (defined in Drupal\views\Form\ViewsExposedForm::buildForm()).
• Using the default Bartik theme, use Drupal's search and look at the list of search results. Twig debug shows: x item-list--search-results.html.twig, x item-list--search-results.html.twig, * item-list.html.twig, but Drupal's theme system is given this list of suggestions: ['item_list__search_results__node_search', 'item_list__search_results'] (defined in Drupal\search\Controller\SearchController::view()).

The underlying cause of this issue is when #theme is set as an array of suggestions. The twig_debug output only works* when #theme is a string or when suggestions are added via suggestions_alter hooks.

* where "works" is defined as super buggy output, showing duplicates and out-of-order suggestions. See #2752443: Incorrect order and duplicate theme hook suggestions

When #theme is set as an array of suggestions, Drupal\Core\Theme\ThemeManager::render() will call the theme suggestions alter hooks with the base hook and will conditionally add an entry from the #theme array if that entry is actually implemented in the system. If none of #theme array suggestion entries are implemented, only the base hook is sent to the theme suggestions alter hooks and the code handling the twig debug comments code.

Here's a specific example of what Drupal core does now:

1. #theme is set to ['item_list__search_results__node_search', 'item_list__search_results'] in Drupal\search\Controller\SearchController::view()
2. Drupal\Core\Theme\ThemeManager::render() will look for implementations of the theme suggestions in the #theme entry.
   • If the only implemented Twig template is item-list.html.twig (like in the Stable themes), the theme suggestion alter hooks will be passed this list of suggestions: item_list, [list of suggestions from hook_theme_suggestions_item_list() (if this function existed)]
   • If the item-list--search-results.html.twig Twig template is implemented (like most core themes), the theme suggestion alter hooks will be passed this list of suggestions: item_list, [list of suggestions from hook_theme_suggestions_item_list()], item_list__search_results
3. The twig_render_template() generates the Twig debugging comments by looking at the list of theme suggestions returned by the theme suggestion alter hooks (passed in $variables['theme_hook_suggestions']). But it doesn't know about the item_list__search_results__node_search suggestion in Step 1, so the list is wrong.

Proposed resolution

Theoretically, we could fix this by #2923506: Deprecate and discourage use of the "array of theme hooks" feature, but that is a loooong road of deprecations that is completely stalled. And since the "array of theme hooks" feature has been in core since 6.x and has been used frequently in contrib and in core 9.1.x and earlier, we need to fix the bug now.

To minimize the possible side effects to changing how Twig chooses templates, we should not modify any existing lines of code inside Drupal\Core\Theme\ThemeManager::render() and only add code to generate a proper list of theme suggestions. OMG. No. This is technically possible, but a "proper list of theme suggestions" requires super ugly code if we're not going to modify existing lines of code. See comment #204 for proof in the form of a patch that implements this option.

Instead of conditionally appending suggestions from #theme on to the end of the suggestions from hook_theme_suggestions_HOOK(), we should always append those suggestions so that hook_theme_suggestions_alter() and hook_theme_suggestions_HOOK_alter() can see them.

Extending the example above, no matter what item_list Twig templates are implemented, the theme suggestion alter hooks will be passed this list of suggestions: item_list, [list of suggestions from hook_theme_suggestions_item_list()], item_list__search_results, item_list__search_results__node_search

This will make it easy to output an accurate suggestion list in twig debugging comments.

We will need to add extensive tests to make sure we aren't breaking anything.

This solution also fixes #2752443: Incorrect order and duplicate theme hook suggestions.

Remaining tasks

1. Final polishing and reviews
2. Commit

User interface changes

Twig debug output will display all templates suggestions, no matter the source of those suggestions.

API changes

The theme suggestions from #theme will always be added to the end of the hook_theme_suggestions_HOOK() list of suggestions before sending them to hook_theme_suggestions_alter() and hook_theme_suggestions_HOOK_alter().

Release notes snippet

Previously, theme suggestions from #theme (like views_exposed_form__content__page) were only sometimes added to the $suggestions variable passed to hook_theme_suggestions_alter() and hook_theme_suggestions_HOOK_alter(). Now those suggestions are always passed to alter hooks.

Problem/Motivation

Views currently does not show theme suggestions, due to a bug in core: #2118743: Twig debug output does not display all suggestions when an array of theme hooks is passed to #theme
Mark Carver though pointed out in #2118743-167: Twig debug output does not display all suggestions when an array of theme hooks is passed to #theme that views could also use hook_theme_suggestions

Proposed resolution

Use hook_theme_suggestions() instead of arrayed theme hooks.

Remaining tasks

Postponed till #2511548: Add a "context" array variable to all theme hooks and "#context" array property to all elements to provide optional contextual data is finished.

User interface changes

None

API changes

Deprecates ViewsPluginInterface::themeFunctions and ViewExecutable::buildThemeFunctions and replaces them with equivilent themeSuggestions methods.

Data model changes

None

Problem/Motivation

In PHPUnit 12, we have to replace test annotations with attributes. As noticed in #3417066-120: Upgrade PHPUnit to 10, drop Symfony PHPUnit-bridge dependency,

we can't mix PHPUnit attributes and annotations [in a single file], we will have to convert them all at once unfortunately

with thousands of test classes in Drupal, we should try to automate the conversion, in a way that a script can be executed on a file and convert it end-to-end.

Rector can help, but we need an overall Rector script that will do all the changes necessary in a go - we should convert by files or group of files, and not by rule/annotation.

Listing some findings for the Rector rule, will document here along

• @group legacy is a symfony/phpunit-bridge concept. It must be converted to the #[IgnoreDeprecations] attribute, however:
• it is still undocumented: https://github.com/sebastianbergmann/phpunit-documentation-english/issue...
• PHPStan does not identify this attribute as a deprecated scope https://github.com/phpstan/phpstan-deprecation-rules/issues/109
• @coversDefaultClass and @covers needs complete rethinking as there is NO one-to-one conversion:
• https://github.com/sebastianbergmann/phpunit/issues/4502
• https://github.com/rectorphp/rector-phpunit/issues/149
• https://github.com/sebastianbergmann/phpunit/issues/5175
• Rector rule CoversAnnotationWithValueToAttributeRector may not be fit for purpose because (a) does not manage short class names + use import and (b) it does not take into account the existence of [#CoversMethod] that was only (re)introduced in PHPUnit 11.1
• The #[CoversMethod] attribute only targets test classes and not individual test methods, this is being disputed upstream: https://github.com/sebastianbergmann/phpunit/issues/5837
• --> Since we will have to live with tests in shape for execution in PHPUnit 10 for a while, and only get later to a supported coverage of methods, the suggestion is to change @covers instances to @legacy-covers in the mean time, then decide what to do once fully on PHPUnit 11.
• @medium can no longer be associated to a method --> add #[Medium] to the class instead
• @uses can no longer be associated to a method --> add #[UsesClass()] to the class instead
• more to be defined

Proposed resolution

The MR here contains the rector.php file with a custome rule to do the conversion, and a .gitlab-ci.yml CI configuration file with a script that executes the rector rule, then runs PBPCBF to cleanup the changed files, then produces a git diff patch file and finally stores the patch as an artifact.

The diff patch file can then be used in child issues to convert specific parts of the test codebase.

The MR itself is not meant to be committed.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

MessageCommand was introduced in #3086096: Add a generic Ajax Message command. It is helpful to show status messages in AJAX contexts. Sadly it uses a totally different "render pipeline" than the active theme does. In fact it uses none, but builds the message area in JavaScript, without using the Theme's twig templates. That's how it's implemented.

From a Themers and Theme Prespective and from "Component" thinking, this is wrong. AJAX messages should use the same templates, as regular messages do.
That's why I'd rate this as bug from outer perspective. Still I think it was a (discussable) design decision.

This results in issues like this: #3165452: Override Drupal.theme.message to to make sure JS messages get rendered correctly

Of course, I know talk is cheap and this is hard to resolve, because the messages are added dynamically and you can't tell if the message area already exists. But these problems can be solved.

Implementation:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/message....
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Ajax%21Me...

The devel maintainer also points out that currently
dsm() / dpm() are broken and could be fixed in this issue: https://gitlab.com/drupalspoons/devel/-/issues/525#note_2039843855

Steps to reproduce

Show a regular status message using PHP in a custom theme, where the message area was modified in twig
Compare the result to a status message added by JavaScript. They differ a lot, if the JS-built dom structure isn't the same as the one in Twig.

Proposed resolution

Return the theme rendered message wrapper and the messages in the AJAX result. Only add the wrapper on the page, if none is present.
After adding or if the message wrapper is already existing, add the rendered messages.

This way the theme handles the message output, like it would do on a regular call, but AJAX builds the message from the theme results without a difference.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

AssetRoutes::routes() contains logic to determine where to store "assets," aka CSS and JS aggregates. This used to be hard-coded to use the public stream wrapper, which implements a ::getDirectoryPath() method. When a specific assets:// stream wrapper was introduced in #3027639: Make css/js optimized assets path configurable, the call to ::getDirectoryPath() was maintained, however if you override the assets stream wrapper (e.g., with Flysystem to point at object storage) this method is not available as it is not in the StreamWrapperInterface contract.

We do not have test coverage for this as it's an expert-mode customization to Drupal, but we should not make assumptions about the stream wrapper that is used.

Related, and discovered in the course of exploring this issue, the cache-control header sent with asset binary responses is incorrect. (It's set to private, no-store but is delivered to the client as public, no-store which isn't particularly performant and also unintentional/non-deterministic.)

Steps to reproduce

Override the stream wrapper implementation for assets:// with one that is not local. Because these stream wrappers do not have a "directory path" served by the web server, no assets available to the client.

For headers, observe that the header delivered with the response is incorrect.

Proposed resolution

Adjust the asset route generation and controller logic to at least not break non-local stream wrappers for asset storage, and clear the way for them to be served either piped from external storage or cached by a CDN/something else expert-mode.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet