Problem/Motivation

It is possible for recipes to ship default content for Experience Builder. That default content can contain references to files/images, as entity references to media. But those references are buried in Experience Builder's input data structures, and although those references are powered by entity reference fields, they are encoded in such a way that our default content importer will not know how to handle them (we don't support denormalization on import).

Proposed resolution

It is an unfortunate deficiency that entity reference field items cannot refer to an entity by UUID. I understand that we store the serial integer (or string) target_id for, presumably, database efficiency reasons -- and that makes sense. But it would greatly improve the ability to use default content -- and unblock site template functionality -- if entity reference items had a computed target_uuid property:

// Internally looks up the media item with that UUID and sets the `target_id` property accordingly.
$node->field_hero_image->target_uuid = 'abcdef-123456';

// Loads the entity from its `target_id` property and returns its UUID.
echo $node->field_hero_image->target_uuid;

For simplicity of implementation, the target_id should not be stored -- the data layer remains exactly the same.

User interface changes

None.

Introduced terminology

None.

API changes

All entity reference items will receive a new virtual property.

Data model changes

Not really.

Release notes snippet

TBD.

Problem/Motivation

UpdateKernel does this:

    if (!Settings::get('update_free_access', FALSE) && !$db_update_access->access($account)->isAllowed()) {

and then DbUpdateAccessCheck does this:

    if (Settings::get('update_free_access')) {
      return AccessResult::allowed()->setCacheMaxAge(0);
    }

Steps to reproduce

Proposed resolution

Decide which one is responsible.
Document it.
Remove the check from the other one.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

The situation where I see merging taking a long time is huge GraphQL requests (thousands of entities using https://www.drupal.org/project/graphql).

When GraphQL resolves fields they can add cache metadata to the object that holds metadata for the whole request, and a lot of tags can be added multiple times.
Every call to addCacheTags performs merging of these tags, so if there are already a few thousand tags each added pack of tags will call array_unique and array_merge with thousands of values.

In one of my tests, Cache::mergeTags was called 71503 times and the average amount of tags in these calls was 2099.

I would like to hear if Drupal itself can benefit from optimizing merge, I'm not sure if this is only a GraphQL issue or maybe just my edge case.

Added patch for sure will fail tests and included just if someone would like to do quick profiling.
In my case, it reduces this query https://pastebin.com/ULmCsr3L from 12-13s to 4-5s. (Without Xdebug/profiler, the profiler doesn't show the same relative difference).
Also in the patch I've changed \Drupal\Core\Access\AccessResult::inheritCacheability, Cache::mergeMaxAges call was redundant since it is already done by addCacheableDependency. It seems to be a safe change and can be a different issue, although it doesn't change much in terms of performance.

Steps to reproduce

• Create CacheableMetadata object
• Keep adding tags to it
• Profile

Proposed resolution

Change addCacheTags/Contexts so that merge is only performed when needed, for example only when calling getCacheTags/Contexts

Remaining tasks

User interface changes

None

API changes

TBD

Data model changes

-

Release notes snippet

-

Meta for triage credit, please note: you only need to add a comment for one issue that was triaged and closed, not every one.

Remember to add the tag 'Bug Smash Initiative' to issues that are triaged.

Problem/Motivation

I'm trying to follow the documentation for creating a "custom block" via a block plugin here:
https://www.drupal.org/docs/creating-custom-modules/creating-custom-bloc...

The problem arises when we try to create a custom template for the block:
https://www.drupal.org/docs/creating-custom-modules/creating-custom-bloc...

I've started a discussion on that page, but it hasn't gone anywhere. Hoping this issue will get more eyes.

The problem is that if you follow that documentation, you end up with unnecessary nested block templates.
Your markup will look something like this:

<div class=block block-id--my-block">
  <h2 class="block__title">My Block</h2>
  <div class="block__content">
    <div class="block">
      <div class="block__content">
        // Content here
      </div>
    </div>
  </div>
</div>

When ideally it would look like this:

<div class=block block-id--my-block">
  <h2 class="block__title">My Block</h2>
  <div class="block__content">
    // Content here
  </div>
</div>

Steps to reproduce

Follow this documentation:
https://www.drupal.org/docs/creating-custom-modules/creating-custom-bloc...

Proposed resolution

I have an alternative suggestion, but it has its own unwanted side effects.

MyBlock.php

/**
 * @Block(
 *  id = "my_block",
 *  admin_label = @Translation("My Block"),
 * )
 */
class MyBlock extends BlockBase {

  /**
   * {@inheritdoc}
   */
  public function build() {
    return [
      '#theme' => 'block__my_block',
    ];
  }
}

my_module.module

/**
 * Implements hook_theme().
 */
function my_module_theme($existing, $type, $theme, $path) {
  return [
      'block__my_block' => [
      // @todo: If default 'content' variable is provided contextual
      // links will not render in Layout Builder.
      'variables' => [],
      'template' => 'my-block',
      'path' => $path . '/templates/block',
      'base hook' => 'block'
    ],
  ]
}

The problem with this solution is that passing any value for variables['content'] in my_module_theme() causes contextual links to not render when the block is placed via Layout Builder (and I assume when the block is placed via Block Layout).

Remaining tasks

Document a process for creating a custom block via a block plugin and a corresponding template in a module that does not generate unnecessary markup and also allows contextual links to render.

User interface changes

API changes

Data model changes

Release notes snippet

If PHP's upload_max_filesize is defined to a positive value (say "25M") and post_max_size is set to unlimited ("0"). The file max upload should be set to 25M. However, Drupal's file field description reports a "0 bytes limit".

In order to correct this, file_upload_max_size() should account for post_max_size set to unlimited, "0". This has been introduced in PHP 5.3.2 and PHP 5.2.12.

The other day I installed drupal 11.2.0. Everything seemed fine, but I didn't check the content insertion.
Today I upgraded to 11.2.1, tried to insert some content and the CKEditor toolbar is not present.

In the log file I got this error:

[26-Jun-2025 06:29:35 UTC] PHP Fatal error: Uncaught Error: Failed opening required '/home/hmcpdbiy/public_html/vendor/autoload.php' (include_path='.:/opt/cpanel/ea-php83/root/usr/share/pear') in /home/hmcpdbiy/public_html/autoload.php:15
Stack trace:
#0 /home/hmcpdbiy/public_html/index.php(14): require_once()
#1 {main}
thrown in /home/hmcpdbiy/public_html/autoload.php on line 15

In the status report I got this warning:

The anonymous user does not exist. See the restore the anonymous (user ID 0) user record for more information

Sorry for my ignorance, but I don't know where to insert the hook (I can't use Drush.).

What could be causing this problem?

Thanks and regards

Follow up https://www.drupal.org/forum/support/post-installation/2019-07-31/error-...

Problem/Motivation

When viewing the page of an entity which doesn't have a label, the

navigation:title</component> throws the following:

<code>
Drupal\Core\Render\Component\Exception\InvalidComponentDataException: Unable to render component "navigation:title". A render array or a scalar is expected for the slot "content" when using the render element with the "#slots" property in Drupal\Core\Render\Element\ComponentElement->generateComponentTemplate() (line 118 of core/lib/Drupal/Core/Render/Element/ComponentElement.php).

This comes from PageContext which has:

    $build += [
      [
        '#type' => 'component',
        '#component' => 'navigation:title',
        '#props' => [
          'icon' => 'database',
          'html_tag' => 'span',
          'modifiers' => ['ellipsis', 'xs'],
          'extra_classes' => ['top-bar__title'],
        ],
        '#slots' => [
          'content' => $entity->label(),
        ],
      ],
    ];

This doesn't account for the fact that EntityInterface::label can legitimately return NULL:

  /**
   * Gets the label of the entity.
   *
   * @return string|\Drupal\Core\StringTranslation\TranslatableMarkup|null
   *   The label of the entity, or NULL if there is no label defined.
   */
  public function label();

Steps to reproduce

View an entity without a label entity key/custom label() implementation.

Proposed resolution

Not sure if a slot can validly be defined to allow NULLs, or whether PageContext should perform some checks before attempting to render the component.

Remaining tasks

User interface changes

N/A

Introduced terminology

N/A

API changes

Data model changes

N/A

Release notes snippet

Problem/Motivation

We currently have granular inline block permissions in Drupal, allowing to precisely set which custom block bundles can be created / edited by which user role. Unfortunately, restricting access to certain custom block types doesn't work in Layout Builder that allows to add / edit all or nothing within a layout by design.

Proposed resolution

1. Add a new permission create and edit accessible custom blocks.
2. Restrict custom blocks list in LB to only those accessible ones for users having only that permission and not create and edit custom blocks
3. Alter LB block add, edit and delete route access basing on custom block permissions for the current user and the old / new permission.
4. (Of course) Add automated test coverage.
5. Create a follow-up to remove the old permission and make LB always respect block access logic or at least mark the old permission with restrict access: true

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The revision log message form component is missing from the override layout entity form.

This is happening because Drupal\layout_builder\Form\OverridesEntityForm::init() currently uses Drupal\Core\Entity\Entity\EntityFormDisplay::collectRenderDisplay() with the $default_fallback parameter set to FALSE to load the entity $form_display. This removes the original components of the entity display form which includes the revision_log component.

Proposed resolution

• Update Drupal\layout_builder\Form\OverridesEntityForm::init() to add the revision_log_message_form_item component to the entity $form_display if ContentEntityForm::showRevisionUi() is TRUE.
• Add test(s).

Remaining tasks

Answer #36.2

User interface changes

Revision log message form is displayed on layout override form for entity types that support revisioning.

API changes

None.

Data model changes

None.

Release notes snippet

Update Layout Builder entity overrides form to display revision log message form when appropriate.

Original report by johnwebdev

With #3004536: Move the Layout Builder UI into an entity form for better integration with other content authoring modules and core features now being committed we have the Revision UI in the Layout Builder UI and when you save an override layout a new revision is created.

However, if you untick the "Create new revision" checkbox, a new revision is created anyway.

Secondly, you're not able to write a revision message.

Create a content type with file field.
Create a view and link the title to the file and not the content type.
Exported view .yml file contains

        title:
          id: title
          table: node_field_data
          field: title
          type: file_link
          settings:
            link_to_entity: false

Run the config inspector and it reported an error.
I did not expect it to report an error.

This prevents other profile tests from running, if the content type is part of a module which is required by the installed profile.

Problem/Motivation

According to instructions of comments in settings.php, a different domain can be set in the public file base URL ($settings['file_public_base_url']), which allows the serving of static files to a CDN service.

After enable that setting, inline images uploaded with CKEditor will have an absolute URL in the src attribute. That works as expected. But with the "Restrict images to this site" filter enabled, all uploaded images will fail to display because their src attributes won't start with $base_path anymore.

Steps to reproduce

1. Install Drupal.
2. Setup a web server (like nginx or caddy) to handle TLS access to the site's domain, let's say, "https://mysite.com" for example.)
3. Setup $settings['file_public_base_url'] to an external domain, let's say "https://files.mysite.com", also setup my web server to serve file from Drupal's files folder under that domain.
4. Enable modules like CKEditor, create a text format with CKEditor and inline-images uploads enabled.
5. Enable "Restrict images to this site" filter.
6. Add an article with inline-images. These images look fine in the CKEditor, but fail to display after I publish the article.

Proposed resolution

While checking function in filter.module checks only whether or not the src attribute starts with $base_path, and whether or not the file is reachable (by running getimagesize()), I think the function should check the src attribute in a detailed manner, to make sure the filter can work with other functions of Drupal like public file base URL (or maybe image styles or so).

Problem/Motivation

why removed class tags with update from core ?
EG.
Bevor update To 11.2.*

<div class="messages__wrapper">
  <div class="messages messages--status" role="status" data-drupal-message-id="status-845490963532364" data-drupal-message-type="status" aria-label="Statusmeldung">Betrieb im Wartungsmodus. <a href="/admin/config/development/maintenance">Online gehen.</a>
  </div>
</div>

after update to 11.2.*
classes and data id are gone

<div data-drupal-messages="">
  <div role="contentinfo" aria-label="Statusmeldung">
              <h2 class="visually-hidden">Statusmeldung</h2>
              Betrieb im Wartungsmodus. <a href="/admin/config/development/maintenance">Online gehen.</a>
          </div>
</div>

used files
core/modules/system/templates/status-messages.html.twig

ist very nerving if you have made the styles an then yoyu remove or changes wit out messages the attributest

Problem/Motivation

When we pass the null value to the optional property, we receive the following error
NULL value found, but a number or an object is required. This may be because the property is empty instead of having data present.

But we shouldn't receive this kind of error since null is the expected value for the optional field. The fix for it is to add a "null" type to the component, but I guess this should be done by default.

Steps to reproduce

1. Run the composer require justinrainbow/json-schema command. We need a validator so that the \Drupal\Core\Theme\Component\ComponentValidator::validateProps can run its logic.

2. Create a component and add an optional property to it, for example

$schema: https://git.drupalcode.org/project/sdc/-/raw/1.x/src/metadata.schema.json
version: 1.0
name: Error
status: stable
props:
  properties:
    text:
      type: string
      title: Text

3. Render new component:

    $build = [
      '#type' => 'component',
      '#component' => 'module:component_name',
      '#props' => [
        'text' => NULL,
      ]
    ];

Proposed resolution

Automatically add null type to all non-require poperties during the validation.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

HTMX swap strategies beforebegin and afterend insert the new content outside the target. When combined with the default target property, this results in failed behaviors attachment.

In htmx-assets.js we trigger Drupal.behaviors with this code block:

  // Trigger the Drupal processing once all assets have been loaded.
  // @see https://htmx.org/events/#htmx:afterSettle
  htmx.on('htmx:afterSettle', ({ detail }) => {
    (Drupal.htmx.assetsPromises.get(detail.xhr) || Promise.resolve()).then(
      () => {
        htmx.trigger(detail.elt, 'htmx:drupal:load');
        // This should be automatic but don't wait for the garbage collector.
        Drupal.htmx.assetsPromises.delete(detail.xhr);
      },
    );
  });

When this markup is used:

<button class="button" name="replace" data-hx-get="/htmx-test-attachments/replace" data-hx-select="div.dropbutton-wrapper" data-hx-swap="afterend  ignoreTitle:true">Click this</button>

The default target is the element issuing the request, which is the button, and the dropdown markup is correctly inserted after the button. But the button is passed in the call to htmx.trigger which becomes the context for Drupal.behaviors.dropButton which finds no dropbutton in the button tag.

Proposed resolution

Change detail.elt to detail.elt.parentNode to account for these swap strategies.

Remaining tasks

Add test cases for these swap strategies.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

In the mobile breakpoint (< 1024px), the Navigation sidebar has some spacing issues at the top where the logo, close button and back button sit.

Steps to reproduce

• Install Drupal standard profile
• Enable Navigation module
• Adjust your browser to the mobile viewport (< 1024px)
• Expand the Navigation sidebar

Expected result

The spacing should follow the same spacing that is used at the desktop breakpoint, however, the spacing is pretty squishy, which doesn't make room for the hover / focus styles:

In addition, when you click on a menu item with children and the drawer opens, the Back link and Close link hover styles are cut off:

Proposed resolution

Adjust spacing to match the Desktop breakpoint.

Remaining tasks

MR
Testing and review.

Problem/Motivation

Since #3517317: SDC slots not being validated against json config schema landed in 11.1.7, empty slots, represented in Drupal by an empty array, give an error in SDCs when validated by ComponentValidator:

[slots.test-slot] Array value found, but an object is required

As soon as the slot contains any key-value pairs, this error goes away. This is because this method call converts associative arrays to objects, but leaves empty arrays as arrays:

    $definition_object = Validator::arrayToObjectRecursive($definition);

We already have some code to handle this for props but not slots:

    // If there are no props, force casting to object instead of array.
    if (($schema['properties'] ?? NULL) === []) {
      $schema['properties'] = new \stdClass();
    }

Steps to reproduce

Proposed resolution

Add similar defensive code for slots.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

After #2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it fix, FileUriFormatter is not returning absolute URL.
As per the change record file_create_url() is supposed to be moved to \Drupal::service('file_url_generator')->generateAbsoluteString($uri)

Instead of that, it is updated with $this->fileUrlGenerator->generateString($uri)

That sounds the root cause of the regression.

Steps to reproduce

Check the FileUriFormatter before #2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it and after the fix.

Proposed resolution

Fix the incorrect change and replace with correct method.

Remaining tasks

Needs review

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Original report by @joakland

Following upgrade to Drupal 9.3.0, checking the "Display the file download URI" for a "File: URI" field in Views no longer displays an absolute path; now it displays a relative path.

Problem/Motivation

/**
 * Tests access to user autocompletion and verify the correct results.
 */
function testUserAutocomplete() {
  $this->drupalLogin($this->account);
  $this->drupalGet('user/autocomplete', array('query' => array('q' => $this->account->getUsername())));
  $this->assertRaw($this->account->getUsername());
  $this->assertNoText('registry initialized', 'The registry was not initialized');
}

The path user/autocomplete does not exist in Drupal 8 for a long time. The test still passes because user/autocomplete is found in drupalSettings.path.currentQuery.

Steps to reproduce

Proposed resolution

Search for all remaining usages of the route or string and decide what to do with each one.

Remaining tasks

Patch
Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet