Problem/Motivation

EntityTypeRepositoryInterface::getEntityTypeFromClass fails using ECK entities, because they have one entity class (Drupal\eck\Entity\EckEntity) for all ECK entity types. There is no way for ECK to fix this since they generate entity types based on config. Automatically generating PHP classes for every entity type seems a bit too far-fetched. I would imagine that a possible fix for this issue could be to manually create a class for every ECK entity type, but even that doesn't work: it fails on this line (is_subclass_of($class_name, $entity_type->getOriginalClass())) because the original class is still Drupal\eck\Entity\EckEntity, regardless of any overrides.

The code in question was introduced in #2570593.

Steps to reproduce

1. Install the eck module
2. Create two eck entity types + entity type classes subclassing EckEntity, and register them using hook_entity_type_alter
3. Create a bundle on one of those entity types + a class for that bundle, and register it using hook_entity_bundle_info_alter
4. Call EntityTypeRepository::getEntityTypeFromClass() with the bundle class name.

Proposed resolution

Maybe we can leave out is_subclass_of($class_name, $entity_type->getOriginalClass())? I'm not sure why that condition exists.

Follow-up to #2152217: Remove theme_form_required_marker() from the theme system - use CSS instead

Problem/Motivation

3 years ago, in #2152217: Remove theme_form_required_marker() from the theme system - use CSS instead, the community decided to remove the star (*) used to indicate that a form field is required from the source code to add it from the CSS. Initially, the issue was just about converting the theme function to a Twig template but changed quickly. The purpose of this change was to simplify theming and improve accessibility. The thing is that, according to WCAG, this is not as accessible as we thought.

References:

• WCAG 2.0 - 1.1.1 Non-text Content
• F3: Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information
• WCAG 2.0 - 1.3.1 Info and Relationships
• F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using :before and :after pseudo-elements and the 'content' property in CSS
• Accessiweb 2.2 - Criterion 10.2 - [Bronze] On each Web page, is visible content still available when style sheets or images are disabled? (Accessiweb is the French accessibility standard)

Screenshots

	With CSS	Without CSS
Before patch
After patch

Proposed resolution

Bring back markup but use the hidden CSS class to avoid changing the current look of the existing sites and aria-hidden to avoid screen readers to vocalize the content of the span as it's already covered by the aria-required and HTML5 required attributes.

Remaining tasks

User interface changes

Visually nothing as long as you have your CSS enabled.
A new "(required)" mention should be show on form labels for people that does not have their CSS enabled.

API changes

None.

Data model changes

None.

Problem/Motivation

When adding a new Content, Comment, Media or custom block type, the help text for the Name, Machine-name and Description fields are not consistent. Let's make them so.

Proposed resolution

Problem/Motivation

Track the steps needed to remove extension TBA from core to contrib. See Remove a core module and move it to a contributed project of the deprecation policy.

The removal of extension TBA was approved in TBA.

Remaining tasks

1. Create a section on Deprecated and obsolete modules and themes to provide recommendations for sites using extension EXTENSION_NAME. The recommendations are to include instructions for sites using the extension and for contributed projects that depend on then extension.
2. Set lifecycle to deprecated.
3. Set lifecycle_link to the section added above, https://www.drupal.org/node//3223395#s-EXTENSION_NAME.
4. Add @group legacy to the tests in the extension.
5. The change record for this issue includes a link to the doc page.
6. Do a thorough search of core for any remaining references to the extension. If references are found, outside of the extension, then creates issues to remove the references.

Release notes snippet

Problem/Motivation

Track the steps needed to remove extension Action from core to contrib. See Remove a core module and move it to a contributed project of the deprecation policy.

The removal of extension Action was approved in #3266458: [Policy] Deprecate Action (UI) module in D10 and move to contrib in D11.

Remaining tasks

1. Begin finding someone to maintain the contrib version of the extension.
2. Move integrations implemented by other modules to the extension.
   Create child issues or child meta issues, as needed, to address the following points. Not all points will apply to all extensions.
   • Move non-migration tests to the extension.
   • Removing references to the extension from database dumps.
   • Update Update path tests. See Writing Automated Update Tests for Drupal 8 (or later) for details.
3. Do a thorough search of core for any remaining references to the extension. If references are found, outside of the extension, then create issues to remove the references.
4. Create the contrib project with a stable release.
5. Deprecate the core extension. Use the Issue Summary template or core extension deprecation. #3369912: Final steps to deprecate Actions module

Completed tasks

• Fix migration test. #3343598: Remove action module from MigrationPluginListTest
• Move Help Topics to the extension. #3343600: Move help topics to actions module
• Remove templates from the extension’s markup.
  • Remove templates from themes that are staying in core, leave them in deprecated themes
  • Keep skipping the template in the stable copies test.
• For a module, handle migrations, if the module has migrations. The migrations have already been moved #3067299: Move actions migrations and tests to system module.

Problem/Motivation

The "Send email" action has a recipient field which allows multiple email addresses to be entered. The help states "Separate recipients with a comma.".

The validation performed on the field doesn't take this into account.

Steps to reproduce

Create a new action "Send email", fill in all the fields. In the recipient field, add multiple valid email addresses separated by a comma, click "Save".

Proposed resolution

Split the field value on a comma and loop through the results, validating each one.

This shouldn't break anything as all existing values in the field would still validate.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When executing an EmailAction, only tokens for nodes are replaced. To replace tokens for other entities, you need to directly pass these entities to the plugin configuration.

Proposed resolution

Use the type of the passed entity in the EmailAction::execute() method.

Problems

• Having a single parameter for actions is not sufficient, nor is it possible to add further metadata to the single parameter (e.g. to define whether it is required)
• We need to support actions without an entity paramter.
• Actions should follow the same API as conditions if there are no reasons to do it different.
• The action subsystem is coupled to entities.
• Finally, this is required if the action system should be useful to Rules as well.

Proposed resolution

Make the action sub-system using context, such as conditions.

Remaining tasks

Patch review.

User interface changes

-

API changes

API changes in this issue are approved by the comments on ActionInterface.php.

1. The 'type' parameter of action annotations is replaced by a proper context definition.
2. The execute() method on ActionConfigEntityInterface is removed.
3. The executeMultiple() method signature on ActionInterface is changed to additionally take a context name argument as first parameter.

Original report by tim.plunkett

See #1846172: Replace the actions API, it currently passes entities around directly, and uses hardcoded type = node

Follow-up for #2001190: Use derivatives for action plugins

+class SaveComment extends ActionBase {
+  public function execute($comment) {
+    $comment->save();
+    Cache::invalidateTags(array('content' => TRUE));
+  }
+}

Sounds like we want a postExecute() method that would run after all of the passed entities have been processed (for invalidating tags or doing any other cleanup).

Motivation

For Rules being able to properly switch between context/configuration being passed on, action (and condition) plugins should not / may not apply data processing like token replacements on the data passed - that may only happen if the user has input a respective value and the configuration user has according permissions.

Proposed resolution

Add data processing API and allow conditions and actions to use it

Remaining tasks

-

User interface changes

-

API changes

Probably some additions to action and condition base classes / context aware plugins.

Problem/Motivation

There are non-migration tests that install the action module.

Steps to reproduce

Proposed resolution

Move tests to the action module or remove actions from the install list.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

There are migration tests that install the action module.

Steps to reproduce

Proposed resolution

Remove actions from the install list.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Move and adjust migration tests as needed so that Statistics can be deprecated.

Steps to reproduce

Proposed resolution

Remove statistics from the migrate_drupal_ui tests and move that portion to new tests in the statistics module. Remove, as mush as possible, unneeded data from the existing fixtures to create smaller ones for Statistics.

Add @todos in

• \Drupal\Tests\migrate\Kernel\Plugin\MigrationPluginListTest
• \Drupal\Tests\migrate_drupal\Kernel\StateFileExistsTest

\Drupal\Tests\migrate_drupal\Kernel\Plugin\migrate\DestinationCategoryTest - this does not need to be moved to statistics. It is enabling all modules and would require multiple @todos. Instead add a note in the removal issue to do this work.

\Drupal\Tests\block\Kernel\Migrate\d6\MigrateBlockContentTranslationTest
\Drupal\Tests\block\Kernel\Migrate\d6\MigrateBlockTest
\Drupal\Tests\block\Kernel\Migrate\d7\MigrateBlockContentTranslationTest

Remaining tasks

Add note to removal issue
Review

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In the Olivero theme, the search block form component is not as per the Figma design for small screens
Before Patch

After Patch

Steps to reproduce

Make sure you have selected the Olivero theme and open it using Chrome or a similar browser and check for the search block form component

Proposed resolution

After debugging the issue I found that the search block form component is not as mentioned in the Figma design for small screens.

Remaining tasks

None

User interface changes

Adding flex-direction:row-reverse to the following class .block-search-narrow .search-block-form fixes the issue.

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

THINGS WE *THOUGHT* WERE CAUSING THE PROBLEM BUT WERE NOT
Test patches within this issue have ruled out several causes as they demonstrate:

• The failures are not specific to a database type, but the nature of the failures can differ.
• The failures occur even when running at single concurrency
• The failures regardless of how long a wait is provided for the process to complete

Details
This was discovered while working on #3055648: Frequent random fail in \Drupal\Tests\media_library\FunctionalJavascript\MediaLibraryTest. There are a few random failures that persist regardless of how the test is refactored. They are all related to the file upload widget failing in some manner, typically on the transition from uploading an image to rebuilding to display form fields for the image's Alternative text. In the Media Library tests, these errors often first reveal themselves after an image is uploaded. The form that appears post-upload should include hidden fields with height and width values, but these values are occasionally empty. (when this occurs, a validation message about an incorrect primitive value appears, which is incorrectly attributed to the alt text field -- this is actually due to the empty width/height hidden fields)

@tedbow helped with a test that ruled out this being an issue related only to the image widget. The test in
article-100x-image-uploads.patch uploads and removes and image on the Article content type 100 times. These 100 attempts are made on the usual node add form, as well as a version where the node add form is inside a dialog. These tests do not fail.

Also attached is a test - media-widget-100-consecutive-uploads.patch - that consistently reproduces the problem (on testbot, the problem never occurs on localhost). There are 100 instances of a file being uploaded then removed via the Media Library widget. On MySql and Postgres, the tests nearly always fail within the iteration 47-48. On SQlite, the iterations are far less predictable, sometimes failing on the first iteration, and never getting further than 48 iterations before failing. It's unlikely that the tests in #3055648: Frequent random fail in \Drupal\Tests\media_library\FunctionalJavascript\MediaLibraryTest will reliably pass until the symptoms demonstrated in this test are addressed.

In the MySql and Postgres tests, the failures always happen during the same step: the test has added a file to the media upload field, but the JS-triggered upload process does not occur. This is a screenshot of when the test fails -- it is expecting the upload process to happen then see a form with the fields associated with this media.

On the SQLite tests, the failures can happen in different places, but most them happen after uploading the media, filling out the necessary fields then clicking "Save and select". The test then asserts that the text "Save and select" is longer present, but in some instances it is.

In other instances, the test fails because it can't find a remove button for the just-uploaded media. This screenshot taken during the fail shows that the widget was never rebuilt:

There are a few other assorted fails in SQlite, screenshots of each can be accessed by viewing the test on the dispatcher and downloading the test artifacts.

Proposed resolution

Not sure yet, but I'm hoping that the non-SQlite tests always failing at iteration 47-48 provide insight into why this is happening.

Remaining tasks

Determine cause of problem, fix.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

The people at the county fair,
Were shocked asethey heard a loud blare:

A bear, a bear!
it's right over there, it's right over there!
I swear, I swear!
It shouldn't be there, It _shouldn't_ be there!

And one said with some flair:
And why exactly, should we care?

Because it causes a random ExpectationFailedException, you fake Dr. Suess!

1) Drupal\Tests\media_library\FunctionalJavascript\EntityReferenceWidgetTest::testWidget
"Bear" was found but shouldn't be there.
Failed asserting that a boolean is not empty.

/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:122
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:55
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/MediaLibraryTestBase.php:86
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/EntityReferenceWidgetTest.php:212
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When defining a route, we can define a requirements clause, which may contain a regexp to match a route parameter, like:

g2.initial:
  path: '/g2/initial/{g2_initial}'
  defaults:
    _controller: '\Drupal\g2\Controller\Initial::indexAction'
    _title_callback: '\Drupal\g2\Controller\Initial::indexTitle'
  requirements:
    _permission: 'access content'
    g2_initial: '[\p{Ll}\p{Lm}\p{Lo}\p{Lt}\p{Lu}\p{Mc}\p{Nd}\p{Nl}\p{No} _-]'

Since Symfony 4.3 (included), these regular expressions are documented as supporting Unicode classes https://symfony.com/doc/4.3/routing.html#route-parameters which means the regexp matching needs to add the u modificator at the end of the regexp, as per https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php

However, in UrlGenerator::doGenerate we use this line to match requirements:

          if (!preg_match('#^' . $token[2] . '$#', $mergedParams[$token[3]])) {

which means we do not enable full Unicode matching beyond basic PCRE, unlike Symfony ≥ 4.3.

As a consequence, any route receiving a parameter matching one of these classes will throw an InvalidParameterException when invoked with a character like é.

Steps to reproduce

• Define a route like the one above.
• In some code, e.g. using drush core-cli try to generate a link to /g2/initial/é, like:
  

  $ug = \Drupal::urlGenerator();
  $ug->generateFromRoute('g2.initial', ['g2_initial' => 'a']);
  $ug->generateFromRoute('g2.initial', ['g2_initial' => 'é']);
  

• Observe how the first case succeeds while the second throws the exception

Note that the problem does not exist when routing incoming requests, as symfony/routing handles the regexp correctly for us.

Proposed resolution

Append the u modificator to support full Unicode matching.

Rerun the example above: now both calls work normally, generating:

"/g2/initial/a""/g2/initial/%C3%A9"

As expected.

Remaining tasks

Implement change.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

The UrlGenerator can now correctly generate URLs to routes using full Unicode character matching with parameters outside the ASCII range.

Problem/Motivation

The test FunctionalJavascript/MaximumFileSizeExceededUploadTest started to hang in CI for PHP 8.2 alpha 1 and 2
It was caused by regression https://github.com/php/php-src/issues/11507
Ref #3366843-28: Fix tests broken on PHP 8.3

But the issue in that post_max_size could be hundreds of megabytes and generating such a big file char-by-char could be very time consuming for no reason

Steps to reproduce

check implementation https://git.drupalcode.org/project/drupal/-/blob/11.x/core/tests/Drupal/...

Proposed resolution

- use random generator to get sequence of bytes instead of char by char
- set limit on number of iterations
- refactor test as it does not require random file as testing controller's behavior

Remaining tasks

- discuss
- patch/review/commit

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

When looking at a french node (/fr/node/xxx) the primary tabs are displayed.
But if I change the language (/nl/node/xxx) the primary tabs are not displayed anymore.
If I uninstall the BigPipe module, the primary tabs are displayed again in all circumstance.

We should be able to use rel="preload" on a CSS asset.

dist/main.bundle.css: { attributes: { rel: preload, as: style } }

This doesn't work ; we can't override the default rel="stylesheet" because of the way the attributes are merged in Drupal\Core\Asset\CssCollectionRenderer

    // Defaults for LINK and STYLE elements.
    $link_element_defaults = [
      '#type' => 'html_tag',
      '#tag' => 'link',
      '#attributes' => [
        'rel' => 'stylesheet',
      ],
    ];

    foreach ($css_assets as $css_asset) {
      $element = $link_element_defaults;

      // .....

      // Merge any additional attributes.
      if (!empty($css_asset['attributes'])) {
        $element['#attributes'] += $css_asset['attributes'];
      }

Since $array1 + $array2 is not equal to $array2 + $array1 when those arrays have common keys (https://stackoverflow.com/a/13087814/3493566),
$element['#attributes'] += $css_asset['attributes']; should be
$element['#attributes'] = $css_asset['attributes'] + $element['#attributes']; or
$element['#attributes'] = NestedArray::mergeDeep($element['#attributes'], $css_asset['attributes']);

There's the exact same logic on Drupal\Core\Asset\JsCollectionRenderer but, since there's no default rel attribute, we already can use rel="preload" on JS assets.