Problem/Motivation

After enabling Require summary on a Basic Block, new blocks cannot be created and Require summary cannot be disabled.

Steps to reproduce

• Navigate to /admin/structure/block/block-content/manage/basic/fields/block_content.basic.body
• Enable Require summary (but not Summary input)
• Save (Message: Saved Body configuration)
• Navigate to /admin/structure/block/block-content
• Add custom block
• Note: only Block description and Body field are visible, no summary
• Add description
• Add body
• Error: Summary field is required.. Note: This behavior is different in Drupal 9.5. There is no longer an error on save. See comment #59.
• Back to /admin/structure/block/block-content/manage/basic/fields/block_content.basic.body
• Note: summary is not visible
• Disable Require summary
• Error: Summary field is required.. Note: This behavior is different in Drupal 9.5. There is no longer an error on save. See comment #59.

I also tested on an existing site (8.8.2) on the body field on a content type and body field on a Product (commerce module), with the same results. Also, on a new content type:

• Deleted the default body field and added a new text w/ summary field
• Save
• Edited, enabled Require summary
• Save
• Same results--unable to add entity or edit the text field under Manage Fields.

If I enable Summary input at the same time as Require summary, then the summary is displayed when adding the entity and when I edit the field, but I still can't disable it. If I fill out the default value summary, then I can disable and save.

Screenshots

Before:

After:

Proposed resolution

Update the form validation to require that Summary input must be enabled before Require summary can be enabled.

Remaining tasks

1. Create patch
2. Review patch
3. Answer outstanding questions
4. Test patch
5. Commit

Outstanding questions

Outstanding questions (see comments in #38, #53, and #59 for reference).
When editing the text field on an entity:

1. When the Summary input is enabled/checked, should the Summary field under Default value automatically display? Or should it only display after the field has been saved? How is this handled in other places?
2. When the Summary input is disabled/unchecked, what should happen to any existing values in the Summary field?
3. When Summary input is disabled/unchecked should Require summary be automatically unchecked?

User interface changes

API changes

Data model changes

Release notes snippet

From https://www.drupal.org/project/drupal/issues/331631:

Drupal users using admin_menu no longer visit the page on the path "admin". That's the only page where Drupal checks the system state.

In #317136: Add status report/update status warnings as icon(s), the idea of displaying the current system (severity) status as icon in the Administration menu evolved. However, admin_menu certainly cannot invoke system_status(TRUE) on all page requests.

So, the goals of this issue:

1) Store current system status in a variable, making it accessible to other modules.

2) Shortcut checking for the current system status. If we already know there is an error, we do not need to perform the full test again.

3) Display system status on all admin pages.

Attached patch tries to do this, however fails to do so. How is Update module maintaining the proper state of its message?

Problem/Motivation

Once #3340712: Add Single Directory Components as a new experimental module has landed this issue will track the necessary work to get the module to beta and then a stable state.

Proposed resolution

Current status

- Currently (as of Drupal 10.0.x), Single Directory Components is proposed for core inclusion with experimental status and located in core/modules/sdc.
- Issues with SDC are still tracked and addressed in https://www.drupal.org/project/sdc first, then carried to the open MR.
- Drupal 10.1's first alpha release is scheduled for the week of Week of April 24, 2023. We are hoping to get #3340712: Add Single Directory Components as a new experimental module merged before that.
- Consensus to add SDC as an experimental module is gathered in #3313520: Single directory components in core.

Release Plan

In terms of the release schedule for Drupal 10, if this module is not included as an experimental module by May 2023 (when 10.1.0-beta1 will be released), then it will need to wait until 10.2. This will also delay the schedule for a future stable version. Normally for Experimental modules, the module gets to Beta, which triggers including it in a release as an Experimental module. Then at a later date, it becomes Stable and gets the Experimental status removed.

Roadmap for Beta (experimental status)

Here is a list of sub-issues that we currently have for that phase, all of which are must-haves to make "Beta" quality, so we can keep it as a live Experimental module in a full Drupal release:

• #3345924: Move schema validation library to require-dev
• #3345925: Fix issues reported by drupal-check
• This is a placeholder to link issues derived from a review on the MR in #3340712: Add Single Directory Components as a new experimental module.

Tasks originally proposed for this phase that made it into the patch before initial commit, or have since been finished:

• #3328636: Make schema props / slots optional
• #3328248: Allow classes and interfaces in the prop types metadata
• #3321150: [META] Increase automated test coverage
• #3320239: String props are improperly encoded/decoded
• #3319704: Allow overriding the library in the component definition
• #3319619: Restrict asset collection
• #3319616: Move components to "/components" from "/templates/components"
• #3317134: Always namespace components during usage and negotiation
• #3317173: Unable to use {% extends %} due to added code
• #3317158: Validate component props at rendering time

Roadmap for Stable

The schedule for stable release is not planned until SDC is in core as experimental.

To get this module to be ready for a stable release, here are some issues we'll need to resolve/finish, all of which are must-haves to make "Stable" quality:

• Umami uses at least one SDC component - #3347672: Create new SDC component for Umami (card view mode)
• Olivero uses at least one SDC component - #3347235: Create new SDC component for Olivero (tabs)
• Allow schema references - #3352063: [PP-1] Allow schema references in Single Directory Component prop schemas
• #3352256: Move code from the experimental SDC module to core
• #3352257: SDC: Validate and improve developer experience and helpfulness of error messages
• #3352258: [META] SDC: Improve and extend documentation
  • #3352262: Create SDC "Quick start" documentation / code - We want this done by DrupalCon Pittsburgh!
  • #3352272: SDC: Move the documentation from markdown to Drupal.org
• #3352260: If needed, create automated tests to validate SDC's use of Drupal escaping and Twig sandboxing
• #3352855: [PP-1] Move makePathRelative from SDC to the FileSystem component
• #3352858: [PP-1] Move isRenderArray from SDC to Drupal\Core\Render\Element

Non-stable-blocking issues

• #3352261: SDC: Investigate augmenting usage of include/embed with custom Twig function

Many efforts have been made to make Drupal 8 a great multilingual system. However, content types are never properly sorted when translations contain accentuated characters.

Content types are sorted using asort. Maybe we could set the locale beforehand.

Steps to reproduce:

Install Drupal 8
Enable the following modules

• Configuration Translation
• Content Translation
• Interface Translation
• Language

Add a language (French in the example)
Add a two content types (Show and Zone)
Translate the Show content type to Émission
Switch languages (fr/admin/structure/types)

Expected behavior

To have a list in this order

• Article
• Basic page
• Émission
• Zone

What happened instead

List was in this order:

• Article
• Basic page
• Zone
• Émission

Problem/Motivation

In Drupal 10.1, we are changing paths and menu navigation for several pages in the Block and Block content modules. In particular,

• #2987964: Move custom block types admin link to admin/structure changes /admin/structure/block/block-content/types to /admin/structure/block-content
• #2317981: The Breadcrumb for block content entities is not useful changes /block/{block_content} to /admin/content/block-content/{block_content}.

When we change paths, we provide redirects from the old ones to the new ones. See #3333383: Create a redirect for the new Block types path. That issue and #2317981 create redirects for the primary paths and also for child paths defined in the block_content module.

This issue is about creating redirect for the child paths provided by other modules, such as content_translation, config_translation, and user. We also want to make it easy for contributed modules to do the same.

Steps to reproduce

1. Install Drupal 10.1.x with the Standard or Umami profile.
2. Visit the path /admin/structure/block/block-content/types/manage/basic/permissions
3. Admire your site's 404 page.

The expected behavior is to be redirected to the new path, /admin/structure/block-content/manage/basic/permissions, with warning messages in the messages area and in the logs.

Proposed resolution

1. Move the function redirectWithWarning() from #3318112: Move "Block layout" from Structure to Appearance to a trait so that it can be used by other controller classes.
2. Update existing redirects to use the new trait.
3. Add routes and controllers to redirect from old child paths to new ones.

To be decided: should the new routes be defined in the block_content module, so that all the related BC routes are in the same place? Or should the routes be defined in the modules that create the original routes, as a model for contributed modules to follow?

Remaining tasks

User interface changes

Redirect to the new path with a warning message instead of giving a 404 (page not found) response.

API changes

Does adding a new trait count as an API change?

Data model changes

None

Problem/Motivation

In the linked meta issue the block items are getting reorganized in the administration menu. At first the moving and relabeling was initially done in #2987964: Move custom block types admin link to admin/structure and #2862564: Move Custom block library to Content. But there was a consensus to separate the relocation and the renaming of things.

Problems with Custom Block Types (https://www.drupal.org/project/drupal/issues/2987964#comment-14764972)

• In #2987964: Move custom block types admin link to admin/structure Custom block types got moved to the same level like Content types, Comment types, and Media types. Due to the prepended word custom and the alphabetical sorting you have Block layout on top of the list then four other menu items and then Custom block types.
• If a person is scanning for blocks in the administration menu the word custom has to be processed first which decreases the readability.
• One could question him or herself if there are Custom block types are there also regular block types?

Problems with Custom block library (https://drupal.slack.com/archives/C1AFW2ZPD/p1666965008595329)

• the term "custom block" means different things to different people, to some people it means creating a custom block in code, while to others it means adding a block containing custom content to be placed on the site;
• Since the introduction of Layout Builder in Core, the use-case for custom blocks has changed, they are no longer just for adding into a region but can be used as part of content on any given page.
• The module itself is named content_blocks.

For the reference the issue was discussed and agreed on in the linked issue on Slack by @aaronmchale, @benjifisher, @rkoller, and @smustgrave

Steps to reproduce

Proposed resolution

• Even though the issue status is already set to postponed [P-4] move the changes for renaming Custom block type to Block type already done in #2987964: Move custom block types admin link to admin/structure over to this issue
• Change the route from /admin/content/block-content to /admin/content/block
• On /admin/content/block (currently /admin/content/block-content) change the page title from Custom block library to Content blocks
• On /admin/content/block (currently /admin/content/block-content) change the label of the tab from Custom blocks to Blocks
• Change the name of the module from Custom block to Block Content

Except the first point, moving over the already made changes, wait with any further work until #2987964: Move custom block types admin link to admin/structure, #2862564: Move Custom block library to Content, and #3318112: Move "Block layout" from Structure to Appearance land. And it might be possible that more name/labeling changes might be necessary.

Remaining tasks

1. Address the items identified in #29 with ❌
2. Address code review in gitlab

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Split from #2025089: Deprecate user_role_grant_permissions() and user_role_revoke_permissions().

Proposed resolution

- user_roles() can often be replaced with Role::loadMultiple()
- user_role_names() can be replaced with array_map() within result of Role::loadMultiple()

Remaining tasks

- review/commit

User interface changes

no

API changes

user_roles() and user_role_names() are deprecated without replacement

Data model changes

no

Release notes snippet

If a module defines a new contextual likes in a *.links.contextual.yml file they are available unless 1 of these things happens:

1. The user's permissions change
2. The user opens a new browser session
3. The user logs out and in.

This is because the contextual links are cached on the client-side and the cache is not cleared unless the hash created by the user's permissions hash changes.

I found while working on #2753941: [Experimental] Create Outside In module MVP to provide block configuration in Off-Canvas tray and expand site edit mode which creates a new contextual link.

This could be fixed by a relying on a hash of current modules installed in addition to permissions.

Problem/Motivation

(Note: this was originally reported at security.drupal.org, but the Sec Team decided it can be handled in public since the circumstances that trigger it are exceedingly rare).

I'd never heard of "phtml" files before. ;) Then I found this in my (mostly) default httpd.conf from MAMP on my local dev box:

AddHandler application/x-httpd-php .php .phtml

Huh? ;) Core doesn't treat these as particularly malicious files.

So IF...

1. You configured a file upload to allow 'phtml' files
2. And your httpd.conf contains the above
3. And for whatever reason the .htaccess got removed from your public files dir (or wasn't created in the first place, etc)

THEN anyone who can access this file upload can run PHP on your server.

Steps to reproduce

1. Install Drupal core
2. Add a file field to one of your content types.
3. Configure that field to allow .phtml file uploads.
4. Configure your httpd.conf file to include:
   

   AddHandler application/x-httpd-php .php .phtml
   

5. Remove the .htaccess file that should be in your public files directory.
6. Create a rce.phtml file with the following content:
   

   <?php
    echo "You've been hacked";
   ?>
   

7. Upload that file to the site.
8. Click on a link to the file.

Expected result

You should see the full contents of the PHP file as text:

<?php
 echo "You've been hacked";
?>

Actual result

The PHP has been interpreted and remote code execution is possible:

You've been hacked

Proposed resolution

Add 'phtml' to the list of extensions that we give special treatment to for .txt renaming if allow_insecure_uploads is FALSE.

Remaining tasks

1. Write tests about it.
2. Do it.
3. Reviews / refinements.
4. RTBC.
5. Commit.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

ajax_page_state is a list of the 'minimal representative set' of libraries on page, which can still be a long list. We should compress it, this will allow it to be passed into GET requests per #956186: Allow AJAX to use GET requests.

The mechanism for this has already been added in #3303067: Compress aggregate URL query strings.

However, we need to figure out whether bc is necessary - some contrib modules might inspect the array. One possible way would be to decompress the query string and replace it in the incoming request, essential upcast it, but... not sure what that looks like yet.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

FinishResponseSubscriber::onRespond() sets some default values for headers.
When setting the values, it specifies the $replace parameter as FALSE, it appears with the intention to not overwrite any headers that have previously been set to the response object's headers.

However, the effect is that $replaces = FALSE instead appends an additional header of the same name, with the specified value.

This may not occur in most cases, assuming:
- modules which alter the headers subscribe with the same or lower priority as the core handler (and consequently execute after the core handler).
- modules set the header value with the parameter $replace == TRUE (which is the default) so that core's value is overwritten.

Steps to reproduce

Create an event subscriber, with a handler for the KernelEvents::RESPONSE event, with an increased priority (>0) that sets one of the following headers:
- X-Content-Type-Options
- X-Frame-Options

The resulting page response will have the default value appended to that of the test subscriber

HTTP/2 200 OK
...
x-ua-compatible: FOO=bar, IE=edge
...

Proposed resolution

Only set the header if a value has not already been set on the request.

Remaining tasks

API changes

Release notes snippet

This issue is part of the wider #3318110: [meta] Reorganize Block items in the administration menu.

Problem/Motivation

Most of the items under "Structure" in the administration menu handle creation of different types (or bundles) of specific entity types: nodes, taxonomy terms, etc. Along to manage the fields and display of each bundle. The Structure area is more about structured content and information architecture, than the layout of the site. The "Block layout" item does not fit that pattern.

After some discussion a consensus has been reached that a better home for Block Layout would be under the Appearance area of the Admin UI.

The primary purpose of the Block Layout page is to add and remove blocks to the regions on a site, these regions are defined by each theme and Core does not make any assumptions about the regions that themes provide. The configuration for blocks in the Block Layout is also organised on a per theme basis. Therefor the link between Block Layout and themes is incredibly strong, in the same way that the Settings forms under Appearance are inherently tied to each theme.

These similarities can clearly be seen when comparing the local tasks on /admin/structure/block and /admin/appearance/settings

Block Layout /admin/structure/block:

Appearance Settings /admin/appearance/settings:

Proposed resolution

Move the "Block layout" page from /admin/structure/block to /admin/appearance/block. Update the child pages to match:

• list, library, and demo for each theme
• edit, delete, enable, and disable, for each block
• add for each block and theme

Add BC routes to redirect the old paths to the new paths, implementing the approach agreed in #3333383: Create a redirect for the new Block types path for making similar path
changes in #2987964: Move custom block types admin link to admin/structure and #2862564: Move Custom block library to Content. Two of the routes use CSRF tokens, so skip these: see Comment #33.

Make the "Block layout" page a local task, before Settings.

Move the "Block layout" link in the Administration menu to the top level under Appearance.

Update implementations of hook_help() and Help Topics to reflect these changes.

Update automated tests.

Remaining tasks

1. Update the change record.

User interface changes

Before

Here is a screenshot of the parent page (Structure) before the patch.

This screenshot shows the path, breadcrumb, admin menu, and tab structure before the patch:

After

Here is a screenshot of the parent page (Appearance) after the patch.

This screenshot shows the path, breadcrumb, admin menu, and tab structure after the patch:

API changes

None

Data model changes

None

Problem/Motivation

Currently the methods hide($element) and show($element) reside in the include file core/includes/common.inc.

Proposed resolution

- Deprecate both methods without replacement, suggesting to inline #printed property flip.
- Document in renderer interface how control flow of render depends on the #printed semaphore

Remaining tasks

- patch
- review/commit

User interface changes

no

API changes

Functions show() and hide() are deprecated

Data model changes

no

Release notes snippet

Problem/Motivation

Coming from #3348093-17: Deprecate user_roles() and user_role_names()
There few places in core which using to escape options for no reason (all other places don't)

Proposed resolution

Remove escaping as twig cares to escape on render and other places not using using it

Probably it could be backported to 9.5

Remaining tasks

path/review/commit

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

Problem/Motivation

Currently if a response is not cacheable Drupal sets X-Drupal-Dynamic-Cache = UNCACHEABLE, but in some cases it does not. See DynamicPageCacheSubscriber::onResponse for details.

Proposed resolution

Always set X-Drupal-Dynamic-Cache header.

1. This changes the existing X-Drupal-Dynamic-Cache: UNCACHEABLE to X-Drupal-Dynamic-Cache: UNCACHEABLE (poor cacheability).
2. This adds X-Drupal-Dynamic-Cache: UNCACHEABLE (no cacheability) (for responses which aren't instances of CacheableResponseInterface).
3. This adds X-Drupal-Dynamic-Cache: UNCACHEABLE (policy) (when the Dynamic Page Cache request/response policy tagged services deny caching).

This makes it much easier for developers to understand what the Dynamic Page Cache module is doing, and why.

Remaining tasks

None.

Updated: Comment #0

Problem/Motivation

We still use the serialize schema key which is used by drupal_write_record() to automatically (un)serialize values upon saving. In #2183231: Make ContentEntityDatabaseStorage generate static database schemas for content entities we will use this for (un)serializing entity field values when saving and loading entities. This is an "API" that was nifty in the far past where people still respected drupal_write_record(), but in the new world order, this is really a weirdness.

$entity = Entity::load('muuuuuuuh');
$entity->save();
$entity_2 = Entity::load('muuuuuuuh');

$entity == $entity_2 // Should return TRUE, or at least theoretical

Proposed resolution

Allow field type classes to define how their values should be (un)serialized. Remove the serialize key from MapItem's schema and use this mechanism instead.

Remaining tasks

- Decide on how this API should work.

User interface changes

None.

API changes

Problem/Motivation

If you create an entity query for an entity type with SQL storage, the Drupal\Core\Entity\Query\Sql\Query class creates a regular SQL query object when the entity query's execute() is called.

There is no way to modify the SQL query from the entity query object.

Reasons you might want to do this include:

- JOINing to a non-entity table, e.g. #3188914: ContentEntity migration source doesn't consider the migration map
- making changes to the SQL query that the entity query class doesn't allow, such as doing $query->forUpdate(TRUE) to prevent concurrency when querying for entities

The only way to do this is:

1. Add a query tag to the entity query, e.g. $entity_query->addTag('my_tag');
2. Implement hook_query_TAG_alter() to then grab the SQL query once the entity query has built it, and it's about to be executed.

This isn't very good DX, as the code for extra bits you want to add to the SQL query is really far away from where you're building the entity query!

Steps to reproduce

Try it.

Proposed resolution

Option 1: Add a method to Drupal\Core\Entity\Query\Sql\Query that takes a callback that will then be applied to the SQL query in the finish() method. Callbacks would be applied in the order that they are registered on the entity query object.

Option 2: Add a toQuery() method, which returns the fully-built (non-Entity) SQL query object. This can then be added to with other statements, and then executed.

Remaining tasks

Write code.

User interface changes

None.

API changes

New method on the SQL entity query class.

Data model changes

None.

Release notes snippet

TODO

Problem/Motivation

See #956186-189: Allow AJAX to use GET requests.

'method' has been in use for a long time. The original patch used 'type', but maybe we could change that to 'httpMethod'. If we make the change before 10.1.x, it won't be an API change.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem summary

AJAX requests are always made using POST, which disables render caching.

However most AJAX requests could be cached safely, and the POST requirement has been due to the large amount of information sent with the request - mainly ajax_page_state containing css/js and html IDs.

ajax_page_state now contains library names instead of individual files, and html IDs are no longer sent at all, resulting in a much shorter URL if requests are switched to GET.

We may be able to reduce the size of the GET request further by compressing ajax_page_state, see #3303067: Compress aggregate URL query strings and #3279206: Dynamically determine ajaxPageState based on libraries.

Proposed solution

Allow AJAX requests to use GET. Continue to default to POST and make this opt-in for backwards compatibility. Forms will continue to have to use POST because they're forms.

Convert Views AJAX (pagers etc.) to use GET - since this is the primary non-form AJAX use-case in core and validates that everything works.

Follow-ups

#2500313: Add views render caching on views ajax requests

Problem/Motivation

After upgrading successfully from DRUPAL 9.2.9 to DRUPAL 9.3.0 via the COMPOSER command "composer update", I tried to upgrade the database with DRUSH command "drush updatedb".

Then the "sort_all_config" post-update script stopped with the error "[warning] Drush command terminated abnormally."

Steps to reproduce

 ---------- ---------------------- ------------- ------------------------------
  Module     Update ID              Type          Description
 ---------- ---------------------- ------------- ------------------------------
  system     sort_all_config        post-update   Sort all configuration
                                                  according to its schema.
  taxonomy   clear_views_argument   post-update   Clear the cache after
             _validator_plugins_c                 deprecating Term views
             ache                                 argument validator.
  user       update_roles           post-update   Calculate role dependencies
                                                  and remove non-existent
                                                  permissions.
  views      sort_identifier        post-update   Add the identifier option to
                                                  all sort handler
                                                  configurations.
 ---------- ---------------------- ------------- ------------------------------


 Do you wish to run the specified pending updates? (yes/no) [yes]:
 >

>  [notice] Update started: system_post_update_sort_all_config
>  [warning] Drush command terminated abnormally.

In ProcessBase.php line 155:

  Output is empty.

Proposed resolution

Workarounds, which are all for contrib modules.
Uninstall additional themes, #37
Uninstall Bario theme, #48 (and others)
Uninstall Gutenberg module, #53
If using the module link_target, see #60

Remaining tasks

Add Steps to reproduce

User interface changes

API changes

Data model changes

Release notes snippet