Problem/Motivation

LinkWidget provides a creative logic for internal links that converts the autocomplete entity value into their equivalent URI and vice-versa along its lifecycle.

That logic is pretty neat and could be interesting to move it to a generic trait in order to be reused by other parts of core or contrib modules that might require this logic.

A good scenario to use this trait and avoid copy&paste code is in https://www.drupal.org/project/drupal/issues/3445993, where Navigation links might use this logic

Proposed resolution

Move the following methods to a generic trait and implement and use the trait in LinkWidget:

• LinkWidget::validateUriElement()
• LinkWidget::getUriAsDisplayableString()
• LinkWidget::getUserEnteredStringAsUri()

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

On doing a "Collapse Sidebar", the sidebar is collapsed properly but the text for menu items (Expland Sidebar, Help, and user account menu)in this section is overflowing.

Steps to reproduce

1. Enable the Navigation module
2. Do a cache clear
3. Click on "Collapse Sidebar"
4. You will face this issue https://www.awesomescreenshot.com/video/28120978?key=0911dde2b83f79acdf7...
5. Using latest chrome on Ubuntu

Proposed resolution

Need some CSS or JS fixes.

Remaining tasks

Code to fix the issue.

User interface changes

NA

API changes

NA

Data model changes

NA

Problem/Motivation

Currently, there is no online documentation page for the module.

For example, I was to change the settings on /admin/config/user-interface/navigation/settings page but not sure what these are and what would reflect after making the changes.

Tried to find the documentation on https://www.drupal.org/project/navigation but could not or is it somewhere else and I missed it.

Steps to reproduce

Proposed resolution

Create a documentation page for the module https://www.drupal.org/project/navigation

Remaining tasks

User interface changes

NA

API changes

NA

Data model changes

NA

Release notes snippet

Problem/Motivation

When implementing the search API for my website, I found myself in the situation where I needed to be able to activate the ‘use ajax’ functionality for the ‘Pager’ part but not for the ‘Exposed filters’.
Acutally, it's not possible to dissociate these 2 functions so I decided to find out how to make this possible.

Proposed resolution

My idea for adding this functionality is to add 3 checkboxes for paging, sorting and exposed filters, allowing the user to select which aspect they want to activate AJAX on.

Remaining tasks

In my research, I managed to address 2 of the 3 points. Unfortunately, I haven't been able to find where to include the sorting part. From what I've understood, it's a matter of enabling AJAX on the sorting of the view's backend arrays, but it's impossible to get my hands on the relevant code.

User interface changes

A list of checkboxes displayed when the user activates the ‘Use ajax’ option

Problem/Motivation

1. Navigate to the page /admin/config/user-interface/navigation-block shows the warning message "You have unsaved changes." without even making any changes.
2. Along with this there is no way to simply "Cancel" or "Go back" link to go back to the homepage or previous page without making any changes, the only way to navigate away from this page is from the Breadcrumbs. User has to either Save and Discard Changes

https://www.awesomescreenshot.com/video/28121999?key=a40128af7a6122991e4...

Steps to reproduce

1. Enable the Navigation module
2. Visit /admin/config/user-interface/navigation-block

Proposed resolution

1. Do not show this warning message on just navigating to this page
2. Add a "Go Back" or "Go to Homepage" link

Problem/Motivation

While creating a list field of a custom entity, we face a WSOD screen with this error in logs -

TypeError: Drupal\Core\Field\FieldTypePluginManager::createFieldItem(): Argument #1 ($items) must be of type Drupal\Core\Field\FieldItemListInterface, null given, called in /web/core/modules/field/src/Entity/FieldStorageConfig.php on line 710 in Drupal\Core\Field\FieldTypePluginManager->createFieldItem() (line 89 of /web/core/lib/Drupal/Core/Field/FieldTypePluginManager.php).

This issue is occurred on 10.2.* version, works with no issues with <= 10.1.

In 10.2 version, there is new update for FieldStorageConfig.php file for getOptionsProvider function.

Steps to reproduce

Create a custom entity, and try creating a select list field.
WSOD will be observed and above mentioned Error will be seen in Recent Logs.

Proposed resolution

Remaining tasks

Prerequisites/Blockers

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We have multilingual sites setup using a different domainname for each language. We also setup the admin ui so that the translate tab on a node opens up in a modal dialog. When you hit the "edit" for one of the translations, the node edit form is opened also in a modal dialog.
CORS is setup to allow all our domains, supportsCredentials is enabled, methods are POST,GET and OPTIONS. exposedHeaders has the 'X-Drupal-Ajax-Token'.
When the Ajax calls are made to open the node edit forms in the second dialog, the calls are made anonymous. The session token is not send.

Steps to reproduce

Setup multilingual site with at least 2 languages.
Use different domain for each language.
Setup CORS as described above.

Proposed resolution

To solve this, ajax.js needs to configure extra options when doing the requests:
- crossDomain: true
- xhrFields: { withCredentials: true }

Remaining tasks

Check if this has any impact on other Ajax related stuff.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

Over at #1170362: Install profile is disabled for lots of different reasons and core doesn't allow for that, the schema for core.extension:profile is being refined.

Once that lands, we'll be able to make it validatable too, and make the entire config object validatable!

Conversation that triggered this issue to be created:

Wim

IMHO this is missing the following validation constraints, because right now **literally any string is allowed**:
```suggestion:-0+0
      label: 'Install profile'
      constraints:
        NotBlank: []
        ExtensionName: []
        ExtensionExists: profile
```

1. `NotBlank: []` because the empty string is never a valid install profile
2. `ExtensionName: []` because that validates the _shape_ of allowed strings
3. `ExtensionExists: profile` because that validates that (the already valid shape) indeed exists

Note that these 3 constraints are _exactly_ what we do for validating installed modules and themes in `config_dependencies_base`.

The only thing that's missing for that to work is a tiny addition to `ExtensionExistsConstraintValidator::validate()` using `\Drupal\Core\Extension\ProfileExtensionList`?

P.S.: _maybe_ `ExtensionExists` is impossible due to a race condition, but the other two validation constraints should be possible.

Alex

I think we should explore this in a follow-up. This is not really in-scope here.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We are planning to rewrite UI Patterns upon SDC. To achieve this, we are proposing a few changes and additions:

• #3390980: Make SDC extensible
• #3352063: Allow schema references in Single Directory Component prop schemas
• Introduce component variants to SDC. The current issue.
• #3390717: Allow declaration of template path in SDC
• #3391702: SDC ComponentElement: Transform slots scalar values to #plain_text instead of throwing an exception
• #3391978: SDC: Add a method to retrieve only components not replaced by others

Variants is a common feature in UI Components:

• Bootstrap cards have vertical and horizontal variants
• Material Design buttons have text, outilned, raised and unelevated variants
• ...

Declaring variants as a prop is not enough for many reasons.

1. Using a string type with enum doesn't allow proper documentation (label, description):

props:
  type: object
  properties:
    variant:
      type: string
      enum:
        - primary
        - secondary
        - inverted

2. Using a anyOf with constant is verbose and complicated:

props:
  type: object
  properties:
    variant:
      anyOf:
        - { "const": "primary", "title": "Primary", "description": "..." }
        - { "const": "secondary", "title": "Secondary", "description": "..." }
        - { "const": "inverted", "title": "Inverted", "description": "..." }

3. The prop ID is free and it will not always be "variant", but sometimes "variants", "variations", "versions", "scheme"... SDC ecosystem may suffer of this lack of consistency. A module which want to leverage components variants will have no way of guessing which prop is a variant.

Proposed resolution

Add a new "variant" property at the root of component declaration with the same structure as the slot property :

name:  Card
variants:
  primary:
    title: Primary
    description: ...
  secondary:
    title: Secondary
    description: ...
  inverted:
    title: Inverted
    description: ...
  primary:
    title: Primary
    description: ...
props: {}
slots: {}

Proposal 1: declare as variant, use as prop

Once declared, the variant is loaded a prop and used as a prop:

[
  '#type' => 'component',
  '#component' => 'card',
  '#props' => [
    'variant' => 'primary',
  ]
]

This is what we plan to do in UI Patterns 2.x if it is not done at the SDC level, not because it is our preference, but because we don't want to "hack" SDC too deeply.

Proposal 2: declare as variant, use as variant

With the introduction of a new property in the render element:

[
  '#type' => 'component',
  '#component' => 'card',
  '#variant' => 'primary',
  '#props' => [ ]
]

We have a preference for this solution.

Remaining tasks

If there is a chance for this feature to be accepted, we (UI Patterns team) can propose a merge request soon.

We have one month before the release of Drupal 10.2.0-alpha1.

API changes

Yes, but not breaking.

Problem/Motivation

If you create a translation of an article in Ukrainian, for example, and then delete it, then on page /admin/config/search/pages we see the following: "There is 1 item left to index."

Running the cron does not solve the problem.

Result:
On page /admin/config/search/pages we see the following: "There is 1 item left to index."
If this is repeated for 100 articles, the indexing of the site will stop.

There is such an entry in the database:
SELECT * FROM `d8_search_dataset`

• sid = 1
• langcode = uk
• type = node_search
• data = "some text"
• reindex = 1618155506

Steps to reproduce

1. Install Drupal 8.9.13 (Latest version for now)
2. Install modules (from core): Configuration Translation, Content Translation, Interface Translation,
Language
3. /admin/config/regional/language - Add the Ukrainian language, for example
4. /admin/structure/types/manage/article - "Enable translation"
5. create an article and add a translation to it.
6. Runs Cron
7. Delete article translation.
8. Runs Cron

Proposed resolution

Delete the translation from the search index by implementing hook_entity_translation_delete

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Problem/Motivation

system.performance has 4 property path that are not yet validatable:

./vendor/bin/drush config:inspect --filter-keys=system.performance --detail --list-constraints
➜  🤖 Analyzing…

 Legend for Data: 
  ✅❓  → Correct primitive type, detailed validation impossible.
  ✅✅  → Correct primitive type, passed all validation constraints.
 ----------------------------------------------- --------- ------------- ------ ------------------------------------------ 
  Key                                             Status    Validatable   Data   Validation constraints                    
 ----------------------------------------------- --------- ------------- ------ ------------------------------------------ 
  system.performance                              Correct   76%           ✅❓   ValidKeys: '<infer>'                      
   system.performance:                            Correct   Validatable   ✅✅   ValidKeys: '<infer>'                      
   system.performance:_core                       Correct   Validatable   ✅✅   ValidKeys:                                
                                                                                   - default_config_hash                   
   system.performance:_core.default_config_hash   Correct   Validatable   ✅✅   NotNull: {  }                             
                                                                                 Regex: '/^[a-zA-Z0-9\-_]+$/'              
                                                                                 Length: 43                                
                                                                                 ↣ PrimitiveType: {  }                     
   system.performance:cache                       Correct   Validatable   ✅✅   ValidKeys: '<infer>'                      
   system.performance:cache.page                  Correct   Validatable   ✅✅   ValidKeys: '<infer>'                      
   system.performance:cache.page.max_age          Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints here  
   system.performance:css                         Correct   Validatable   ✅✅   ValidKeys: '<infer>'                      
   system.performance:css.gzip                    Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                     
   system.performance:css.preprocess              Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                     
   system.performance:fast_404                    Correct   Validatable   ✅✅   ValidKeys: '<infer>'                      
   system.performance:fast_404.enabled            Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                     
   system.performance:fast_404.exclude_paths      Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints here  
   system.performance:fast_404.html               Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints here  
   system.performance:fast_404.paths              Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints here  
   system.performance:js                          Correct   Validatable   ✅✅   ValidKeys: '<infer>'                      
   system.performance:js.gzip                     Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                     
   system.performance:js.preprocess               Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                     
 ----------------------------------------------- --------- ------------- ------ ------------------------------------------

Steps to reproduce

1. Get a local git clone of Drupal core 10.3.x.
2. composer require drupal/config_inspector— or manually install https://www.drupal.org/project/config_inspector/releases/2.1.5 or newer (which supports Drupal 11!)
3. composer require drush/drush
4. vendor/bin/drush config:inspect --filter-keys=system.performance --detail --list-constraints

Proposed resolution

Add validation constraints to:

1. system.performance:cache.page.max_age
2. system.performance:fast_404.exclude_paths
3. system.performance:fast_404.html
4. system.performance:fast_404.paths

For examples, search *.schema.yml files for the string constraints:😊

Reach out to @borisson_ or @wimleers in the #distributions-and-recipes.

Remaining tasks

User interface changes

None.

API changes

Data model changes

More validation 🚀

Release notes snippet

None.

Problem/Motivation

When useres register for an account and follow their one-time login link, or requests a one-time-link because they forgot their password, the resulting user/edit form does not require them to choose a new password. If by chance they miss that part of the form (which happens quite often as it's not highlighted), they're left with the inital random password.

To make matters worse, when they return to the user account page to change their password later on, they are prompted to enter their OLD password - the one they have forgotten. This creates a terrible user experience for users, and a headache for site admins.

Proposed resolution

It would make for a better user-experience all around if the prompt to reset your password were on the one-time login page.

Remaining tasks

• Update issue summary with screenshots.
• Add simpletests.

User interface changes

None.

API changes

user_pass_reset():

• moved the second phase (the form response) to user_pass_reset_submit().
• Clarified the status message for already used links. Expired links are caught by the first if, so let's be specific here: In the end, a user needs to know if there are signs that a 3rd person could have used the link and taken over the user's account.
• The status message for logged-in users: "You have already used this one-time login link. It is not necessary to use this link to login anymore. You are already logged in." is misleading. While it is true that it is not necessary to use this link, first of all it is also true that it is not possible anymore. Changed this to "You have already used this one-time login link, therefore you need to login with your password. In this case this is not necessary because you are already logged in."

user_pass_reset_submit():

• To save the new password I'm straightly using user_save() unlike in patch #4 where a custom query was used. True, that user_save is a bit behemoth. But we need to do all checks, call all hooks, allow for alternate password hashing schemes etc. Certainly we don't want to reimplement or copy/paste that code. In the end using user_save is no problem because resetting the password is no performance-critical task.

user_pass():
The button title "E-mail new password" has been incorrect for quite a while. We're not sending passwords, but one-time login links. I changed the button title to "Request password reset" which is generic enough not to be incorrect, yet easy to understand.
Also, a description was added to the textfield.
user_pass_submit():

• The message "Further instructions have been sent to your e-mail address." misses out the one-time login link and therefore leaves the user unclear about whether this means his action was successful or not. Changed to: "A one-time login link and further instructions have been sent to your e-mail address."
• The redirect to the login page is confusing because logging in is exactly what the user can't do at the moment. Rather we should leave the user where s/he is. S/he anyway needs to check mail, first.

_user_mail_text():

• Changed the e-mail text so it reflects our changes.
• Maybe we can improve on some of the messages.

Also I wasn't sure if hook_user_login (invoked by user_authenticate_finalize) should be provided both password and username, so modules hooking in there can make use of the information (at that point there is not enough documentation about the hooks available). As hook_user_login currently doesn't get any useful information, going with what we have should be okay. If someone knows more about this aspect, I'd appreciate some info though.

Original report by joshk

When users register for an account and follow their one-time login link, or requests a one-time-link because they forgot their password, the resulting user/edit form does not require them to choose a new password. If by chance they miss that part of the form (which happens quite often as it's not highlighted), they're left with the inital random password.

It would make for a better user-experience all around if it were required that newly registered users were required to choose a password which they can remember. This would mean:

1) Making the password fields required for the one-time-login form
2) Give the password section of the form a very light weight to put it at the top

I'll create a patch for this unless there's a compelling reason not to.

Problem/Motivation

Action entity is not yet validatable:

vendor/bin/drush config:inspect --filter-keys=system.action.user_cancel_user_action --detail --list-constraints
➜  🤖 Analyzing…

 Legend for Data: 
  ✅❓  → Correct primitive type, detailed validation impossible.
  ✅✅  → Correct primitive type, passed all validation constraints.
 ------------------------------------------------------------------ --------- ------------- ------ ---------------------------------------------------------------------------------------------------- 
  Key                                                                Status    Validatable   Data   Validation constraints                                                                              
 ------------------------------------------------------------------ --------- ------------- ------ ---------------------------------------------------------------------------------------------------- 
  system.action.user_cancel_user_action                              Correct   79%           ✅❓   ValidKeys: '<infer>'                                                                                
   system.action.user_cancel_user_action:                            Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                                
   system.action.user_cancel_user_action:_core                       Correct   Validatable   ✅✅   ValidKeys:                                                                                          
                                                                                                      - default_config_hash                                                                             
   system.action.user_cancel_user_action:_core.default_config_hash   Correct   Validatable   ✅✅   NotNull: {  }                                                                                       
                                                                                                    Regex: '/^[a-zA-Z0-9\-_]+$/'                                                                        
                                                                                                    Length: 43                                                                                          
                                                                                                    ↣ PrimitiveType: {  }                                                                               
   system.action.user_cancel_user_action:configuration               Correct   NOT           ✅❓   ❌ @todo Add validation constraints to ancestor type: action.configuration.user_cancel_user_action  
   system.action.user_cancel_user_action:dependencies                Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                                
   system.action.user_cancel_user_action:dependencies.module         Correct   NOT           ✅❓   ❌ @todo Add validation constraints to ancestor type: config_dependencies                           
   system.action.user_cancel_user_action:dependencies.module.0       Correct   Validatable   ✅✅   NotBlank: {  }                                                                                      
                                                                                                    ExtensionName: {  }                                                                                 
                                                                                                    ExtensionExists: module                                                                             
                                                                                                    ↣ PrimitiveType: {  }                                                                               
   system.action.user_cancel_user_action:id                          Correct   Validatable   ✅✅   Regex:                                                                                              
                                                                                                      pattern: '/^[a-z0-9_\.]+$/'                                                                       
                                                                                                      message: 'The %value machine name is not valid.'↣ PrimitiveType: {  }                                                                               
                                                                                                    ↣ Length:                                                                                           
                                                                                                      max: 166                                                                                          
   system.action.user_cancel_user_action:label                       Correct   Validatable   ✅✅   Regex:                                                                                              
                                                                                                      pattern: '/([^\PC])/u'                                                                            
                                                                                                      match: false                                                                                      
                                                                                                      message: 'Labels are not allowed to span multiple lines or contain control characters.'           
                                                                                                    NotBlank: {  }                                                                                      
                                                                                                    ↣ PrimitiveType: {  }                                                                               
   system.action.user_cancel_user_action:langcode                    Correct   Validatable   ✅✅   NotNull: {  }                                                                                       
                                                                                                    Choice:                                                                                             
                                                                                                      callback: 'Drupal\Core\TypedData\Plugin\DataType\LanguageReference::getAllValidLangcodes'↣ PrimitiveType: {  }                                                                               
   system.action.user_cancel_user_action:plugin                      Correct   Validatable   ✅✅   PluginExists:                                                                                       
                                                                                                      manager: plugin.manager.action                                                                    
                                                                                                      interface: Drupal\Core\Action\ActionInterface                                                     
                                                                                                    ↣ PrimitiveType: {  }                                                                               
   system.action.user_cancel_user_action:status                      Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                               
   system.action.user_cancel_user_action:type                        Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: system.action.*                         
   system.action.user_cancel_user_action:uuid                        Correct   Validatable   ✅✅   Uuid: {  }                                                                                          
                                                                                                    ↣ PrimitiveType: {  }                                                                               
 ------------------------------------------------------------------ --------- ------------- ------ ---------------------------------------------------------------------------------------------------- 

Steps to reproduce

1. Get a local git clone of Drupal core 11.x.
2. composer require drupal/config_inspector— or manually install https://www.drupal.org/project/config_inspector/releases/2.1.5 or newer (which supports Drupal 11!)
3. composer require drush/drush
4. vendor/bin/drush config:inspect --filter-keys=system.action.user_cancel_user_action --detail --list-constraints

Proposed resolution

Add validation constraints to:

1. system.action.*:type

This requires looking at the existing code and admin UI (if any) to understand which values could be considered valid. Eventually this needs to be reviewed by the relevant subsystem maintainer.

For examples, search *.schema.yml files for the string constraints:😊

Reach out to @borisson_ or @wimleers in the #distributions-and-recipes.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

More validation 🚀

Release notes snippet

None.

Problem/Motivation

We have multilingual sites setup using a different domainname for each language. We also setup the admin ui so that the translate tab on a node opens up in a modal dialog. When you hit the "edit" for one of the translations, the node edit form is opened also in a modal dialog.
CORS is setup to allow all our domains, supportsCredentials is enabled, methods are POST,GET and OPTIONS. exposedHeaders has the 'X-Drupal-Ajax-Token'.
When the Ajax calls are made to open the node edit forms in the second dialog, the calls are made anonymous. The session token is not send.

Steps to reproduce

Setup multilingual site with at least 2 languages.
Use different domain for each language.
Setup CORS as described above.

Proposed resolution

To solve this, ajax.js needs to configure extra options when doing the requests:
- crossDomain: true
- xhrFields: { withCredentials: true }

Remaining tasks

Check if this has any impact on other Ajax related stuff.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Kinda messed up with the branches in the original ticket 3338518, so started from fresh.

Problem/Motivation

Right now CKEditor shows an option to display an image as "block" wrap text, left, center and right, but not a block right (see attached image).

Steps to reproduce

1. Enable image insertion in CKEditor and enable image align.
2. Create a node with the appropriate text editor.
3. The options are Break Text, Align and wrap left, align and break center, align and wrap right, inline
4. Attempts to add an align and break right with overrides in a module or attempting to patch core do not seem to make the icon option visible.

Proposed resolution

Add an option to allow block right

Problem/Motivation

Opening this following a discussion with @berdir, @xjm, @bbrala, @japerry in slack.

Original slack discussion here: https://drupal.slack.com/archives/C03L6441E1W/p1716842930248339

For the 10-11 cycle, we set 10.3 as the cut-off point where most new deprecations would be for removal in 12.x instead of 11.x. This is so that the majority of modules would only need to be compatible with 10.2 deprecations in order to be compatible with 11.0.

However #3401236: Rename EntityReferenceTestTrait to help discoverability has shown that this was slightly optimistic. The trait deprecated in that issue was deprecated in 10.1 (released June 2023) for removal in 11.0.

June 2024 was the earliest release window for Drupal 11.0.0 to come out, so modules would theoretically not have to support 10.1 and 11.0 at the same time, except they actually do - if they want to test against 11.x alpha and beta releases. Because we intentionally have long alpha/beta windows for major releases, this creates a couple of months or more of overlap between 10.1 and 11.0 at precisely the time we want modules to start working on 11.x compatibility.

If we take June 2026 as the earliest possible release window for Drupal 12 and count backwards from there:

June 2026 - 12.0.0 + 11.4
December 2025: 11.3 (EOL December 2026)
June 2025: 11.2 (EOL June 2026)
December 2024: 11.1 (EOL December 2025)

If we want to avoid the same situation again, the latest that we can deprecate for removal in 12.x would be in the 11.1 minor release, 11.2 would need to start deprecating for removal in Drupal 13.

Steps to reproduce

Proposed resolution

From Drupal 11.2, target all potentially disruptive deprecations for removal in Drupal 13 where possible. Potentially do this for any highly disruptive 11.1/11.0 deprecations too if it's not likely to cause a large maintenance burden.

Exceptions would be:
1. Deprecated modules moving to contrib, for various reasons this is less disruptive closer to the new major release and also not really an API deprecation.
2. @internal code like controller/plugin constructors (unless it's something that is actually going to be very disruptive for some reason)
3. Inherited deprecations from upstream (phpunit, Symfony et al)
4. Deprecations with no replacement and similar situations where cross-minor/major compatibility is less of an issue.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Often, in the course of improving code in Drupal, it becomes necessary to provide code paths that are used specifically to maintain our backwards compatibility promise. It's not appropriate to mark the code as deprecated, as it may include conditionals that are expected to be run, or it may include data transformations that update legacy data to match current expectations while remaining idempotent for modern data, and are thus run on every data set currently.

A common example is providing for dependencies that are added to constructors in a backwards compatible way. In this case, a new optional parameter is added to the end of the constructor, and then a BC layer is added to detect if the parameter is missing, and load it from the container if it is, usually triggering a deprecation error. There are numerous other examples in core. The migration system deprecated the use of CckFieldPlugins in favor of the replacement FieldPlugins, and requires a fair amount of code to manage still-existing CckFieldPlugins that is not technically @deprecated, but should be removed when the Drupal 9 branch is open. Views has a method View::fixTableNames() which exists to update views which may have been saved prior to the 8.3 revisionable entity updates, and imported. Eventually this method should be removed, perhaps in Drupal 9, perhaps later. This method is currently marked deprecated, but should not be, as it is correctly still in use.

Several other examples have been noticed while working on cleaning up deprecations in #3038170: Drupal core's own deprecation testing results

Currently we handle this in a few ways. Sometimes we mark methods as deprecated, which is not correct, and won't work as we are now enforcing proper use of the @deprecated tag. Sometimes there is a comment in the code pointing out that the code exists as a BC layer and should be removed. Sometimes we file follow-ups, and sometimes we do nothing to mark that the code needs to be removed in a later version.

The current documentation on this is at https://www.drupal.org/core/deprecation#how-codepath and says only:

For example when we have a code path handling a deprecated key in a YAML file.
Add @trigger_error('...', E_USER_DEPRECATED) at the start of the code block that handles the backwards compatibility layer. DO NOT add an @deprecated phpdoc annotation to the method or function docblock that contains the code path as this causes IDEs to mark the entire method as deprecated. For example:

// @todo

Other documentation on that page suggests where to trigger an error in certain situations, but does not document ways to mark a particular code block as deprecated and needing to be removed. The main purpose of this policy is to designate a way to mark these code blocks as being scheduled for removal in the code so that we can easily create and use automated tools to make sure that these paths are removed when we open a new major version branch.

The below proposal is a starting point for discussion on how to reign this code in, mark it properly, and make sure it is easy to remove in the next major version.

Proposed resolution

First and foremost, any code that is provided for a bc layer and expected to be removed should have a follow-up issue filed to remove it at the time it is committed. The code should contain an @todo describing what is to be removed/changed, and a link to the issue. Should we have a new tag for this so we can scan the code when the next major branch is open? @bc or something?

When possible, BC layer code should be surrounded by a conditional detecting if it is needed, and if so, an E_USER_DEPRECATED error should be triggered.

If the needed logic is more complicated than one or two lines, it should be moved into its own method (where appropriate). This method should be marked @internal, private, and final. @bc? In this case, both the method and the location from which it is called should be commented with the @todo tag, and with a link to the follow-up issue.

Ideally a patch to remove the code could be posted to the follow-up issue at the time it is created, but keeping the patch rolled correctly may prove too much.

Remaining tasks

Discuss if such a policy is even needed.
Determine best practices
Document

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Must-haves prior to tagging 11.0.0-beta2

Release notes: #3449818: 11.0.0-beta2 release notes

• #3108658: Handling update path divergence between 11.x and 10.x
• #3378393: Hardcode security coverage EOL dates for Drupal 10.last-1 and 10.last
• Address any regressions in 11.0.0-beta1 or 10.3.0-beta1

#3445847: PHPUnit 10 behaves differently when invoked outside web root
#3446026: Adding media library openers use autoconfigure and tags in 10.3.x has BC consequences
#3441010: Container compile crash when a service decorates a destructable service

• Address any straggler deprecation cleanups
• Resolve critical 10.x -> 10.x upgrade path bugs.
• Resolve any 11.0.x-only security or data integrity issues.
• Resolve other D11-only upgrade blockers.
• Update jQuery 4 to a stable version #3449874: Update to a stable version of jQuery 4
• Update jQuery UI to the stable version: #3449875: Update to a stable version of jQuery UI 1.14.0
• Update Symfony 7.1 to the stable version

Should-haves prior to tagging 11.0.0-beta2

• #3421418: [May 2024] Add void return typehints to all test methods
• Evaluate any alpha or beta targets for whether they should be prioritized before beta2.

Hello,

I'd like to add a functionnality for the TextTrimmedFormatter to be able to add an ellipsis and / or word boundaries trim options.

Patch attached.