Problem/Motivation

\Drupal::service('typed_data_manager')->createDataDefinition('entity:user')->getLabel(); helpfully returns the the label of the entity type, in this case user.

\Drupal::service('typed_data_manager')->createDataDefinition('field_item:string')->getLabel(); returns nothing.

It would be helpful if this returned the label of the field type. This can be used when working with configurable contexts to show what type of data a context is.

Steps to reproduce

Run \Drupal::service('typed_data_manager')->createDataDefinition('field_item:string')->getLabel(); get nothing returned

Proposed resolution

Add a getLabel() method to FieldItemDataDefinition that returns the label of the field type plugin.

Remaining tasks

Change record

User interface changes

NA

API changes

core/lib/Drupal/Core/Field/TypedData/FieldItemDataDefinition.php has a new method getLabel().

Data model changes

NA

Release notes snippet

NA

Problem/Motivation

It would be nice if the "Sample release schedule" chart on the Release process overview could be generated from a template file in a drupal.org Git repo.

It should be easy to update with new versions when necessary, and generate an embeddable SVG-file.

Proposed resolution

Create a template with Apexcharts, to allow easy updating with a text editor.

Drupal release schedule

Note: The versions and dates are based on the chart from Release process overview > Sample release schedule.

This is an example. The exact schedule varies, and will be published on the Drupal core release schedule.

Remaining tasks

Decide if it looks all right. For example, are the dotted lines in the current version necessary?

Figure out how to make the labels at the bottom be "June 2024", "Dec 2024", etc. with some JavaScript.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In order to intercept an entity after it has saved, both hook_entity_insert and hook_entity_update must be implemented.

Proposed resolution

Add hook_entity_postsave. Detect if entity is new or being updated using entity API: $entity->isNew()

Remaining tasks

User interface changes

None

API changes

Deprecate hook_entity_[type_]insert and hook_entity_[type_]update.

Data model changes

Original report by ivanjaros

We already have a hook_entity_presave hook so why don't we also have hook_entity_postsave?
In current state if I want to run some logic after the entity hase been saved, and I don't care if it is/was new or already existing entity, I have to implement TWO hooks instead of just one: hook_entity_insert AND hook_entity_update.

The get_value_options on filters currently not returns the actual available options, but just set the value on the object, which is fine, though the function name implies to return something, so let's do that.

Problem/Motivation

Part of #3324560: Replace strpos/substr with PHP 8's str_starts_with() / str_contains() / str_ends_with().

Proposed resolution

1. Replace most substr($a, 0, $i) == $b with str_starts_with($b).
2. A few are deliberately omitted where they would cause merge conflicts with other child issues.

Remaining tasks

• When reviewing, consider using git diff --color-words or git diff --porecelain.
• Pay attention to the fact that $i should be the length of $b.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

When you disable a text format it is not possible to re-enable it. This seems counter to the behavior in other situations, such as Views, which allows disabling than re-enabling a display. Furthermore, it can lead to major problems on a site if a text format was mistakenly disabled.

Steps to reproduce

Disable a text format and experience the disappointment upon realizing it can't be re-enabled. You'd need to create a new text format (yet can't create one with the same machine name), then change all items previously using the old one to use the new one.

Proposed resolution

Add an "Enable" operation for disabled text formats, which can be used to re-enable the disabled text format.

Remaining tasks

Code review

User interface changes

The "Enable" operation is available to disabled text formats

API changes

Data model changes

Release notes snippet

Beta phase evaluation

The entire site crashed after being upgraded to D10.2.1 from D10.2

I am in the middle of testing my site of migrating from D7 to D10. Then I was prompted with new update reminder. First I updated Ecommerce on site, then I encounter an error when updating database. But I was able to check status report and other pages. Then I used terminal to upgrade to D10.2.1, the entire site crashed with an error message of "The website encountered an unexpected error. Try again later."

Unable to get to any page, so I cannot provide additional error messages.

This is devastating. I don't know what to do. Although it is not a production site, but with lots of work done here. In addition, it really concerns me that updating modules or core is so unstable, really fear to go to production.

If anyone could help me how to get back to my site, really appreciate!!!!

Problem/Motivation

We have a number of issues around the confusing situation with Full/Default:

* #2834316: Node preview shows and defaults to "Default" instead of "Full" view mode
* #2639274: Unable to select "default" pseudo view mode in FieldFormatterFromViewDisplay configuration (not core, but relevant feedback from @yched)
* #2700147: Views uses non-existent "default" view mode, which causes Quick Edit to break

The main problem is that we have view displays and view modes and there is a default view display that is a fallback for all view modes that have no display enabled. The default view mode is "full" and there is often now view display enabled for it. And our API returns 'default' as fixed always-there default option instead of "Full".

Proposed resolution

@todo: Complete this, just some notes/ideas for now:

* Remove Default, make Full the fallback
* Maybe no fallback at all, no enabled display => no fields. Without a hierarchy of fallbacks, it is in 95% of the cases not what you want anyway
* Have a full view mode that always exists for all entity types
* Have locked view modes that can't be deleted

Maybe some changes can be done as improvements in 8.x, but changing the fallback concept and renaming default to full is IMHO 9.x only.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

TypeError: strlen(): Argument #1 ($string) must be of type string, array given in strlen() (line 395 of core/lib/Drupal/Component/Utility/Unicode.php)

The problem is in 'function template_preprocess_field_multiple_value_form' where they are in the header a array empty

$header = [
[
'data' => [
'#type' => 'html_tag',
'#tag' => 'h4',
'#value' => $element['#title'],
'#attributes' => $header_attributes,
],
'colspan' => 2,
'class' => ['field-label'],
],
[],
t('Order', [], ['context' => 'Sort order']),
];

Steps to reproduce

create a field multiple

Problem/Motivation

When adding a link field to an entity and set the field to allow more then 1 value it breaks the site with WSOD when it tries to render the form. The following error is thrown in the logs:

TypeError: strlen(): Argument #1 ($string) must be of type string, array given in strlen() (line 396 of .../web/core/lib/Drupal/Component/Utility/Unicode.php).

Steps to reproduce

Add link field to any entity and set number of allowed values to more than one. When trying to access the form the site breaks throwing the error stated above. backtrace suggests that error is thrown when the twig engine is trying to render a table for the multiple value form.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce from #3117751: Unpublished revisions of multilingual node rollback unpublished revision of another language to default revision:

Let's have a multilingual site & node with more than 1 language (i.e. node is translatable): EN & DE.
Also enable Workflows module to have draft & published states.

We have 2 published revisions for EN & DE languages.
Then we create new revision of node with EN language but do not publish. Database containt up-to-date value for e.g. field body.
After it we create new draft revision of DE node.
Database contains value for body field for EN node from previous published (default) revision.
Drafts with different languages of one node should not revert another draft to previous state.
It also affects JSON:API.
There are a lot of possible related issues I guess:
#2875861: Optimize updating data and revision data tables
#3023194: [PP-2] Add parallel revisioning support
#2795279: [PP-2] [META] Revisions support
#2833084: $entity->original doesn't adequately address intentions when saving a revision
#2833049: ContentEntityBase::hasTranslationChanges will compare a forward revision with the default one instead of the newest forward revision
#2477419: Codify mechanism to set a forward revision as the default revision
#2960887: Do not create field revisions when field data hasn't changed
#2769741: Node revisions page might not list a default revision
#3056440: Cannot add new translation if the latest affected translation revision of the source language is older than the default revision
#3080995: EntityRepository::getActive does not return a translations most recent revision
#2815949: It is not possible to know if a revision was once the default
#2766957-176: Forward revisions + translation UI can result in forked draft revisions - potential root cause
#2845144: User can't reference unpublished content even when they have access to it

How to reproduce

• 1. Add 2 languages to site (EN and any one).
• 2. Make "Article" node revisionable & translatable.
• 3. Create Moderation Workflow with: draft, review, published states.
• 4. Create Published revision of node with default language: body field text = "published default"
• 5. Create Draft revision of node with default language: body field text = "draft default"
• 6. Verify database table "node_revision__body", created node has body_value = "draft default" for default (en) language
• 7. Create Published revision of node with non-default language: body field text = "published translation"
• 8. Create Draft revision of node with non-default language: body field text = "draft default"
• 9. Verify database table "node_revision__body", created node has body_value = "published default for default (en) language

Visually database will look like:

Revision 9659 contains new EN content but reverts RU to previous published.
Revision 9660 contains new RU content but reverts EN to previous published.
Revision 9661 contains new EN content but reverts RU to previous published once again.

Original report: I am using Content moderation, Workflows, Language and Content translation core modules in Drupal 8.6.4. I have implemented workflow on Basic page with states like (Draft, Audit, Review, Pre Publish and Publish). Now I am creating a Test content in English as well as in Spanish language and pass all the workflow states and publish the content in both language. Now when i try to update the moderation state of both of these content to Draft one of them gets auto published, but inside the edit mode it shows current state as Draft only for both of the content which is correct. (Here, we are refering to content_moderation_state_revision table in DB)

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce

• Install drupal
• Install language and content translation module
• Add a second language
• Mark node articles as translatable
• Create some content, and translate it
• Go to /admin/content and you'll see two rows, one for each :

More detailed description of the problem space

The admin/content page needs a dynamic language field and a dynamic language filter that is exposed only on multilingual sites.

Proposed resolution

a) Add a dynamic language field on the admin/content page.

b) Make the language filter UI dynamic that shows up only on multilingual sites.

Remaining tasks

User interface changes

The admin/node page will be usable in Multilingual.
Head Monolingual

Head Multilingual

MR Monolingual

MR Multilingual

API changes

None.

Problem/Motivation

Vertical tabs are not working optimally in forced colors mode. See videos for reference: https://youtu.be/6j0Z62R2bEA and https://youtu.be/VtWjPn5p5-w.

Steps to reproduce

1. Install drupal 11.x-dev.
2. Navigate to the vertical tabs.
3. Added custom block and the palce in any region.
4. At the bottom of left side, See the visibility of vertically tabs.

Proposed resolution

-Apply appropriate border colour on active tab.

Problem/Motivation

The Rendered entity field adds cache tags for a all entity display config entities associated with the entity type of the rendered entity. In other words, if the content (node) view is configured to display a Rendered entity field, the cache tags for all configured entity view displays for node types will be added to the view/view display config's cache metadata. On a site with many content types and entity displays/view modes, this will bubble up all those cache tags on pages where the view is rendered. This can lead to errors such as #2844620: FinishResponseSubscriber: Need warning/error when headers exceed 16k.

Since rendering the entity will bubble up cache tags that are invalidated whenever entity view displays are saved, it is not necessary for the Rendered Entity plugin to include cache tags for the entity view displays in getCacheTags() at all.

Steps to reproduce

1. Create a few different content types
2. Create a few different view modes for content
3. Configure custom displays for some view modes across content types
4. Create and configure a view to display content with a Rendered entity field. Add a filter for a single content type
5. Create test content that will be displayed in the view
6. Visit page with the view.
7. If http.response.debug_cacheability_headers is true, note that there are tags in the HTTP header for all configured node entity displays.
8. Alternatively check the relevant entry in the cache_page database table and observe the tags there

Proposed resolution

Change getCacheTags() in \Drupal\views\Plugin\views\field\RenderedEntity to return an empty array.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #2659940: Extension System, Part III: ThemeExtensionList and ThemeEngineExtensionList, the responsibility of managing the list of themes and theme data is moved to \Drupal::service('extension.list.theme'). This issue is a follow up to deprecate ThemeHandlerInterface::rebuildThemeData() and replace it with calls to \Drupal::service('extension.list.theme')->reset() and \Drupal::service('extension.list.theme')->getList()

Proposed resolution

Replace all usages and deprecate ThemeHandlerInterface::rebuildThemeData() and trigger a silenced error. Also, when replacing the usages we should ensure that we don't unnecessarily rebuild the module list.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Updated: Comment #41

Problem/Motivation

- Mapping field item properties to DB storage record is hardcoded in \Drupal\Core\Entity\Sql\SqlContentEntityStorage.
- It contains special cases for the serialize key of FieldItemInterface::schema, and a special case of this special case for MapItem field (where not a single property but all properties are serialized).
- Issues like #2563843: MapItem is broken for configurable fields demand to add more special cases
- In the context of the JSON storage initiatives (like #3276818: [META] Add support for JSON field queries in entity queries), a proper JSON map field adds more requirements to that.

Time to add an API so that fields can specify how their properties are mapped to their schema columns.

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.
- Deprecate the serialize key in a followup.

Remaining tasks

- Decide on how this API should work, code, review, commit.

User interface changes

None.

API changes

Addition: Field items can specify how they are mapped to storage and possibly serialized or JSON encoded.

Problem/Motivation

After enabling Require summary on a Text (formatted, long, with summary) field, when editing the field can't save without giving a default Summary.

Also I can check Require summary without summary input being checked.

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.

Screenshots

Before:

After:

Proposed resolution

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

Also even when Require Summary is checked, builders can still save the field UI without putting a default summary in.

Remaining tasks

1. Create patch
2. Review patch
3. Answer outstanding questions
4. Test patch- Use test-only feature
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? - not sure but also seems like a follow up as this is about fixing a bug (least how I understand it) - Opened #3394040: When the Summary input is enabled/checked, should the Summary field under Default value automatically display
2. When the Summary input is disabled/unchecked, what should happen to any existing values in the Summary field? - Seems like a follow up but this issue shouldn't tough that. - Opened #3394041: 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? - Yes updating fix

User interface changes

See screenshots

API changes

NA

Data model changes

NA

Release notes snippet

NA

Problem/Motivation

The toolbar subtrees use a hash to determine if access to the subtree should be allowed in ToolbarController::checkSubTreeAccess(). In certain situations the hash does not match, resulting in a JavaScript error and the subtrees not dynamically loading.

Steps to reproduce

1. Set the admin menu in vertical mode.
2. Make sure to have a site with 2 languages.
3. Enable the Account administration pages on Language negotiation > Detection and selection
4. Set the default language to something non-english
5. Set an admin language in your user profile other than the default site language (e.g. english).
6. Go to a content page in your content language
7. Refresh the cache (I did this from the content page with devel module)
8. Navigate to an admin page
9. Observe that the toolbar submenu toggles are not shown and there is a JavaScript error

Temporarily commenting out the hash check from ToolbarController::checkSubTreeAccess() makes the toggles appear again.

Proposed resolution

The hash is calculated from the rendered subtrees, but if the rendered content changes (assumably because the labels are suddenly in another language), the hash no longer matches with the sent one and the access check fails.

I am not entirely sure why the hash is even there, so perhaps this can be added in a comment?

Perhaps create a hash from something that is not language/content dependent (before rendering)?

Remaining tasks

TBD

User interface changes

Hopefully none

API changes

Probably none

Data model changes

Release notes snippet

Problem/Motivation

Over at #3324140: [PP-1] Convert field_storage_config and field_config's form validation logic to validation constraints, we identified the need for a EntityBundleExists constraint for FieldConfig and BaseFieldOverrideconfig entities.

However, there are at least a few other uses for this:

1. condition.plugin.entity_bundle:*'s bundles sequence items
2. views.argument_validator_entity`'s bundles sequence
3. LanguageContentSettings config entity (language.content_settings.*.*`): target_bundle field
4. et cetera.

Steps to reproduce

N/A

Proposed resolution

1. Extract EntityBundleExistsConstraint(Validator from that issue
2. Add explicit test coverage for the new constraint
3. Adopt in all config entities in core where it makes sense
4. Maybe adopt in some simple config, if there's little doubt about it being valuable

Remaining tasks

1. ✅ Constraint + test coverage
2. ✅ Adopt in all relevant config entities: EntityFormDisplay, EntityViewDisplay, ContentLanguageSettings and FieldConfig
3. ✅ Update corresponding ConfigEntityValidationTestBase subclasses
4. ✅ Create change record

User interface changes

None.

API changes

None.

Well, sort of. There's an internal class added, \Drupal\Core\Config\Schema\TypeResolver, which contains logic previously in \Drupal\Core\Config\TypedConfigManager concerned with replacing tokens like %parent with actual, fully resolved config names. TypeResolver exposes that logic as public methods so that the constraint can use it for a little dynamism, since it's very possible that you'll want to sometimes specify entity type IDs using dynamic tokens.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

The pager by default uses an h4, this creates the `Heading levels should only increase by one` error in many use cases.

Steps to reproduce

Create a view with a pager that has no other content on the page.
Run axe devtools

Proposed resolution

Add ability to set the heading level per view pager.
Options should be h1 - h6

Remaining tasks

User interface changes

API changes

N/A

Data model changes

Add pagination_heading_level to views pager schema
Add pagination_heading_level variable to views mini pager and full pager

Release notes snippet