Problem/Motivation

The default entity reference selection plugin (Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::createNewEntity) doesn't validate newly created entities which could lead into potential data integrity problems. Drupal doesn't ship with broken configurations by default, but it is very easy for users to configure in a way that leads into data integrity problems. For example, adding additional required fields besides label/title for auto creatable entity type or bundle would automatically lead into data integrity problems.

Proposed resolution

1. Add UI restrictions to prevent users from creating broken configurations on their sites
2. Validate auto created entities in Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::createNewEntity

Steps to reproduce

1. Install standard profile
2. Add a required field to the tags taxonomy
3. Ensure the tags field on Article autocreates entities
4. Create a new article with a tag that doesn't exist.
5. Verify the term is created with the new required field empty.

Remaining tasks

-

User interface changes

-

API changes

This might create some API changes since we would do more validation. However, this only happens when user has already misconfigured their site.

Data model changes

None, but this will add stricter validation validation for new data being created through the default entity reference selection plugin.

Problem/Motivation

ModulesUninstallForm.php assigns string value to ['attributes']['class'] which can cause complication since in most cases Array is expected.

In our case, hook_link_alter() was used in custom module to target links with specific class values and additional classes were appended to them. As soon as we upgraded to 9.4, an error was thrown on visiting admin/modules which was complaining about [] operator not supported for strings.

Of course we could change our custom code, but I believe, in principal, ['attributes']['class'] should be an array, since class often holds multiple values.

Proposed resolution

We can simply put the value in [].

Remaining tasks

Write tests

Problem/Motivation

Machine names of menus use a hyphen instead of an underscore as default replacement.
This is different then most (all?) other machine-names.

A machine-name like menu_main is therefor not possible. It must be menu-main.

This is possibly only a UI feature for helping administrators with creating valid machine-names.
In that case there are no deeper dependencies where code related to the menu-system requires the hyphen-pattern.

Steps to reproduce

• Create a new menu via the UI, use the underscore _ in the machine-name. Notice the underscore is replaced with a hyphen -
• Create a new menu via code and use underscores in its machinename, edit the menu in the UI and notice this error: "A unique name to construct the URL for the menu. It must only contain lowercase letters, numbers and hyphens."

Proposed resolution

If this is a UI feature only the proposal is:

1. Allow both _ and - in machine-names of menu's. This is a BC layer for both patterns.
2. Default the replacement to underscore _ which is inline with other machine-names.
3. Currently no upgrade path where existing menu machine-names are converted to the underscore pattern.
4. Currently no changes in default config (install profiles) that create new menus in new installations.

After this change the following machine-names are valid

1. menu_main
2. menu-main
3. menu-_main

If an administrator creates a new menu with the title "Menu main", the automatically created machine-name will be the first one with underscores i.e. menu_main

Remaining tasks

• Create a patch
• Get an answer if there is code in Drupal core or contrib that depends on the existing machine-name pattern without underscore

User interface changes

API changes

• Both Underscores and hyphens are allowed in menu-machine names

Data model changes

Release notes snippet

Before going any further, know this:

There's a patch of comments - #175-#235 - that may be a bit confusing as some of what was discussed spun off into a different issue: #3076171: Provide a new library to replace jQuery UI autocomplete

Anything in this issue that specifically discusses replacing jQueryUI with Awesomplete is no longer relevant to this issue and can be ignored. Everything else particularly the library evaluations, are still fully relevant. The desired improvements to select elements will need to be accomplished with a different library than what is used for autocomplete.

In other words: The stuff about Awesomplete is not relevant to this issue, but everything else is. . This is about improving the UX of select lists.

Problem/Motivation

Improve usability and accessibility of long select lists and autocomplete tagging widgets.

Proposed resolution

• Evaluate possible libraries
• Create a pro / con list and required feature list for the library candidates, for example
  • Code style
  • Maturity
  • Responsiveness
  • Accessibility
  • UX
  • UI
  • Modularity
  • AJAX support
  • Single / multi select
  • Filter search
  • ...
• Choose the best matching library for Drupal's needs.

Libraries evaluated so far

• https://github.com/jshjohnson/ChoicesEvaluation (#189)
• https://harvesthq.github.io/chosen/Evaluation (#194)
• https://github.com/Mobius1/SelectrEvaluation (#195)
• https://github.com/alphagov/accessible-autocomplete (prototype at #182, great accessibility but not considered as it does not support select/multiselect It is strictly for providing suggestions to single-value text fields)
• https://github.com/HemantNegi/jquery.sumoselectEvaluation (#201)
• http://ivaynberg.github.io/select2 (of which https://github.com/woocommerce/selectwoo is a fork of, created to improve accessibility) Evalulation (#193)
• Custom library based on https://react-select.comEvaluation (#200)
• https://selectize.github.io/selectize.js/Evaluation (#199)
• https://github.com/github/auto-complete-elementEvaluation (#222)

(disregard the Awsomplete evaluations - it is a great library, just not relevant to this issue)

Remaining tasks

• Determine specific requirements for new functionality
• Compare against the libraries reviewed so far, and evaluate additional ones when discovered
• Confirm the desired replacement is sufficiently accessible

User interface changes

Yes.

API changes

Yes.

Problem/Motivation

Log a warning if the attribute name contains a space and we strip the attribute all together (e.g. ['selected href' => 'http://example.com']). Because we're only checking that the output attribute names match the ones we pass in this will be stripped.

Steps to reproduce

Proposed resolution

If an attribute name contains a space log a warning and strip the attribute entirely.

Remaining tasks

If an attribute name contains a space log a warning and strip the attribute entirely.
Test coverage.

User interface changes

A warning will be logged if an attribute name contains a space.

Introduced terminology

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

TBC

Problem/Motivation

There is no need to use FormattableMarkup to produce message strings in PHPUnit assertions; it is cleaner and easier in almost all cases to use simple string interpolation instead.

Steps to reproduce

Proposed resolution

Replace all uses of FormattableMarkup in kernel test assertions with either plain string interpolation, or remove the assertion message entirely when the assertion is obvious and the message does not add any context.

Keep FormattableMarkup at:

• tests/Drupal/KernelTests/Core/Routing/ExceptionHandlingTest.php (single comment)
• tests/Drupal/KernelTests/Core/Theme/TwigMarkupInterfaceTest.php (markup tests)
• tests/Drupal/KernelTests/Core/Test/Comparator/MarkupInterfaceComparatorTest.php (markup tests)
• tests/Drupal/KernelTests/Component/Render/FormattableMarkupKernelTest.php (test FormattableMarkup)

Remaining tasks

1) Command to search code base

grep FormattableMarkup -r -l | grep Kernel

2) Decide if FormattableMarkup should be removed from:

• tests/Drupal/KernelTests/AssertContentTrait.php
• modules/system/tests/src/Kernel/Theme/FunctionsTest.php

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal saves and render Date field in certain way. However the way it does, is not very transparent looking at the available documentation. This becomes critical when we have time sensitive fields example Event Date and Time.

During content save Drupal will store Date field in UTC format, the date input by user is considered to be in timezone user belongs to at the time of saving.
During content render Drupal will convert it to viewer's user account timezone in case of logged in user, else in site default time zone in case of anonymous user.

While this works most of the times, however in case where content editor has to create multi geographical data belonging to different timezone it becomes erratic in nature and hard to understand for editor.

Steps to reproduce

1. Add a Date and Time Field in Drupal.
2. The process of Drupal storing and rendering date field is missing.

Proposed resolution

Improve documentation to explain Drupal way of maintaining the date, so site builders take more aware decisions.

When fields allow multiple values (other than e.g. checkboxes), the widget is output in a table with tabledrag. This is functional but difficult to style to look consistent with other form elements. When a form needs to match a design, we often find ourselves fighting to hide the fact that fields, which often do not need to be orderable at all, are being presented in a tabledrag table we don't want.

This patch adds an option to the field widget settings which shows up for multiple fields to allow you to choose if the field should be orderable. If you do not choose orderable it will not use a table with tabledrag to output the fields.

Before:

After:

Setting:

Problem/Motivation

When node_access_rebuild(TRUE) is called multiple times per request, it registers as many batch sets as the number of times the function was called. This can lead to unnecessary long node access rebuild processes, because triggering the operation once per request is enough. At least it's hard to imagine a scenario when multiple consecutive runs would have any benefit.

Example: Let's say you are rolling out some updates to your site and multiple modules request node access rebuild in their database update hooks via node_access_rebuild(TRUE);. Ideally, what should happen is that the rebuild process is performed only once, but it going to be triggered multiple times.

Steps to reproduce

1. Implement two new database update hooks (not necessarily in different modules) which request node access rebuild by calling node_access_rebuild(TRUE);.
2. Run the pending database updates either via Drush or from the administrative UI.

Proposed resolution

I can think of several possible solutions to address the problem:

• Fix the implementation of node_access_rebuild()'s batch mode to register only one batch set even if the function is called multiple times.
• As an alternative solution - if it turns out that there can be scenarios when running the rebuild process multiple times does make sense - provide a solution which ensures that the process is only registered once per request (e.g. node_access_rebuild_once()).
• Provide a solution by which developers can check whether the rebuild process has been triggered already during the request.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

I am currently working on transitions of existing Drupal 7 site to Drupal 11.

I installed Drupal 11.1.4

After installation completion, I am redirected to the « Welcome page ».
Display does not correspond to the expected look and feel. See screenshot 1
Reloading the page leads to a correct display of the « Welcome page ». See screenshot 2

When navigating to admin/content, once again, display does not correspond to the expected look and feel. See screenshot 3.
Reloading the page leads to a correct display of the admin/content page. See screenshot 4

Display is not systematically wrong. What I observe is when is takes some time for the page to load, there is a chance that the display is wrong. It seems that when the loading of the page is without delay, the display is correct.

I never experienced this problem with Drupal 7, Drupal 8 nor Drupal 9.
It is with Drupal 10 and Drupal 11 installation that I have observed this problem.

Any idea of the origin of this problem ?.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Date views filter (\Drupal\views\Plugin\views\filter\Date) throw a php warning with checked "Allow multiple selections" option.

Warning: Undefined array key "type" in Drupal\views\Plugin\views\filter\Date->acceptExposedInput() (line 128 of core/modules/views/src/Plugin/views/filter/Date.php).

This happens because when the "Allow multiple selections" option is checked the $this->group_infois array.
And this condition in the \Drupal\views\Plugin\views\filter\Date::acceptExposedInput is not enought because $this->group_info['type'] can be an empty and cause a warning:

    if (is_array($this->group_info)) {
        $type = $this->group_info['type'];
    }

Steps to reproduce

1. Install Drupal standard profile
2. Edit the default Content view at /admin/structure/views/view/content
3. Add a "Created" filter
4. Select "Expose this filter to visitors, to allow them to change it"
5. Select "Grouped filters"
6. Set the Grouping 1 label to "Last week", operator to "Is greater than", value type to "An offset from ..." and value "-7 days"
7. Check "Allow multiple selections"
8. Press Apply and then Save
9. Navigate to /admin/content

Proposed resolution

Replace condition in the \Drupal\views\Plugin\views\filter\Date:127
if (is_array($this->group_info)) {
with
if (!empty($this->group_info['type'])) {

Problem/Motivation

https://www.drupal.org/sa-core-2025-004 added some XSS filtering code to the link module which ideally would live in core itself.

The aim is not to introduce new APIs or make BC breaking changes in Security Advisories, but now the SA has been released the code can be refactored in a public issue.

Steps to reproduce

Code in question: https://git.drupalcode.org/project/drupal/-/commit/b112cf535a8edd5a981c2...

Proposed resolution

Per the comments in \Drupal\link\AttributeXss:

/**
 * Defines a class for attribute XSS filtering.
 *
 * @internal This class was added for a security fix and will be folded into
 *   the \Drupal\Component\Utility\Xss class in a public issue.
 */
final class AttributeXss {

Remaining tasks

tbc

User interface changes

tbc

Introduced terminology

tbc

API changes

tbc

Data model changes

tbc

Release notes snippet

tbc

Problem/Motivation

Split from #2880237: [meta] Refactor system/base library

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Prior to #2057401: Make the node entity database schema sensible and the implementation of fully revisioned node fields, data loss was possible when reverting between revisions with different node authors. This has been a long-standing source of confusion and bugs through multiple versions of Drupal core. Notwithstanding that this should now be "fixed", tests should be implemented to ensure that node and revision author information is in fact preserved across revisions and reverts.

Per comment #8 by catch below, the typical problem scenario arises when changing author information across revisions and then reverting:

Steps to reproduce, logged in as user 1 works fine for this.

1. Create a node with user A (current user is fine)
2. Edit the node, change authoring information to user B, check the 'new revision' checkbox.
3. Revert to the revision created with #1.
4. Revert to the revision created with #2.

Now there's two issues:

1. User A is still listed as the author of the node, but it should be user B.
2. There is no trace of user B ever being the author of the node in the node_revisions table or anywhere else.

Proposed resolution

The underlying need for revisioning author information has been addressed in core, but we should add tests to ensure there is no future regression.

Remaining tasks

The test proposed needs to be reviewed.

User interface changes

None -- this affects automated testing only.

API changes

None -- this affects automated testing only.

Contributor tasks needed

Beta phase evaluation

Problem/Motivation

Some of RegExp.test() can replace with method which is defined String.prototype. In core/modules/toolbar/js/escapeAdmin.js, checks that window.location.search includes 'destination='.
This case can change to window.location.search.includes('destination=').

Proposed resolution

Replace possibly RegExp for simple string comparison with
method which is defined String.prototype.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Core contact form throws error when submitting form.

TypeError: Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given, called in /var/www/html/web/core/lib/Drupal/Component/Render/FormattableMarkup.php on line 238 in Drupal\Component\Utility\Html::escape() (line 431 of core/lib/Drupal/Component/Utility/Html.php).

Steps to reproduce

Drupal core 11.0.x, php 8.3.
Create contact form, subject field disabled.
Sending e-mail gives above error.

If Subject field is enabled, error goes away.

Core migration issues

• RTBC
• NR
• all open
• Needs subsystem maintainer review
• Statistics, Google spreadsheet

Next video meeting 2025-04-24

Hello all, it’s time for the biweekly migration subsystem meeting. The meeting will take place in slack in various threads. This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every second Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. #3456078: [meeting] Migrate Meeting 2024-07-18 2100Z)See the parent issue for an idea of the typical agenda.
➤Transcript will be exported and posted to the agenda issue. For anonymous comments, start with a 👤 emoji. To take a comment or thread off the record, start with a 🚫 emoji.

0️⃣ Who is here today?

1️⃣ What should we talk about today? Suggest topics here and I will add threads. I will also check for comments on the issue for today's meeting.

2️⃣ Action items. To be added later.

3️⃣ Statistics

4️⃣ Comment in this thread if you are looking for ways to contribute. Give us some idea of what you would like to do: documentation, code review, testing, project management, ...

5️⃣ Previous minutes.

6️⃣ Announcements

7️⃣ Change the filter in the details page for migration messages to a condition object

8️⃣ migrate mapping & messages table names are truncated, can lead to incorrect mapping lookups

9️⃣ Move the d8_config source plugin to the migrate module

🔟 Migrations fail due to missing dependency when dependency has skipped rows by the source plugin

1️⃣1️⃣ Should migration plugins declare their configuration?

1️⃣2️⃣ Menu migration should happen before block migration

1️⃣3️⃣ Wrap up

Problem/Motivation

The work to enable Drupal.Commenting.FunctionComment.MissingReturnComment

Steps to reproduce

Proposed resolution

Add child issues

Remaining tasks

Complete child issues
When the other issues are fixed use this issue to enable the sniff and fix any remaining problems.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

With the contributed module Symfony Mailer installed and configured in a Drupal 11.x site, site emails, including the password reset email, html-encode quotation marks and similar characters in the body of the message. Such emails contain tokens for example the site name. So, as an example, if a site name has apostrophes (single quotes) in it like 'L'Entreprise' then they are converted to HTML entities in the email body.

BEFORE
The text as seen in the sent email with Symfony mailer installed:

AFTER
The same email with the fix applied, with the single quotations displayed correctly:

There is a fix for this behaviour at line 785 of the user.module file:

BEFORE

  $message['subject'] .= PlainTextOutput::renderFromHtml($token_service->replace($mail_config->get($key . '.subject'), $variables, $token_options));
  $message['body'][] = $token_service->replace($mail_config->get($key . '.body'), $variables, $token_options);

AFTER

  $message['subject'] .= PlainTextOutput::renderFromHtml($token_service->replace($mail_config->get($key . '.subject'), $variables, $token_options));
  $message['body'][] = PlainTextOutput::renderFromHtml($token_service->replace($mail_config->get($key . '.body'), $variables, $token_options));

Steps to reproduce

Install Drupal 11.x using the standard profile.
Change the site name to 'L'Entreprise'.
Install the Symfony mailer module.
Set the Symfony mailer as the default mailer.
Generate an email for a new user or create a password reset email for a user and sent it.
View the email.

Proposed resolution

Apply the function PlainTextOutput::renderFromHtml to the body of the emails then apostrophes and quotes and other special characters will be displayed as plain text.

API changes

N/A

Remaining tasks

There is an MR with a fix. There is also now a test. But the test will always pass until tested with the Symfony mailer contributed module installed and configured. It is necessary to find a way of applying a test-only test that fails.

Problem/Motivation

This provides a single CSS rule, for a class that is only used in themes/claro/js/nav-tabs.js

We can move the rule to themes/claro/css/components/tabs.css and copy to somewhere in stable9, so that it's not loaded on every page for every Drupal site.

This is a tiny file so the bytes savings are miniscule, but it's also an extra http round trip when aggregation is off, such as the UI installer and maintenance mode etc.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet