Problem/Motivation

Error message

TypeError: array_filter(): Argument #1 ($array) must be of type array, null given in array_filter() (line 723 of /app/web/core/modules/views/src/Plugin/views/field/EntityField.php).

Also, confirmed in Drupal 10.4 and Drupal 11.0.

Steps to reproduce

• Add node
• Create a view to display node ids with aggregation
• Set aggregation settings of ID field in the view to COUNT
• Save View
• Change aggregation settings of ID field in the view to MAX results in AJAX error

Proposed resolution

TBA

Remaining tasks

NA

User interface changes

NA

Introduced terminology

NA

API changes

NA

Data model changes

NA

Release notes snippet

TBA

Problem/Motivation

    Drupal\Tests\ckeditor5\FunctionalJavascript\ImageUrlProviderTest::testResize
    with data set "Image resize is enabled" (true)
    Failed asserting that false is identical to true.
    
    /builds/project/drupal/core/modules/ckeditor5/tests/src/FunctionalJavascript/ImageTestProviderTrait.php:285
    
    FAILURES!

https://git.drupalcode.org/project/drupal/-/jobs/3214752

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

The fieldset element can be used to indent a conditional field ("sub-field"), see for example the Twig debug form:

(from #3278493: Make it easier for theme builders to enable Twig debugging and disable render cache)

... so it feels like a sub-element, lower in the hierarchy, even if that was never the intended use.

The question is, what is the best method to indent a form element to the right, to visualize the hierarchy, and signify that this element is at a lower level?

Proposed resolution

Maybe we should consider adding styling to dependent fields and similar fields at a lower levels, and indent them to the right, to signify their hierarchical position?

---

Originally posted as a Claro Compact issue:

Fieldset texts are too far to the left, and need to be moved to the right, to align with the element above.

Steps to reproduce

1. Visit /admin/config/development/settings
2. Click "Twig development mode"
3. See that the header in the opened fieldset ("Twig development mode") is not indented enough, and doesn't align with the elements above

Claro

Fieldset texts are correctly aligned in Claro.

Claro Compact

Fieldset texts are too far to the left in Claro Compact.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

In #3437499: Use placeholdering for more blocks and on Slack we (@berdir, @catch and myself) did some digging and came to the conclusion that the single cache lookups of placeholders no longer makes sense in Renderer. We now have a ::getMultiple() method on the render cache and we know we're going to look all of the placeholders up in one go in CachedStrategy.

So why don't we skip the retrieving of placeholders in Renderer altogether and allow CachedStrategy to do that? The ones we didn't find will still end up getting rendered live, but at least this way we went to the cache once instead of for every placeholder individually.

Steps to reproduce

N/A, check metrics after the change

Proposed resolution

Skip single placeholder cache GETs and offload to getMultiple()

Remaining tasks

Investigate and discuss potential fall-out from moving this bit around

User interface changes

N/A

Introduced terminology

For discussion in this issue:

PRC

PlaceholderingRenderCache

VC

VariationCache

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Follow up for #1498674: Refactor node properties to multilingual

Postponed on

• #1498674: Refactor node properties to multilingual
• #1497374: Switch from Field-based storage to Entity-based storage
• #2004330: [META] Convert queries to entity field query v2
• #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions

Problem/Motivation

There was not much room for optimization in #1498674: Refactor node properties to multilingual.

However the following issues make it possible to do some optimization:

• #1497374: Switch from Field-based storage to Entity-based storage
• #2004330: [META] Convert queries to entity field query v2
• #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions

They open up the possibility for an interesting proposed resolution.

Performance regressions in 1498674 effected both single language sites and sites with multiple languages. The proposed improvements here will confine the performance regression to multilingual environments, improving (restoring) single language site performance.

Proposed resolution

Once the SQL storage is under the full control of the entity system we can automatically alter primary keys and queries depending on whether we are in a monolingual or multilingual environment. We have a couple of recurring patterns to switch from a monolingual query to a multilingual one, which should not be hard to automate.

Drop composite primary key and set it to just nid as primary key making the monolingual query, for example:
SELECT title FROM {node_field_data} WHERE status = 1 AND promote = 1 ORDER BY created
as performant as HEAD was before 1498674.

Remaining tasks

Open follow-ups for each performance improvement that is not automated.
Consider doing a meta which would have an issue for each query.
Identify the patterns. List examples.
Automate (write a script to use the patterns identified and change the code?) the improvements.

User interface changes

None.

API changes

None.

Original report in issue summary of #1498674: Refactor node properties to multilingual

there is not much room for optimization in this issue, however #1497374: Switch from Field-based storage to Entity-based storage, the contextual conversion of entity queries to EFQ2 and #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions open up for some interesting scenario: once the SQL storage is under the full control of the entity system we can automatically alter primary keys and queries depending on whether we are in a monolingual or multilingual environment. We have a couple of recurring patterns to switch from a monolingual query to a multilingual one, which should not be hard to automate. This would let us confine the performance regression to multilingual environments, which should be a fair compromise.

Problem/Motivation

After inserting EBT block via layout builder, contextual buttons for edit/delete.. missing.

Steps to reproduce

Install some EBT modules:
https://www.drupal.org/project/ebt_core
https://www.drupal.org/project/ebt_basic_button

Proposed resolution

Change code in layout-builder.js that is resposible for hiding everything in block that isn't contextual link related.

/* $element.children(':not([data-contextual-id])').hide(0); */

// update:
const contextual_lookup = $element.children().find('[data-contextual-id]');
const has_child_contain_contextual = !!(contextual_lookup.length);
if (has_child_contain_contextual == true) {
contextual_lookup.siblings().hide();
contextual_lookup.parent().siblings().hide();
} else {
$element.children(':not([data-contextual-id])').hide(0);
}

When we find a spam post, a node admin can delete it but needs a user admin to ban the user. And it takes too many clicks. Esp for book pages. This here adds a checkbox to the node delete form -- one click block.

Problem/Motivation

The logo in olivero is hard-coded. All logos in core are either hard-coded or we _only_ render the image path. Never dimensions. We should. And we might want a holistic solution that passes from theme config the logo and the logo dimensions. For good measure, we could even add loading="eager". That's the default, but adding it is more explicit and instructive.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The variable to render the theme logo is now <code>logo. The variable site_logo for the system branding block has been deprecated.Module and theme maintainers should update any usages of site_logo to the new variablelogo.

Problem/Motivation

The UserSession class has a @todo to make all properties protected. The only remaining one in 11.x is the name property.

This issue makes the name property protected and deprecates calling the function directly. This should cause no BC breaks until the deprecation layer is removed in 12.x

Steps to reproduce

Proposed resolution

Make the name property protected
Add a BC layer with __get & __isset

Remaining tasks

Open MR
Review
Merge

API changes

UserSession::name is now protected.

Release notes snippet

In today's episode of "there's an hour of my life I'll never get back..."

In the Spark installation profile, I attempted to create an "About Us" page in the little demo module that loads as part of the install profile: #1722802: Add an "About us" page Simple enough task, right? BZZT. WRONG. Why?

Because as dman so eloquently lays out:

spark_demo is listed as a requirement for spark : so will run its install before the spark install.
But it's the spark.install that creates a 'page' content type after that.

If I'd gotten an error such as "Invalid node type 'page'" when I called this function, I could maybe have figured this out. But with it silently doing nothing, I was completely at a loss, and dman saved my bacon.

Let's be nicer to people in this situation. :)

Hiding the field in the "Manage Form Display" editing interface does not work. Dragging the field to the hidden section and saving the form is useless.

Problem/Motivation

Sometimes we want to move a class from one place to a different place. An example is in #3502602: Remove non-formatter plugins out of the file field formatter directory.

There are two solutions we've used in the past:

1. Leave the old class in place, usually extending the new class, add @deprecated and trigger a deprecation. When we want to move something to avoid it being scanned for discovery, this does not help us until the next major release.

2. Add a call to class_alias - this has to be manually specified in boostrap.inc and can never be removed.

I think we might be able to handle both deprecation and aliasing in a classloader.

Steps to reproduce

Proposed resolution

Something like:

1. Create a new classloader

2. This classloader allows a $movedClasses array to be populated via a setter.

3. The moved classes array is keyed by the moved class, the value is an array of the new classname, the deprecated from version, the removed version (latter two could be optional).

4. in DrupalKernel, register this as an extra classloader, it should run after the composer classloader so it has zero runtime overhead.

5. When the composer classloader can't find a class, PHP falls back to our classloader. Our classloader checks the $movedClasses property, if the class is in there, it calls class_alias($old_class, $new_class, TRUE);

If this works, we could then look at populating the moved classes array, potentially from a container parameter so that it's possible for core and contrib modules to add to it.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Beta phase evaluation

Problem/Motivation

Node forms are in Drupal\node namespace instead of Drupal\node\Form. That is inconsistent, and I can guess this is the first place anyone would look for Form examples in core.

Proposed resolution

Move them to Drupal\node\Form.

Remaining tasks

Review.

User interface changes

None.

API changes

Drupal\node\NodeForm is at Drupal\node\Form\NodeForm
Drupal\node\NodeTypeForm is at Drupal\node\Form\NodeTypeForm

As the title suggests, allowing users to "checkout" content for editing.

If you have a large site and a lot of users, it makes sense to prevent users from editing files when others are working on them.

The current system can become frustrating to non-drupalers. Most users expect the web applications they use to do this. An actual example is Joomla!.

I would add the workflow:

1. User clicks 'edit' tab, system verifies it is not locked.
2. If NID is locked, print message explaining the lock, else show edit tab.
3. Administrator can set a "max edit time" directive to unlock "forgotten" locks after x amount of time.

Problem/Motivation

While presenting #3318110: [meta] Reorganize Block items in the administration menu to colleagues for feedback, one person noted how they quite often find themselves spending time jumping around to different parts of the admin interface.

For instance, after adding a field on a content type, then configuring it, they have to jump over from Structure to Content to see/test their changes; They then jump back to Structure to make additional changes or add another field, and if they have multiple fields to add/change, they find themselves repeatedly clicking through multiple screens to get from one deep part of the admin UI to another.

I gave this problem some thought and came to the conclusion that, while we currently have a way to navigate the hierarchy of the admin UI, we don't currently have a consistent way to jump between related parts of the admin UI.

There are some cases where related parts of the admin UI are deep-linked between each other. For example, the Block Types collection provides a link to the Custom Block Library, however this link is displayed within a short paragraph of help text at the top of the list, and so it may be easy to miss.

In #2987964: Move custom block types admin link to admin/structure we are proposing to remove this paragraph because, in the interest of consistency, none of the other collection pages under Structure provide such help text, and so it seemed better to be consistent, and instead solve the problem more holistically.

The intention of this issue is to provide a space to discuss this problem in more detail and propose some solutions.

Proposed resolution

I presented the problem at #3323771: Drupal Usability Meeting 2022-12-02.

During the usability meeting I proposed an idea of a "related links" or "quick links" pattern for the admin UI. This could be displayed at the bottom of admin UI screens, so that it is non-intrusive but still noticeable.

The key advantage of such a pattern is that it would provide a consistent approach for deep-linking across relevant parts of the admin UI. Such a component could even link to relevant help topics.

During the meeting we discussed that such links should be clearly visible: unlike the Block Content example, these links should not be displayed in-line with other text and should instead be presented in a list and/or using a button style. This would help them stand out and be easily discoverable.

During the meeting we also discussed other possible solutions:

• Integrating elements of the Admin Toolbar module, to make it easier to quickly jump through the menu tree in the toolbar.
• The admin UI may benefit from a way to quick search for different screens/settings, the Coffee module does this well by providing a MacOS Finder style search overlay, which can be quickly brough up using a keyboard shortcut.
• The Gin admin theme, provides new styles for the toolbar; Most notably a vertical style which displays the toolbar down the left side of the screen. Anecdotal evidence suggests this is popular, based on the fact that this is the default style when using Gin and Gin is currently in use on over 22K Drupal 8/9/10 sites.
• We also noted that the existing Core Toolbar has a vertical tray style, which we agreed was easier to navigate quickly because it allows expanding out the hierarchy without needing to click through different screens. And when the user clicks onto a screen, the hierarchy stays expanded at the level the user has navigated to. We also noted that this is not the default tray view and aside from a small button on the far-right of the toolbar, it may not be obvious to many users that this view of the toolbar tray exists.

This issue does not need to solve this problem, it can be used as a place to discuss the various potential solutions, and could evolve into a meta issue.

It should also be noted that while #2755613: Restructure the admin interface Information Architecture does exist, it's focus is more about reorganising the structure, and regardless of the outcomes we would likely still end up with a hierarchy which would benefit from more than one approach to navigation.

Remaining tasks

• Discuss the possible solutions, potentially opening child issues against Drupal Core for any quick fixes that we can identify.
• Gather examples from other applications (not just Content Management Systems) and other systems which have a large number of settings screens (for example Windows and MacOS), to understand what approaches work well and what we can learn from them.

User interface changes

API changes

Data model changes

Problem/Motivation

Don't fully understand why yet, but i noticed on our project with redis monitor that there are quite a few identical cache lookups:

"HGETALL""prefix:data:css:THEME_NAMEenaxHQwg5UBhW9FfRUylgqlvQ43K67H9VuTW3QXt27iZU1""HGETALL""prefix:data:js:THEME_NAMEen:D9AaXzT3MlnOQcjEJMKZEOqJpT9sVkpufRFf2FceqFM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM11""HGETALL""prefix:data:js:THEME_NAMEen:D9AaXzT3MlnOQcjEJMKZEOqJpT9sVkpufRFf2FceqFM11"

There are two unique hashes, the D9A... one is actually all-the-libraries, the NXh hash is an empty array of $libraries_to_load and settings.

Not sure how common this situation is, this also also on 10.4, haven't verified yet if 11.x changes anything.

I'm not sure what this is doing exactly with those assets. Took me a while to find where exactly it's looping, it's in \Drupal\big_pipe\Render\BigPipe::sendNoJsPlaceholders(), which has 23 fragments, all or most seem to be toolbar parts (classic toolbar with admin_toolbar).

Not sure what should be done in this scenario. statically cache the cache? if it's all identical, do we even need to process it or could we somehow return early somewhere?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

At present Drupal has a file usage API. This is critical to things like private file access and garbage collection of files.
Unfortunately, it relies on modules recording and removing usage entries and cannot be relied upon to provide a source of truth.

There are a wide number of bugs in core that pertain to invalid file usage data and we've had security issues and critical data loss issues as a result of this.

Some examples include:

• #2801777: Give users the option to prevent drupal from automatically marking unused files as temporary
• #2461845: Private files that are no longer attached to an entity should not suddenly become accessible to people who couldn't see them before
• #1452100: Private file download returns access denied, when file attached to revision other than current
• #2708411: [PP-1] editor.module's editor_file_reference filter not tracking file usage correctly for translations

Automatic file deletion in core had to be disabled due to persistent and impossible to resolve data loss issues:

#2821423: Dealing with unexpected file deletion due to incorrect file usage (see also all the linked and related issues of that issue, many of which are unresolved).

In addition, this API is limited to file usage, but Drupal's data model allows much richer entity relationships.

For example, the file usage API may record that a media entity makes use of a file. But content editors need to know if any other content entities make use of that media entity before they can decide if the file is in fact no longer in use.

Proposed resolution

Adapt the entity usage module for core as a low level API.
It provides the following features.

• A configurable usage API allowing an entity type to be flagged as a source or target of a usage record
• Support for revisions
• Support for translations
• Calculated at save time so cheap to query at run time
• A plugin based API allowing usage to be determined in a myriad of ways - e.g. via an entity reference, via a link in HTML, via an image tag, via an inline block in layout builder and many more
• The ability to reload the entire usage dataset via batch (ala node access rebuild) to ensure the data is accurate

With Entity Usage, a content editor can traverse the entity relationship to ascertain that e.g. image file A is attached to media entity B which is referenced from block content C which is used inline in the layout of node D. This allows the content editor to get meaningful usage data.

Remaining tasks

Agree this would be a useful feature to add to core, move to the core issue queue

User interface changes

API changes

Data model changes

Problem/Motivation

#3436146: Introduce a list of "frequent cache tags" to reduce lookup query amount adds preloading for cache tags.

I think we can make use of this in the cache backend itself, to preload tags when multiple cache items are requested at once.

This doesn't kick in very often with core performance tests but it's visible in the Umami authenticated test.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

A large amount of our time during the Drupal 10 readiness effort was around semantic version discussions. Maintainers of contributed projects were creating new major version releases to add Drupal 10 compatibility while dropping Drupal 9 compatibility. That may technically follow semantic versioning guidelines but it adds profound complications for sites updating to a new Drupal core version.

For example, a site with a Composer requirement of "drupal/some_contrib_module": "^1.0" will have to explicitly change the version constraint if drupal/some_contrib_module releases version 2.0. In contrast, if drupal/some_contrib_module releases a new 1.x.x version when providing compatibility for the next version of Drupal core, sites trying to update Drupal core don't need to audit what's changed in drupal/some_contrib_module.

Therefore, contrib project maintainers should endeavor avoid new major versions except when absolutely necessary: (A) a code change introduces backwards compatibility breaking changes in the module itself or (B) a code change must drop backwards compatibility with a *supported* version of Drupal core. We shouldn't need to document (A), since that is covered by semver. We should establish a guideline for (B) -- i.e., for contributed projects and semantic versioning specific to Drupal core support.

Reference material

Derived from https://mglaman.dev/blog/drupal-module-semantic-versioning-drupal-core-s...

Proposed resolution

A contributed project should release a new major version when its code changes the relationship to Drupal core by:

• Dropping compatibility for a currently supported version of Drupal core
• Introducing breaking changes from Symfony or another dependency where backward compatibility (such as adding types to method signatures) cannot be supported.
• Introducing impossible dependency resolution (such as the module requiring Guzzle 7 when a previous Drupal core version required Guzzle 6).

A contributed project should release a new minor version when its code changes the relationship to Drupal core by:

• Dropping compatibility with an unsupported version of Drupal core.

A contributed project should release a new patch version when its code changes the relationship to Drupal core by:

• Adding compatibility with a new Drupal core major version while maintaining backward compatibility for all previously supported versions

Remaining tasks

Decide where the documentation will fit into the existing docs. Add link.
Title of the page
Refine and agree on the proposed text

Problem/Motivation

Look at this code, this is an inconsistent mess:

<?php print render($title_prefix); ?>
  <?php if (!$page): ?>
  <h2<?php print $title_attributes; ?>><a href="<?php print $node_url; ?>" rel="bookmark"><?php print $label; ?></a></h2>
  <?php endif; ?>
  <?php print render($title_suffix); ?> 

Proposed resolution

I understand the need to call the label() method on the node object instead of directly referencing the $node->title, but I don't understand why that needs to trickle all the way down to the theme layer. Can we please be consistent with our variable names and call this a title? We can preprocess it in, or do it as part of the Twig __to_string() method on rendering a node.title but in the template file we should really be calling this a title.

Alternatively, we could rename everything else in these templates that contains "title" into a label. label_prefix, label_suffix, label_attributes.

Remaining tasks

- make our templates consistent

User interface changes

- none

API changes

- none

Related Issues

#1939224: Change block "label" so that it's called a title like everything else in the template file (and all other template files)
#1591806: Change block "subject" so that it's called a (admin_)label like everything else on the theme layer
#1591830: Change comment "subject" so that it's called a title like everything else in the template file (and all other template files)
#1825216: Name variables consistently across all templates (preprocess)
#2004966: Markup and variable cleanup for titles and attributes in all templates