Problem/Motivation

When using the Preview on same page feature for content editing, Drupal displays a confirmation modal when navigating away from the preview. However, this modal is also triggered during in-page AJAX interactions (e.g., filtering, autosubmit forms, autocomplete selections), causing confusion and unnecessary interruptions to the user experience.

This is especially disruptive when working with features like view mode switching, inline form updates, or autocomplete fields that are AJAX-driven but don’t constitute actual navigation away from the page.

Steps to reproduce

1. Enable content preview for a node type.
2. Start creating/editing content and preview it.
3. Trigger an AJAX action, such as:

- Using an autocomplete field.
- Changing a view mode that autosubmits.

4. Observe the "Leave preview?" modal incorrectly appears, despite not leaving the page.

Proposed resolution

This patch updates the nodePreviewDestroyLinks and nodePreviewSwitchViewMode behaviors to properly:

• Detect and handle AJAX requests via ajaxComplete, setting a hasAjaxRun flag.
• Suppress the leave-preview modal for AJAX-driven interactions
• Prevent false-positive triggers of the modal during expected UI events.

Remaining tasks

• Review JavaScript logic for robustness.
• Confirm patch fixes the issue across different browsers.
• Confirm behavior works with modal and non-modal previews.

Problem/Motivation

I'm not sure if this is an issue with entity_reference or field...

We recently uninstalled a module that contained an custom entity. There were nodes that had entity_reference fields. We removed the reference fields but I'm still getting an error on the field_cron run

Drupal\Core\Field\FieldException: Field 'field_vt_recipients' on entity type 'monument' references a target entity type 'medal' which does not exist. in Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem::schema() (line 172 of /code/web/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php).

I've checked my config files and there's no medal reference or field_vt_recipients left. is there another place I can look to clear this error?

We're currently on v 10.4.6

Problem/Motivation

Drupal is executing queries like the following one which are producing significant load and always full table scans

SELECT pattern_outline FROM router WHERE '/node/278960' LIKE CONCAT(pattern_outline, '%') AND pattern_outline != '/';

Steps to reproduce

Run a query like the following:
SELECT pattern_outline FROM router WHERE '/node/278960' LIKE CONCAT(pattern_outline, '%') AND pattern_outline != '/';

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

When users comment multiple times in a row on a post, it is often desirable to visually group their responses for readability. Many modern forums and discussion platforms (e.g., Slack, Discourse) hide repetitive elements such as the user avatar, name, and timestamp for consecutive messages by the same user. Drupal’s core comment module currently renders each comment with its full metadata, regardless of author repetition.

Proposed resolution

Introduce logic to track author continuity in the CommentDefaultFormatter when rendering comments. For each comment, if the author is the same as the previous comment, allow the comment view mode to alter its presentation (e.g., hide the header or footer region).

This could be implemented by:

1. Tracking the previous comment’s user ID in the formatter.
2. Adding a #context variable to the render array such as ['same_author_as_previous' => TRUE].
3. Allowing view modes or templates (like comment--default.html.twig) to conditionally suppress header or footer rendering based on this context.

Optionally, expose this as a formatter setting (e.g., “Collapse consecutive comment author information”) to allow site builders control over this behavior.

Example logic (simplified):

$previous_uid = NULL;
foreach ($comments as $comment) {
  $uid = $comment->getOwnerId();
  $same_author = ($uid === $previous_uid);
  $previous_uid = $uid;

  $render_array = $this->viewBuilder->view($comment, $this->getSetting('view_mode'));
  $render_array['#context']['same_author_as_previous'] = $same_author;

  $build[$comment->id()] = $render_array;
}

This could then be used in Twig:

{% if not same_author_as_previous %}
  <header class="comment-header">
    {{ author_picture }}
    {{ author_name }}
  </header>
{% endif %}

Remaining tasks

• Decide whether this should be core functionality or opt-in via a setting.
• Ensure that multi-threaded comments are handled properly
• Implement unit and render tests.
• Provide a final merge request.

There needs to be something in between toggling "Show content preview" and the amount of characters displayed by lorem ipsum/devel when working with multiple fields.

It's nice to have the content preview so you can confirm that any labels are completed but not have it followed by paragraphs of text

Problem/Motivation

When makes changes to the languages (more specificially changing the language negotiation) in Drupal 8.6.2 I'm getting multiple notices. Check out the screenshot for the error.

This is an error after using the Drupal 8.6.2 environment for a couple of weeks. This means the error could happen for a variety of reasons.
The fix I'm proposing is a simple check for the index, which is mostly harmless, but will remove the notice.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3512835: [11.1.x] Add BC stubs for Hook ordering. we added BC stubs for hook attributes and order classes.
The goal was that contrib modules that use the new hook order features can still remain compatible with older versions of Drupal.

From comment #37 in #3512835: [11.1.x] Add BC stubs for Hook ordering.:

We have a grace period before 11.2.0 to tweak api details of the new attributes and API features we are adding.
But whatever we put into older versions of Drupal may get released before 11.2.0, as part of a minor release. At that point we can no longer change these, so we are cutting that grace period short.

Also for disruptive future changes to the new attributes, we now will need to cater to the 10.5.x, 11.0.x and 11.1.x as well.
Worse, we could have contrib modules written for 11.2.x that are compatible with 10.5.x but not with 10.6.x, or vice versa, because we just backported another change.

Steps to reproduce

Proposed resolution

Revert changes from 10.5.x and 11.5.x that were backported as hook order BC stubs, have not been released yet, and which are not necessary for the main purpose that they were added for.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

First of all I want to state that I can understand the logic behind the 6.x->7.x API change in #593522: Upgrade drupal_alter().

However, what is the use of passing three variables by reference, when the documentation says (paraphrased):
"Oh, and if you need more variables, you should make the last one an associative array with passed-by-reference values."

If you're going to use that logic anyway, why not change the function to:

  function drupal_alter($type, &$data, $context) {
    // Same logic, only pass just one context
  }

Note: As part of this suggestion, I changed the context variable to no longer be passed by reference. If you want to pass something by reference, you could use the array technique currently described in the docs for $context2.

Reasoning behind this change is that if you want to allow a certain variable to be altered by other modules, based on a certain context, you may not want that context to be alterable as well. By changing $context to a not-passed-by-reference value, you give people the choice.

So in short:

1. What this issue is about: 2 similar variables that could be replaced by just one
2. What this issue further suggests: make the $context parameter optionally passed by reference, not forced

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

Hello,

1. The first sort way
This way affects the use of field values because the fields above cannot be obtained from the fields below through Twig, Only the fields below can obtained the values of the fields above. So, it cannot be sorted arbitrarily here, because to obtain the values of other fields, they must be placed on top, and in the front-end table output, it needs to be placed in the last column of the table. This is contradictory, unless in the Format table settings, you can freely drag and drop to control the sorting of columns.

2. The second sort way
I hope can control the sorting of table columns in Format table settings.

Problem/Motivation

When non-ASCII characters are used in the query string of a Url object, the link generator service fails to add an is-active class to the anchor tag.

Steps to reproduce

This faulty behavior is demonstrated by the test-only changes in the MR. The MR modifies the core LinkGeneratorTest::testGenerateActive() test to demonstrate that this test passes when an ASCII query string is used but fails with a Cyrillic query string.

Proposed resolution

Post #8 proposed a change to the JavaScript that adds this class.

Remaining tasks

Fix the link generator service so that the tests pass. #8 needs to be put into the MR and reviewed, or another change needs to be proposed.

User interface changes

None.

API changes

None.

TL;DR

The constructor for \Drupal\Core\Url allows the user to pass in an array of key-value options as the third parameter.

These options are supposedly documented in the documentation for Url::fromUri() but in practice core sets and uses other options that are not documented there.

Specifically, the link generator service recognizes and uses the set_active_class option. This option is documented in core/includes/theme.inc in the documentation for template_preprocess_links() (deprecated, moved to an OO hook \Drupal\Core\Theme\ThemePreprocess::preprocessLinks).

- set_active_class: (optional) Whether each link should compare the
     route_name + route_parameters or URL (path), language, and query options
     to the current URL, to determine whether the link is "active". If so,
     attributes will be added to the HTML elements for both the link and the
     list item that contains it, which will result in an "is-active" class
     being added to both. The class is added via JavaScript for authenticated
     users (in the active-link library), and via PHP for anonymous users (in
     the \Drupal\Core\EventSubscriber\ActiveLinkResponseFilter class).

There are also core test cases in \Drupal\Tests\Core\Utility\LinkGnereatorTest to ensure this option does the right thing.

Original bug report

Code:

        \Drupal::service('link_generator')->generate($title, Url::fromRoute('yarcom_sphinx.search_type', array('search_type' => $t), array(
          'set_active_class' => TRUE,
          'query' => array(
            'q' => $i['query'],
          ),
        )));

If $i['query'] is russian characters, css class is-active does not appear.

Example 1:
$i['query'] = 'комацу' (russian characters).
Browser address bar: http://dev.******.ru/search/yarcom_news?q=%D0%BA%D0%BE%D0%BC%D0%B0%D1%86...
Html code:
<a href="/search/yarcom_news?q=%D0%BA%D0%BE%D0%BC%D0%B0%D1%86%D1%83" data-drupal-link-query="{&quot;q&quot;:&quot;\u043a\u043e\u043c\u0430\u0446\u0443&quot;}" data-drupal-link-system-path="search/yarcom_news">News entity</a>

Example 2:
$i['query'] = 'komatsu' (english characters).
Browser address bar: http://dev.*****.ru/search/yarcom_news?q=komatsu
Html code:
<a <strong>class="is-active"</strong> href="/search/yarcom_news?q=komatsu" data-drupal-link-query="{&quot;q&quot;:&quot;komatsu&quot;}" data-drupal-link-system-path="search/yarcom_news">News entity</a>

In the first example q=%D0%BA%D0%BE%D0%BC%D0%B0%D1%86%D1%83" and data-drupal-link-query="{"q":"\u043a\u043e\u043c\u0430\u0446\u0443"}" are not identical.

Problem/Motivation

When exporting content using a Views REST Export, images do not always honor the display settings configured in the content type. Specifically:

• If the View format is set to Entity, the image field outputs the original image URL, not the image style (e.g., medium, thumbnail) configured in the content type’s Manage Display settings. There is no option to change this behavior.
• If the View format is set to Fields, it is possible to choose a specific image style, but:
  • There is no "Default" image style option that would follow the content type's display configuration.
  • Important image metadata (e.g., alt, title, width, height) is not included in the output, making it difficult for frontend consumers (like SPAs or mobile apps) to render the image accessibly and accurately.

This limits flexibility, leads to inconsistency, and reduces accessibility of API-based frontends relying on the exported data.

Steps to reproduce

1. Create a content type (basic_page) with an image field.
2. Set the image field to use a specific image style (e.g., Medium) in Manage Display.
3. Create a View with a REST Export display.
4. Set the View format to:
   • Entity: Note that the image field outputs the original image URL, ignoring the display settings.
   • Fields: Add the image field and choose an image style. No option is available to use the “default” (Manage Display) style. Also, alt, title, width, height values are not exposed.

Proposed resolution

• Enhance the Entity row plugin in Views REST Export to respect the image style set in the content type's Manage Display.
• When using Fields format:
  • Provide a "Default" image style option that reflects the display configuration of the content type.
  • Extend the image field formatter or Views integration to include image metadata (alt, title, width, height) in the export.

These changes will maintain consistency across rendered and exported content and improve API accessibility.

Remaining tasks

• Technical analysis to determine how image styles are selected in the Entity row plugin.
• Implement logic to default to display settings.
• Update image field output to include metadata.
• Write functional tests covering both Field and Entity format output.
• Update documentation for REST Views and image field behavior.

User interface changes

• Addition of a "Default" image style option in Views UI for image fields.
• Possibly new checkboxes or fields to select which image metadata to include.

Introduced terminology

API changes

Data model changes

Release notes snippet

Original report by RobKoberg

I have added an image field to a basic_page content type and set the display to use the medium image style.

When using a views rest export:

• With the format set to show as an entity, the original file URL is used rather than that set in the display settings and there is no way to set the appropriate image style. It should use the image style set in the display settings.
• With the format set to show as fields, I can select the same image style I used in the content type's display settings. There should be a "default" option that does this (uses the content type's display setting) in case it changes without the views knowledge. In addition, there is no way to get other information like alt, title, width, height, etc.

Problem/Motivation

We should introduce a Caddyfile configuration to enable Drupal to be served by caddy. It would also make it possible to use FrankenPHP easily, and benefit from all it's features such as, server sent events, early hints to load assets faster, etc.

Later, once #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole is in a good state, we can enable the worker mode of FrankenPHP and improve performance. The end goal would be to recommend FrankenPHP as the way to deploy Drupal on production.

We can also make use of FrankenPHP static binary to provide a PHP-cli and make it possible to use and serve Drupal (including composer and drush) from an environement that does not have PHP installed. From what I tried the following works:

# download the relevant binary for you system from https://github.com/dunglas/frankenphp/releases
# download composer https://getcomposer.org/download/
$ frankenphp php-cli ~/opt/bin/composer create-project drupal/recommended-project look_no_hands
$ cd look_no_hands
$ frankenphp php-cli ~/opt/bin/composer require drush/drush
$ cd web
$ frankenphp run

You have a Drupal up and running on a system without PHP installed, you used composer and drush works. While this is out of scope for this issue, it is to give an idea about how it can be used and the relevance of adding a Caddyfile to core. There is a docker way of doing all this, but I wanted to highlight the simplest way it can be made to work.

Proposed resolution

Add a Caddyfile to core, next to .htaccess, taking inspiration from the frankenphp-drupal config.

Remaining tasks

Release notes snippet

TODO

Problem/Motivation

We have a very nice translation system in place that is based on translating fields on entities. For many cases this work very well, but in some cases we need to special care. One of these places are menu items. Right now, when you display menu items, fx with the menu block from core, all menu items are displayed regardless of it being translated or not. This is bad for a few reasons.

• Having a menu with mixed languages is often not desired for site builders / end users
• Different menu blocks can have different requierments (e.g. filter main menu by current language, but not the footer menu)
• It's not possible to hide menu items on certain languages (where they might not be relevant)

Steps to reproduce:

1. Install Drupal with several language and enable menu translation
2. Display the main menu with the core menu block
3. Create some pages with links in the main menu
4. Visit a page with the menu with a UI missing translations for menu items

Actual result:

All the menu items are displayed in the menu, untranslated in the original (or another) language.

Expected result:

Only the translated menu items are displayed in the menu.

Proposed resolution

Add a new API to allow manipulating menu link trees: this has been requested in #3091246: Allow MenuLinkTree manipulators to be altered and #2854013: Allow SystemMenuBlock tree manipulators to be altered too.

Add first usage of this API to Custom Menu Links module to add a new setting that allows limiting the menu block to display menu items for the current language, or those without a specific language (not specified, not applicable).

Remaining tasks

Decide how handle different types of menu items (from code. *.links.menu.yml, from views, from menu link entity). This could potentially be a follow-up issue.

User interface changes

TBD.

API changes

None.

Data model changes

None.

Available work-arounds

• Content Language Access
• Menu Manipulator
• Menu Multilingual
• Menu block current language

Problem/Motivation

1. The block_content module is a block factory. It creates blocks plugins by deriving over reusable Block Content entities (\Drupal\block_content\Entity\BlockContent).
2. The block module mainly offers block placement functionality.

Normally, block_content.module should not need block.module in order to function properly. The blocks produced by block_content can be placed on page by Layout Builder, Display Suite, Panels and even... (core) Block module.

But there are some dependencies on block.module exposed in block_content.module:

• The administer blocks permission.
• The block.admin_display route.
• Unnecessarily installing block in tests
• Redirects for insert/update with BlockContent entity form
• Delete form and delete hook
• ...anything else?

But, I think the above, dependencies were just a compromise, inherited from earlier Drupal versions. I see them only polluting the intra-module relationships by an unneeded dependency.

Proposed resolution

Now that we have decoupled block_content from the block library, I believe we can remove dependency

To be discussed...

• Move block.admin_display route in core? - Believe this is no longer needed
• What about the shared permission? - Believe this is no longer needed

Remaining tasks

• Review outline in #3206952-22: Remove block.module dependency from block_content
• Review proposed MR

User interface changes

None

API changes

Move appropriate customisations to Block or Block Content modules.
Add accommodations to testing in Block Content that relies on block placement to avoid block.module

Data model changes

None

Release notes snippet

@todo

Problem/Motivation

If a block returns a renderable array and the array has direct attibutes they will be "stolen" from the original content and applied to the block itself.

For example a if a block returns something like this:

array(
  '#attributes' => array(
    'class' => array(
      'foo-bar'
    ),
    'data-test' => 'This is just a test'
  ),
  '#markup' => 'This is block content'
);

The rendered HTML will be:

<div id="block-foobartest" class="foo-bar" data-test="This is just a test">
  This is block content.
</div>

instead of:

<div id="block-foobartest">
  <div class="content foo-bar" data-test="This is just a test">
    This is block content.
  </div>
</div>

This is especially bad for blocks that represent forms since none of the form attributes is preserved.

Steps to reproduce

From #10:

• Install the Standard profile.
• Add the Search Form block to a region on the page, somewhere it isn't likely to be given special theming. It's already in the Secondary Menu and while it does exhibit the bug there it's harder to tell due to alterations that are made.
• Visit the site front page.
• Inspect the block's HTML.

Expected result

The form contained in the block should have the attribute drupal-data-selector="search-block-form-###".

Actual result

The block wrapping the form has the expected attribute.

Proposed resolution

Update BlockViewBuilder so that it applies the #wrapper_attributes from a block's content render array to the outer block wrapper instead of the content's #attributes.

Remaining tasks

• Make certain this change doesn't break anything else.
• Review

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Several issues have surfaced recently with the new status page UI that made me start doing research what the different REQUIREMENTS variables are. Below is the current docblock:

 *   - severity: The requirement's result/severity level, one of:
 *     - REQUIREMENT_INFO: For info only.
 *     - REQUIREMENT_OK: The requirement is satisfied.
 *     - REQUIREMENT_WARNING: The requirement failed with a warning.
 *     - REQUIREMENT_ERROR: The requirement failed with an error.

This has lead to a misunderstanding of where these variables should be used, and if these variables are sufficient for the status page. This is very important for the REQUIREMENT_WARNING and REQUIREMENT_ERROR variables, where best practices require that these notices be resolved before a site can launch.

Proposed resolution

TBD - Discuss!

Remaining tasks

Define what each of these requirement notices mean
Decide if there is an area where there are gaps in messaging coverage for these notices
Identify & fix current core modules that contain notices that are miscategorized based on the definitions

User interface changes

If there is an additional notice added to core, we'd need to show it on the status report page. Otherwise, any modules who change their requirement status notices would change on the page.

API changes

N/A

Data model changes

N/A

Problem/Motivation

The @todo refers to the issue #2076085: Resolve the need for a 'title callback' using the route. Its resolution was fixed:

Proposed resolution

Remove the @todo

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

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

It's possible to access any public files/images on the platform without having the right to see it by using the edit user form and setting any file id on the user_picture parameter.

Steps to reproduce

1. Create a node with a picture uploaded in a field, but don't publish the node.
2. Create a new user, without any right. It can't access the article because it's not public.
3. Go to the user edit form at /user/{id}/edit and select any picture. If you look at the request made, this is a POST request to /user/{id}/edit with a parameter user_picture[0][fids]

In this parameter this is the id of the picture you uploaded. But if you replay this request, by using another id like the id of the picture you uploaded in the unpublished article, you will set the user picture with this image.

So by doing that, you can see any pictures on the platform.

And this is because the user edit form only accept pictures, but if you create a form by default with a file upload, you can access all others files, even the unpublished one and those from other users.

Proposed resolution

To be defined what the proposed fix would be, IF this would need a fix.

Remaining tasks

MR

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

TODO

Background information

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

Please credit following users:

• aituglo
• cilefen
• pwolanin
• dokumori
• greggles
• bramdriesen

Problem/Motivation

https://git.drupalcode.org/project/drupal/-/pipelines?page=1&scope=all&r...

HEAD is broken but it's been difficult to spot because the daily tests are only running the lint steps.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet