Problem/Motivation

The security advisories list contains many fixed CSRF vulnerabilities. It proves that it is easy to forget to add CSRF protection on GET routes that do sensitive actions.

It is easy to create a route and simply forget to add CSRF protection to it.

Steps to reproduce

1. Create a GET route that deletes an entity or changes a config value without a confirmation form.
2. Don't add the _csrf_token requirement.
3. Your route is vulnerable to CSRF attacks.

Proposed resolution

Adding CSRF tokens to every GET route would not be a good idea, it is only needed on routes that modify config or entities.
But maybe we could make it required to specify explicitly on each route whether it needs CSRF token. (Similar for what we do for access checks on entity queries.)
This would force developers to think about it.

(Routes that return a form are already protected from CSRF attacks automatically and would not need this.)

An alternative approach would be to forbid sensitives actions in GET requests (#3384167: CSRF tokens in GET requests can be leaked and reused; stop encouraging server-site state changes with GET requests) but I don't think this would be easy to do.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

The link_uri migrate process plugin provided by the core menu_link_content module provides handling for links referencing the special <front> and <nolink> routes but does not currently support the special <button> route added in 8.8 (https://www.drupal.org/node/3053689).

When migrating into menu links url field I receive the following error.

 -------------- ------------------- ------- --------------------------------------------------------------- 
  Source ID(s)   Destination ID(s)   Level   Message                                                        
 -------------- ------------------- ------- --------------------------------------------------------------- 
  1                                  1       The path "internal:/<button>" failed validation.               

Steps to reproduce

in my migration_name.yml file I am using the menu_link_content process

process:
  bundle: menu_link_content
  title: title
  menu_name: menu
  # Handle external urls or url aliases.
  'link/uri':
    plugin: link_uri
    source: urlpath

In my source migration_name.json file

{
  "menu_links": [
    {
      "link_id": "1",
      "parent_link_id": "0",
      "menu": "az-resource-menu",
      "title": "Resources",
      "urlpath": "<button>",
      "external": false,
      "expanded": true,
      "enabled": true,
      "weight": "1"
    },

Proposed resolution

Add the supported special route to https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/modules/menu...

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Add the ability to migrate the following menu item types <button>, <none>,''.

Problem/Motivation

When an editor adds a media item via the modal and encounters an error, for example skipping the required Alternative Text field, the error message displays on the page, behind the modal.

This causes usability issues since the error message is obscured by the modal, leaving the editor confused as to why the form does not save.

Steps to reproduce

1. Add a media item via a modal, eg: edit an existing Image media item.
2. Save the form without including alternative text.

Watch this video as an example.

Proposed resolution

Display error messages within the modal.

Remaining tasks

1. Get core maintainer approval of the resolution
2. Implement the resolution
3. Test
4. Deploy

User interface changes

Error messages from a modal form would display within the modal, rather than on the page the modal appears from.

API changes

None

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

The Navigation Top Bar was hidden from the UI as it was is alpha experimental in #3401826: [PLAN] Top contextual bar.

Proposed resolution

The Navigation Top Bar has closed all the Stable blockers and it's ready to be able to be enabled again via the UI. So I'm creating this issue to revert #3401826: [PLAN] Top contextual bar and make sure that the the Top Bar is enabled when the Navigation is.

User interface changes

The Navigation Top Bar will be enabled when the Navigation is, so it always adds the Top Bar.

Release notes snippet

Problem/Motivation

Similar issue as #2940755: block_content block derivatives do not scale to thousands of block_content entities but a different approach to a fix

Steps to reproduce

Have 1000s of reusable block content entities.
See your site die with OOM on plugin definition rebuild.

Proposed resolution

Use an aggregate query instead of ::loadMultiple

Merge request link

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Config inspector report provides error with a missing schema for fields and filters when aggregation in views is on.

Steps to reproduce

1) Install Drupal 11.
2) Install and enable the config_inspector contributed module.
3) Create a Views listing with nodes (i.e. a "Content" listing) using all defaults.
4) Enable "Use aggregation" in the views display under the Advanced settings in the Other section.
5) There should already exist a "Content:Title" field with aggregation set to "Group results". If it isn't there, add it.
6) Add a "Content: ID" field with aggregation set to "Count". The fields should be as seen in this screenshot:

7) Save the View.
8) Go to /admin/reports/config-inspector and check the "Only show errors" box.
9) See your view listed in the report, showing 7 errors under the Schema heading.
10) Click on the List link for your view, then scroll down the page until you see the errors as seen in the screenshot below.
11) Applying the MR and running database updates removes the schema errors in the configuration inspector report.

Proposed resolution

Provide a merge request that fixes this issue.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

On Drupal 10.4.3, when I am using the batch process to process anything, and I have the JavaScript Aggregation on, I get the following JavaScript errors:

Uncaught TypeError: Cannot read properties of undefined (reading 'prototype')
Uncaught TypeError: Drupal.ProgressBar is not a constructor

These errors do not appear when aggregation is off.

Steps to reproduce

Install Drupal 10.4.3
Turn on JavaScript aggregation.
Run a batch process.
Batch process will not run, showing these JavaScript errors.
Turn off JavaScript aggregation.
Run a batch process.
Batch process will run as expected.

Problem/Motivation

See https://git.drupalcode.org/issue/drupal-3426302/-/jobs/4376040 for an example.

I think this is packagist/github related which might be a general gitlab issue #3445532: Random HTTP timeouts for GitLab CI jobs, but would be good to pin down if we can.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

I have an entity query_alter that was adding a cacheable metadata to a jsonapi response and before it was working and now I get: `LogicException: The controller result claims to be providing relevant cache metadata`, any ideas? I am altering the json query by a passed argument on the url and I want that resource to be be varied by that url argument, but it seems I should not be adding it on the query alterer now, which would be the proper way?

I am/was doing this on

function microsite_query_entity_query_alter(Drupal\Core\Database\Query\AlterableInterface $query) {
  $request = \Drupal::requestStack()->getCurrentRequest();
  $renderer = \Drupal::service('renderer');
  if ($request->isMethodCacheable() && $renderer->hasRenderContext()) {
    $build = ['#cache' => ['contexts' => ['url.query_args:microsite_site']]];
    $renderer->render($build);
  }
}

This stopped to work after recent upgrades to core/jsonapi.

@wimleers asked

What code path in JSON:API is triggering your code to be executed? JSON:API should have the appropriate “run entity queries in a render context so it can detect bubbled cacheability and associate it with the resulting response” logic in place. If it doesn’t, that’d be a bug.

I answered: Does this answer your question https://pastebin.com/T0RvpbX3? The first path I actually now see that it’s captured and bubbled up, however the others (one per media entity) are not. Please ignore the `microsite` controller. It’s currently a bare decorator for the jsonapi controller service to add the cache context on an overridden `buildWrappedResponse()` (PoC from yesterday), but I rather not have to do something like this.

He said yes and asked to fill in a ticket, so here it is.

In the end I removed the decorator end ended up replacing the whole jsonapi.entity_resource service with the same `buildWrappedResponse()` overridden to add my needed context but not to have to override also the constructor on the decorator.

From Slack: https://drupal.slack.com/archives/C6DJEP1EK/p1556217296004400 (likely to be lost in the backscroll noise but here for reference)

Dear Drupal Community,

I am writing to request an upgrade or update related to the replacement of certain PHP dangerous functions within the Drupal core and contributed modules. As part of our ongoing efforts to improve security and adhere to modern best practices, I believe we can take further steps to replace or mitigate the use of potentially risky functions in the platform. Specifically, the following functions are of concern:

exec()
shell_exec()
passthru()
escapeshellarg()
escapeshellcmd()
proc_open()
proc_close()
popen()
ini_set()
phpinfo()

These functions are well-known to be vulnerable to command injection attacks and remote code execution risks, particularly if user input is not adequately sanitized. While some of these functions are still used in specific scenarios, I believe that we could either:

Replace them with more secure alternatives (such as the Symfony Process Component or native Drupal APIs).
Deprecate their use entirely in favor of safer practices.
Add additional safeguards for any existing functionality that relies on these functions.

I would like to suggest reviewing the Drupal core and major contributed modules to identify and replace any instances of these dangerous functions. This would significantly enhance the platform’s security, especially in the context of modern PHP development.

Additionally, if there are any ongoing efforts or discussions about upgrading or refactoring this aspect of Drupal, I would love to contribute or be informed of the progress.

Can you specify the table collation when creating a table via db_create_table() (or hook_schema())? I didn't find any documentation (or issue) on this, but I hope it is possible? Otherwise, this is definitely a feature request for D8.

Problem/Motivation

Explanation: Some full and provisional members of the Drupal Security Team meet fortnightly to triage and discuss private core security issues. These meetings are essential to core security process and should be credited like other contribution meetings.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

This meeting takes place every Friday at 14:00 UTC (currently 6:00am PT, 9:00am ET). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.

List of Slack users to ping 10 minutes before the meeting:
@worldlinemine, @lauriii, @AaronMcHale, @anmolgoyal74, @Ravi, @shaal, @ckrina, @simohell, @gauravvv, @Quynh, @yoroy, @andrei.zvonkov, @Regu.pl, @amazingrando

This list gets copied to the issue for the next meeting. If that has already happened, then go to that issue to add/remove yourself to/from the list.

Recording of this week's meeting: TODO

Rough transcript of this week's meeting: Drupal Usability Meeting - 2025-02-28.txt

We discussed the following issue:

• [#TODO]

NR and RTBC issues marked Needs usability review.

The group is actively tracking progress on these issues:

• #3318110: [meta] Reorganize Block items in the administration menu
• #2860419: [Meta] Appearance page is too long and confusing
• #2985168: [PP-1] Allow media items to be edited in a modal when using the field widget with notes:
  • @AaronMcHale: Issue could use some guidance.
    In comment #109 the issue was marked as postponed for needing input from UX, accessibility and media initiative. Apparently there are some outstanding UX/accessibility questions (but I'm not sure what they are). This was echoed in comment #111.
    Comment #144 is asking what is needed to move the issue along (the postponed state seems to be causing some delays/confusion as to how to proceed).
    Perhaps we can at least take a look at what the issue is doing and provide some recommendations/guidance on how it could be implemented.
• #2704931: Provide Drupal root path on file system admin form
• #3163197: Allow hiding configured blocks in layout builder
• #2916876: Add visibility control conditions to blocks within Layout Builder
• #3247064: Error message presented when a BrokenPostRequestException is fired on AJAX submission can be misleading
• #3262935: Link field validation constraints don't give enough detail
• #3386762: Use modals in field creation and field edit flow

Remaining tasks

1. Add issue credits for the participants.
2. Add the issue(s) we discussed to the issue summary and as related issues.
3. Add a rough transcript.
4. Add a link to the recording on YouTube.
5. Comment on the issue(s) we discussed.

Problem/Motivation

When there are many items in the toolbar of CKEditor5, the buttons are relegated into a drop-down menu. However, depending on how many items there are, this can get clipped in Drupal's off-canvas:

Steps to reproduce

1. Enable the Layout Builder, Node and Block Content modules.
2. Create a block type that has a formatted text field.
3. Create a CKEditor5 editor configuration with many buttons.
4. Create a node type and enable the layout builder.
5. Edit the layout.
6. Hit the Add block button to an existing section to bring out the off-canvas dialog.
7. Hit Create a custom block.
8. (If there are multiple block types on the site) Choose the block type that has a formatted text field.
9. Open the overflow menu drop-down, see that is is clipped and partially unusable.

Proposed resolution

Change the value of --ck-toolbar-dropdown-max-width variable to be relative to the width of the editor instance.

This can be achieved with CSS container queries as follows.

.ck.ck-editor {
  container-type: inline-size;
  container-name: ck-editor;
}


@container ck-editor (width > 0) {
  .ck-dropdown__panel {
    --ck-toolbar-dropdown-max-width: 90cqw;
  }
}

Remaining tasks

• Fix.
• Review.
• Commit.

User interface changes

The dropdown width will always be less than the editor width, ensuring that it never gets clipped if the editor is in a div with overflow: hidden; like off-canvas.

Before:

After:

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

#2958588: Off-canvas style resets are overriding styles (especially SVGs) resulting in display issues introduced off-canvas reset
#3291797: Refactor Drupal 10 settings tray / off-canvas to use modern CSS improved it to use modern CSS

As you can see here: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/dialog/o...
the current implementation of the reset looks like this:

/*
 * DO NOT EDIT THIS FILE.
 * See the following change record for more information,
 * https://www.drupal.org/node/3084859
 * @preserve
 */

/**
 * @file
 * Reset HTML elements styles for the off-canvas dialog.
 *
 * @internal
 */

#drupal-off-canvas-wrapper *:where(:not(svg, svg *, .ck-reset *, [data-drupal-ck-style-fence] *, .ui-resizable-handle)) {
  all: revert;
  box-sizing: border-box;
  -webkit-font-smoothing: antialiased;
  line-height: 1.4;
}

#drupal-off-canvas-wrapper *:where(:not(svg, svg *, .ck-reset *, [data-drupal-ck-style-fence] *, .ui-resizable-handle))::after,
#drupal-off-canvas-wrapper *:where(:not(svg, svg *, .ck-reset *, [data-drupal-ck-style-fence] *, .ui-resizable-handle))::before {
  all: revert;
  box-sizing: border-box;
  -webkit-font-smoothing: antialiased;
}

It already contains some excludes for special cases in core, but doesn't allow for contrib to opt-out of the resets, if needed.

That's what we should allow to do, by adding a general helper class to

Steps to reproduce

Need CSS in contrib not to be reset by the off-canvas layer

Proposed resolution

Provide a documented class in :not() selector to opt-out of the reset in contrib, just like the existing, predefined cases.

The class name should be discussed. Proposals:

• .drupal-off-canvas-wrapper-unreset
• .drupal-off-canvas-wrapper-noreset
• ...?

That might also solve the raised point in the comments here:
https://herchel.com/articles/new-drupal-core-refactored-canvas-dialog-css

And eventually it can save us from adding some further special cases and use the class instead?

Remaining tasks

1. Discuss
2. Implement
3. Document
4. Release

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

I get this error from drupal everytime I access a page with a blog entry:

# warning: pg_query() [function.pg-query]: Query failed: ERROR: invalid byte sequence for encoding "UTF8": 0x97 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". in /local/var/www/drupal-6.10_postgresql/includes/database.pgsql.inc on line 139.
# user warning: in /local/var/www/drupal-6.10_postgresql/modules/locale/locale.module on line 365.

# warning: pg_query() [function.pg-query]: Query failed: ERROR: invalid byte sequence for encoding "UTF8": 0x97 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". in /local/var/www/drupal-6.10_postgresql/includes/database.pgsql.inc on line 139.
# user warning: in /local/var/www/drupal-6.10_postgresql/modules/locale/locale.module on line 381.

I can reproduce this problem on different drupal installations and with different languages activated so I think it has to be something with the blog module and not the translations.

To reproduce:

1. use postgresql 8.3.x
2. activate blog module
3. create a blog entry
4. install and activate as default a language other than english. (I have try this with the spanish and danish translations)
5. access any page that shows a blog entry

Any ideas? This is a big problem on busy sites because every page view with blog entries generates error entries by the dblog module

Problem/Motivation

Explanation: Some full and provisional members of the Drupal Security Team meet fortnightly to triage and discuss private core security issues. These meetings are essential to core security process and should be credited like other contribution meetings.

Posted by xjm

Problem/Motivation

There are several deficiencies in Views' API documentation:

• While views.api.php has been updated to Drupal 8, basic explanations for handler plugin types are missing.
• The hook examples need review by an experienced Drupal 8 Views developer; many were updated but some may still be out of date.
• Much of the documentation has not been updated from Drupal 7 (or, in some cases, Drupal 6)...
• All base plugins and handlers need significantly more documentation.
• Plugin @defgroup/@ingroup were moved around when Views' classes were converted to PSR-0, and as a result some classes are probably missing their @ingroup, while Views also has the odd pattern at present of having an @defgroup wrapped around a single PSR-0 class in the base class for a kind of plugin.
• Critical documentation like function and method summaries, parameter documentation, and typehints is widely missing.
• In general, many parts of Views do not conform to Drupal 8 documentation style guidelines.

Proposed resolution

1. Throughout the release cycle, new patches added to Views will be adjusted to core documentation standards defined in the Core documentation gate minimum requirements.
2. We will hold a virtual sprint to do general cleanup of the Views API documentation. This sprint will not begin until at least Feburary 2013. There are two important reasons for postponing the sprint until then:
   • Documentation cleanup patches often take longer to review than to create, and while they are great contribution opportunities for novices, they also need to be reviewed for their accuracy by an experienced developer. The VDC team needs to focus important features and APIs at this point in the release cycle.
   • Documentation cleanups frequently conflict with other patches, because they affect many lines scattered throughout the codebase, in and around actively developed APIs. With a record volume of patches currently being submitted each month, early feature freeze is the worst possible time to force rerolls. (See the graph below, from Dries' blog.)
     

Remaining tasks

Related issues

• #1882558: [META] Document all views plugins types
• #1805818: META: Plugin doc cleanup
• #1776526: Fix ingroup/defgroup documentation
• #1793510: Move views toward D8 documentation standard
• #1805820: Access plugin docs cleanup
• #1892470: Update Views documentation for D8

Problem/Motivation

The items in a tabledrag (menu, taxonomy, etc) are shifted up and not vertically centered with the drag handle.

Looking at the HTML, I see that the handle in 11.0.11 went from

<a href="#" title="Move in any direction" class="tabledrag-handle js-tabledrag-handle"></a>

to this in 11.1.0
<a href="#" title="Move in any direction" class="tabledrag-handle"><div class="handle"></div></a>

which seems to indicate that it's coming from /core/misc/tabledrag.js instead of /core/themes/claro/js/tabledrag.js

The "Show row weights" link was also affected in a similar way.

I suspect it has something to do with the recent changes is asset order: https://www.drupal.org/node/3473558

Steps to reproduce

Go to any form with a tabledrag element: /admin/structure/menu/manage/admin or /admin/structure/block or /admin/config/content/formats/manage/basic_html
Notice that the drag handle and text are not aligned and "Show row weights" is a blue text link.

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is a meta issue after identifying a problem in issue #2613146: filter_test_filter_format_insert() has the wrong "implements" documentation with docblock of different hooks implemented in core and docblock is provided as:

/**
 * Implements hook_*_*().
 */

See:
https://www.drupal.org/project/drupal/issues/2613146#comment-10555240
https://www.drupal.org/project/drupal/issues/2613146#comment-10555332

Proposed resolution

Search for hooks to change with
for hook in $(grep -rh 'Implements hook_.*_.*\(\).' core|grep -Eo 'hook_[^(]+'|sort|uniq); do grep -r "function $hook" core|grep -q api.php || echo $hook; done
This will scan all docblocks for hook implementations and then check for a matching function in *.api.php, outputting the hooks that don't have a match.

Remaining tasks

Use the output of the grep command above and created child issues as need.

User interface changes

N/A

API changes

N/A

Data model changes

N/A