Problem/Motivation

Search page config entity is not yet fully validatable:

.vendor/bin/drush config:inspect --filter-keys=search.page.user_search --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                                                                       
 ---------------------------------------------------- --------- ------------- ------ --------------------------------------------------------------------------------------------- 
  search.page.user_search                              Correct   80%           ✅❓   ValidKeys: '<infer>'                                                                         
   search.page.user_search:                            Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   search.page.user_search:_core                       Correct   Validatable   ✅✅   ValidKeys:                                                                                   
                                                                                        - default_config_hash                                                                      
   search.page.user_search:_core.default_config_hash   Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                      Regex: '/^[a-zA-Z0-9\-_]+$/'                                                                 
                                                                                      Length: 43                                                                                   
                                                                                      ↣ PrimitiveType: {  }                                                                        
   search.page.user_search:configuration               Correct   NOT           ✅❓   ❌ @todo Add validation constraints to ancestor type: search.plugin.user_search              
   search.page.user_search:dependencies                Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   search.page.user_search:dependencies.module         Correct   NOT           ✅❓   ❌ @todo Add validation constraints to ancestor type: config_dependencies                    
   search.page.user_search:dependencies.module.0       Correct   Validatable   ✅✅   NotBlank: {  }                                                                               
                                                                                      ExtensionName: {  }                                                                          
                                                                                      ExtensionExists: module                                                                      
                                                                                      ↣ PrimitiveType: {  }                                                                        
   search.page.user_search:id                          Correct   Validatable   ✅✅   Regex:                                                                                       
                                                                                        pattern: '/^[a-z0-9_]+$/'                                                                  
                                                                                        message: 'The %value machine name is not valid.'                                           
                                                                                      Length:                                                                                      
                                                                                        max: 166                                                                                   
                                                                                      ↣ PrimitiveType: {  }                                                                        
   search.page.user_search:label                       Correct   Validatable   ✅✅   Regex:                                                                                       
                                                                                        pattern: '/([^\PC])/u'                                                                     
                                                                                        match: false                                                                               
                                                                                        message: 'Labels are not allowed to span multiple lines or contain control characters.'    
                                                                                      NotBlank: {  }                                                                               
                                                                                      ↣ PrimitiveType: {  }                                                                        
   search.page.user_search:langcode                    Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                      Choice:                                                                                      
                                                                                        callback: 'Drupal\Core\TypedData\Plugin\DataType\LanguageReference::getAllValidLangcodes'↣ PrimitiveType: {  }                                                                        
   search.page.user_search:path                        Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: search.page.*                    
   search.page.user_search:plugin                      Correct   Validatable   ✅✅   PluginExists:                                                                                
                                                                                        manager: plugin.manager.search                                                             
                                                                                        interface: Drupal\search\Plugin\SearchInterface                                            
                                                                                      ↣ PrimitiveType: {  }                                                                        
   search.page.user_search:status                      Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   search.page.user_search:uuid                        Correct   Validatable   ✅✅   Uuid: {  }                                                                                   
                                                                                      ↣ PrimitiveType: {  }                                                                        
   search.page.user_search:weight                      Correct   Validatable   ✅✅   Range:                                                                                       
                                                                                        min: -2147483648                                                                           
                                                                                        max: 2147483647                                                                            
                                                                                      FullyValidatable: null                                                                       
                                                                                      ↣ 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=search.page.user_search --detail --list-constraints

Proposed resolution

Add validation constraints to missing properties.

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 #recipes.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

More validation 🚀

Release notes snippet

None.

My module does some tasks via Batch API. To avoid duplicating code, I want to do those same tasks during a cron run by programmatically starting and executing the batch without trying to redirect the user to the standard batch job progress bar thingie. There seems to be the facility for this by setting the 'progressive' value of the $process_info array to FALSE, but by the same token, there doesn't seem to be a way to do that - it's hard-coded to TRUE . From D6's form.inc (D7's version is the same in this regard):

function batch_process($redirect = NULL, $url = NULL) {
  $batch =& batch_get();

  if (isset($batch)) {
    // Add process information
    $url = isset($url) ? $url : 'batch';
    $process_info = array(
      'current_set' => 0,
      'progressive' => TRUE, // <= HERE
      'url' => isset($url) ? $url : 'batch',
      'source_page' => $_GET['q'],
      'redirect' => $redirect,
    );
    $batch += $process_info;

    if ($batch['progressive']) {
      // Clear the way for the drupal_goto redirection to the batch processing
      // page, by saving and unsetting the 'destination' if any, on both places
      // drupal_goto looks for it.
      // […snip…]
      drupal_goto($batch['url'], 'op=start&id='. $batch['id']);
    }
    else {
      // Non-progressive execution: bypass the whole progressbar workflow
      // and execute the batch in one pass.
      require_once './includes/batch.inc';
      _batch_process();
    }
  }
}

Unless I'm missing something, this means that, though the functionality exists to do what I want to do, it's not actually possible to do so without hacking core - the code in that "else" branch will never, ever execute. One dead kitten later, I get the expected result.

However, I will allow that I'm just misunderstanding how to use an esoteric feature of this esoteric API and that doing what I need to do is possible without slaughtering kittens; in which case, a bit of edumacation would be appreciated.

Proposed resolution

Set the progressive status in the batch based on batch definition e.g.

  $operations = ['my operations'];
  $batch = [
    'title' => 'My batch runs in single run',
    'operations' => $operations,
    'progressive' => FALSE,
  ];
  batch_set($batch);
  batch_process();

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Language entity is not yet fully validatable:

.vendor/bin/drush config:inspect --filter-keys=language.entity.en --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                                                                       
 ----------------------------------------------- --------- ------------- ------ --------------------------------------------------------------------------------------------- 
  language.entity.en                              Correct   83%           ✅❓   ValidKeys: '<infer>'                                                                         
   language.entity.en:                            Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   language.entity.en:_core                       Correct   Validatable   ✅✅   ValidKeys:                                                                                   
                                                                                   - default_config_hash                                                                      
   language.entity.en:_core.default_config_hash   Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                 Regex: '/^[a-zA-Z0-9\-_]+$/'                                                                 
                                                                                 Length: 43                                                                                   
                                                                                 ↣ PrimitiveType: {  }                                                                        
   language.entity.en:dependencies                Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   language.entity.en:direction                   Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: language.entity.*                
   language.entity.en:id                          Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: language.entity.*                
   language.entity.en:label                       Correct   Validatable   ✅✅   Regex:                                                                                       
                                                                                   pattern: '/([^\PC])/u'                                                                     
                                                                                   match: false                                                                               
                                                                                   message: 'Labels are not allowed to span multiple lines or contain control characters.'    
                                                                                 NotBlank: {  }                                                                               
                                                                                 ↣ PrimitiveType: {  }                                                                        
   language.entity.en:langcode                    Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                 Choice:                                                                                      
                                                                                   callback: 'Drupal\Core\TypedData\Plugin\DataType\LanguageReference::getAllValidLangcodes'↣ PrimitiveType: {  }                                                                        
   language.entity.en:locked                      Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   language.entity.en:status                      Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   language.entity.en:uuid                        Correct   Validatable   ✅✅   Uuid: {  }                                                                                   
                                                                                 ↣ PrimitiveType: {  }                                                                        
   language.entity.en:weight                      Correct   Validatable   ✅✅   Range:                                                                                       
                                                                                   min: -2147483648                                                                           
                                                                                   max: 2147483647                                                                            
                                                                                 FullyValidatable: null                                                                       
                                                                                 ↣ 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. Install language module./vendor/bin/drush en language -y
5. vendor/bin/drush config:inspect --filter-keys=language.entity.en --detail --list-constraints

Proposed resolution

Add validation constraints to missing properties.

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 #recipes.

Remaining tasks

MR

User interface changes

None.

API changes

None.

Data model changes

More validation 🚀

Release notes snippet

None.

Problem/Motivation

We are running a quite big multi domain drupal site (all separate databases but running on the same database server) and found that in some cases we had lots of translation strings which needed to be updated within deployment of new versions.

Updating these would often trigger an update to the field 'version' in the table 'locales_location', which would end up being comparably slow. The reason we found was that the WHERE clause would contain a search by the field 'name', and that one is not indexed.

UPDATE locales_location SET version='8.8.8'
WHERE (sid = '5760') AND (type = 'path') AND (name = '/our/custom/path');

We created a composite index for the contained fields and could see that our database load dropped by ~50% (!) immediately after that.

CREATE INDEX sid_type_name on locales_location (sid,type,name);

Point is that we actually do not want to do anything custom to Drupal's Core, respectively the core database structure if we can avoid it, and there might be reasons why there's no index on this field. Clearly creating an index could slow down operations like INSERT a bit. But this table seems to see far more SELECTs or UPDATEs where 'name' is involved.

So what I'm hoping to achieve here is either confirmation this should be considered an improvement and go into Drupal Core, or getting an answer explaining why this index is a bad idea.

Thank you in advance!

Proposed resolution

Index 'name' field in locales_location table

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

System module settings has 2 property paths that are not yet validatable:

vendor/bin/drush config:inspect --filter-keys=system.file --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.file                              Correct   67%           ✅❓   ValidKeys: '<infer>'                      
   system.file:                            Correct   Validatable   ✅✅   ValidKeys: '<infer>'                      
   system.file:_core                       Correct   Validatable   ✅✅   ValidKeys:                                
                                                                            - default_config_hash                   
   system.file:_core.default_config_hash   Correct   Validatable   ✅✅   NotNull: {  }                             
                                                                          Regex: '/^[a-zA-Z0-9\-_]+$/'              
                                                                          Length: 43                                
                                                                          ↣ PrimitiveType: {  }                     
   system.file:allow_insecure_uploads      Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                     
   system.file:default_scheme              Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints here  
   system.file:temporary_maximum_age       Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints here  

Steps to reproduce

Proposed resolution

Add validation constraints to:

1. system.file:default_scheme
2. system.file:temporary_maximum_age

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

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

Many tests creates actions by using only id and plugin.
Eg.

    $action = Action::create([
      'id' => 'entity_save_action',
      'plugin' => 'entity:save_action:entity_test_mul_changed',
    ]);
    $action->save();

or

    $action = Action::create([
      'id' => 'entity_delete_action',
      'plugin' => 'entity:delete_action:entity_test_mulrevpub',
    ]);
    $action->save();

These tests starts failing if we don't make type: nullable.

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

ContentLanguageSettings entity is not yet fully validatable:

.vendor/bin/drush config:inspect --filter-keys=language.content_settings.node.article --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                                                                       
 ------------------------------------------------------------------------------------------ --------- ------------- ------ --------------------------------------------------------------------------------------------- 
  language.content_settings.node.article                                                     Correct   74%           ✅❓   ValidKeys: '<infer>'                                                                         
   language.content_settings.node.article:                                                   Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   language.content_settings.node.article:_core                                              Correct   Validatable   ✅✅   ValidKeys:                                                                                   
                                                                                                                              - default_config_hash                                                                      
   language.content_settings.node.article:_core.default_config_hash                          Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                                                            Regex: '/^[a-zA-Z0-9\-_]+$/'                                                                 
                                                                                                                            Length: 43                                                                                   
                                                                                                                            ↣ PrimitiveType: {  }                                                                        
   language.content_settings.node.article:default_langcode                                   Correct   Validatable   ✅✅   Choice:                                                                                      
                                                                                                                              callback: '\Drupal\language\Entity\ContentLanguageSettings::getAllValidDefaultLangcodes'↣ PrimitiveType: {  }                                                                        
                                                                                                                            ↣ NotNull: {  }                                                                              
   language.content_settings.node.article:dependencies                                       Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   language.content_settings.node.article:dependencies.config                                Correct   NOT           ✅❓   ❌ @todo Add validation constraints to ancestor type: config_dependencies                    
   language.content_settings.node.article:dependencies.config.0                              Correct   Validatable   ✅✅   NotBlank: {  }                                                                               
                                                                                                                            ConfigExists: {  }                                                                           
                                                                                                                            ↣ PrimitiveType: {  }                                                                        
   language.content_settings.node.article:dependencies.module                                Correct   NOT           ✅❓   ❌ @todo Add validation constraints to ancestor type: config_dependencies                    
   language.content_settings.node.article:dependencies.module.0                              Correct   Validatable   ✅✅   NotBlank: {  }                                                                               
                                                                                                                            ExtensionName: {  }                                                                          
                                                                                                                            ExtensionExists: module                                                                      
                                                                                                                            ↣ PrimitiveType: {  }                                                                        
   language.content_settings.node.article:id                                                 Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: language.content_settings.*.*    
   language.content_settings.node.article:langcode                                           Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                                                            Choice:                                                                                      
                                                                                                                              callback: 'Drupal\Core\TypedData\Plugin\DataType\LanguageReference::getAllValidLangcodes'↣ PrimitiveType: {  }                                                                        
   language.content_settings.node.article:language_alterable                                 Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   language.content_settings.node.article:status                                             Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   language.content_settings.node.article:target_bundle                                      Correct   Validatable   ✅✅   EntityBundleExists: '%parent.target_entity_type_id'↣ PrimitiveType: {  }                                                                        
   language.content_settings.node.article:target_entity_type_id                              Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: language.content_settings.*.*    
   language.content_settings.node.article:third_party_settings                               Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: language.content_settings.*.*    
   language.content_settings.node.article:third_party_settings.content_translation           Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   language.content_settings.node.article:third_party_settings.content_translation.enabled   Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   language.content_settings.node.article: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. Install Demo: Umami profile./vendor/bin/drush si demo_umami -y
5. vendor/bin/drush config:inspect --filter-keys=language.content_settings.node.article --detail --list-constraints

Proposed resolution

Add validation constraints to missing properties.

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 #recipes.

Remaining tasks

MR

User interface changes

None.

API changes

None.

Data model changes

More validation 🚀

Release notes snippet

None.

Problem/Motivation

After doing a recent installation of Drupal 9.4.5, we came across the following problem and error message when browsing at:
Comment: Type Comment, Manage default display page: /admin/structure/comment/manage/comment/display
Config: core.entity_view_display.comment.comment.default

Error message displayed in logs at: /admin/reports/dblog

Type: system
Message	Entity view display 'node.article.default': Component 'comment' was disabled because its settings depend on removed dependencies.
Severity: Warning

 
Tested with:

• Drupal core: 9.4.5 Standard installation profile
• PHP 7.4

 
Problem: Unfortunately, as a result, the Comment field is disabled when displaying Article Nodes (Hidden).

Steps to reproduce

So the steps to reproduce should be quite straight forward:
1 - Install a new site with the Standard profile.
2 - Browse to Comment/Comment manage display: /admin/structure/comment/manage/comment/display
3 - Check error logs: /admin/reports/dblog

Initial investigation

After doing an initial investigation, the error message would seem to come from the following piece of code:
https://git.drupalcode.org/project/drupal/-/blob/9.4.5/core/lib/Drupal/C...

          // If there are unresolved deleted dependencies left, disable this
          // component to avoid the removal of the entire display entity.
          if ($this->getPluginRemovedDependencies($renderer->calculateDependencies(), $dependencies)) {
            $this->removeComponent($name);
            $arguments = [
              '@display' => (string) $this->getEntityType()->getLabel(),
              '@id' => $this->id(),
              '@name' => $name,
            ];
            $this->getLogger()->warning("@display '@id': Component '@name' was disabled because its settings depend on removed dependencies.", $arguments);
            $changed = TRUE;
          }

It would seem a lot of this code relates to issue: #2562107-77: EntityDisplayBase should react on removal of its components dependencies.

After doing some basic debugging, breaking at this point in code resulted in the following stack trace:

array:55 [▼
0 => array:7 [▼
"file" => "/web/core/lib/Drupal/Core/Config/ConfigManager.php""line" => 497
"function" => "onDependencyRemoval""class" => "Drupal\Core\Entity\EntityDisplayBase""object" => Drupal\Core\Entity\Entity\EntityViewDisplay {#2650 ▶}
    "type" => "->""args" => array:1 [▶]
  ]
  1 => array:7 [▼
    "file" => "/web/core/lib/Drupal/Core/Config/ConfigManager.php""line" => 360
    "function" => "callOnDependencyRemoval""class" => "Drupal\Core\Config\ConfigManager""object" => Drupal\Core\Config\ConfigManager {#857 ▶}
    "type" => "->""args" => array:4 [▶]
  ]
  2 => array:7 [▼
    "file" => "/web/core/modules/user/src/Form/EntityPermissionsForm.php""line" => 88
    "function" => "getConfigEntitiesToChangeOnDependencyRemoval""class" => "Drupal\Core\Config\ConfigManager""object" => Drupal\Core\Config\ConfigManager {#857 ▶}
    "type" => "->""args" => array:2 [▶]
  ]
  3 => array:7 [▼
    "file" => "/web/core/modules/user/src/Form/EntityPermissionsForm.php""line" => 173
    "function" => "permissionsByProvider""class" => "Drupal\user\Form\EntityPermissionsForm""object" => Drupal\user\Form\EntityPermissionsForm {#2057 ▶}
    "type" => "->""args" => []
  ]
  4 => array:5 [▼
    "function" => "access""class" => "Drupal\user\Form\EntityPermissionsForm""object" => Drupal\user\Form\EntityPermissionsForm {#2057 ▶}
    "type" => "->""args" => array:3 [▶]

    ...

 
Mostly, with this chain of calls:

[... Multiple calls before ...]
Drupal\user\Form\EntityPermissionsForm:permissionsByProvider
Drupal\Core\Config\ConfigManager:getConfigEntitiesToChangeOnDependencyRemoval
Drupal\Core\Config\ConfigManager:callOnDependencyRemoval
Drupal\Core\Entity\EntityDisplayBase:onDependencyRemoval

 
The code of these functions seems to be related to #2850973: ConfigEntityInterface::onDependencyRemoval() called with incorrect dependency list.
 
In short, the reason the problem happens is because:
When the Manage Display Comment page is displayed, a list of all config depending on 'comment.type.comment' is created.
Since the default display of comments 'core.entity_view_display.comment.comment.default' depends on 'comment.type.comment' and since 'core.entity_view_display.node.article.default' depends on 'core.entity_view_display.comment.comment.default' it is also added to the list of dependencies.
core.entity_view_display.node.article.default > core.entity_view_display.comment.comment.default > comment.type.comment
 
The affected "cross" dependency is due to the fact the Node, type Article, default display 'core.entity_view_display.node.article.default' uses the default comment formatter (to display the Comment field), which points to the default display of the Comment, type Comment 'core.entity_view_display.comment.comment.default', see:
https://git.drupalcode.org/project/drupal/-/blob/9.4.5/core/modules/comm...
In particular lines around 270:

        if ($display = EntityViewDisplay::load("comment.$bundle.$mode")) {
          $dependencies[$display->getConfigDependencyKey()][] = $display->getConfigDependencyName();
        }

 
From a logic perspective it certainly makes sense to allow the default comment formatter, and Plugins in general to react to configuration changes on Entity Displays.
For example, it would probably make sense adding a specific handling case for the default comment formatter: Drupal\comment\Plugin\Field\FieldFormatter\CommentDefaultFormatter:onDependencyRemoval, to check whether the referenced display still exists and capture any changes to the settings, much like it's currently done for the 'ImageFormatter', see:
https://git.drupalcode.org/project/drupal/-/blob/9.4.5/core/modules/imag...
 

Work-around/Temporary solution

Note the problem can be fixed temporarily by removing the config dependency either programmatically, or by importing the modified config through the backend (at '/admin/config/development/configuration/single/import/') or from its file (edit file 'config/sync/core.entity_view_display.node.article.default.yml', remove the line 'core.entity_view_display.comment.comment.default' under 'config' and import).
But of course the config is added back the next time the Node Article display 'core.entity_view_display.node.article.default' is saved.
 
Lastly, since we're really unsure how to approach the problem and the config dependency system seems to have a lot of moving parts, we found the following issues that could potentially be related or where some work is carried around Plugins 'getPluginRemovedDependencies' and 'getPluginRemovedDependencies':

• #2786841: Entity reference fields should add selection handler config dependencies
• #2865710: Dependencies from only one instance of a widget are used in display modes
• #2579743: Config entities implementing EntityWithPluginCollectionInterface should ask the plugins to react when their dependencies are removed

We would greatly appreciate to have your feedback and more particularly, if anyone would have any pointers or guidance on what could be the best approach to finding a solution to the problem.
Feel free to let us know if you have any questions, if anything is unclear or if more information would be needed, we would surely be glad to help.
Thanks in advance.

Problem/Motivation

If a form has a CKEditor 5 text area on a form and also has some action that opens a dialog with a different CKEditor 5 text area, the modal dialog doesn't function 100%. At least, but maybe not limited to, the link button in the dialog does not work at all.

I confirmed this issue on Drupal 9 and Drupal 10 branches.

Steps to reproduce

1. install standard profile
2. add $settings['extension_discovery_scan_tests'] = TRUE; to the settings file
3. Enable ckeditor5_test module
4. Modify \Drupal\ckeditor5_test\Controller\CKEditor5DialogTestController.php into a form like \Drupal\ckeditor5_test\Form\CKEditor5DialogTestForm
5. Add a text_format element above the original link element
6. view the route /ckeditor5_test/dialog
7. Verify the link in the initial CKEditor works fine
8. Open the dialog by clicking the "Add Node" link
9. Verify the link in the dialog CKEditor doesn't work at all

Proposed resolution

Remaining tasks

User interface changes

None

API changes

Data model changes

Release notes snippet

Problem/Motivation

JSON:API responses are currently sent with the application/vnd.api+json mimetype. This is not one of the supported File types that CloudFront compresses. Furthermore, it seems that this is not a common mimetype enabled in nginx or apache config. For example this is the list of mimetypes in the DDEV nginx config.

By changing the mimetype to application/json we would get gzip compression out of the box for a lot of people. I'm certain there is a reason why we need to use application/vnd.api+json, so perhaps this is a simple "won't fix". Would be good to get some discussion here.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Dynamic page cache currently ignores cacheability information from route access results which could lead to unexpected edge cases. Imagine a page where the access is decided per user bases but the content does not vary per user. Without adding user context to the render array/response of the page, the dynamic page cache module is not going to cache it per user.

Having this fixed is currently a blocker of another issue and the original fix for this problem were invented there: #3278759: [PP-1] Access cacheability is not correct when "view own unpublished content" is in use See also: https://git.drupalcode.org/project/drupal/-/merge_requests/8198#note_317834

Original description

Discovered in #2869426: EntityResource should add _entity_access requirement to REST routes.

See #2869426-28: EntityResource should add _entity_access requirement to REST routes, #2869426-29: EntityResource should add _entity_access requirement to REST routes and #2869426-83: EntityResource should add _entity_access requirement to REST routes in particular.

#29:

I could be wrong, but I remember that we once discussed that it is by design that route access cacheability is *not* considered by dynamic page cache because dynamic page cache runs *after* route access checking.

But maybe I misunderstood something here.

To my surprise 😲 and fear 😱, this was NEVER DISCUSSED! Zero mentions of route access. #2429617-219: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!) mentions it. But doesn't dive in deeper. So I instead looked at every occurrence of access. Again nothing mentioned.

But I think @Berdir is right. It's just unfortunate that despite Dynamic Page Cache having such detailed test coverage, this is not something that is explicitly tested. (If it were, then the change made to \Drupal\Core\EventSubscriber\RouteAccessResponseSubscriber::getSubscribedEvents() should trigger a test failure.)

And I think the reason this is only coming up now and not months or years ago, is that the REST module's responses are atypical. Unlike pretty much all other responses, the controller in question (\Drupal\rest\Plugin\rest\resource\EntityResource::get()) has been:

1. Doing its own route/response-level access checking.
2. Significantly varying the contents of the response based on that access checking.

(The closest analogies are block and entity rendering, but those are not route/response-level, they're intra-response-level.)

Proposed resolution

TBD

Remaining tasks

1. Fix #3452426: Insufficient cacheability information bubbled up by UserAccessControlHandler that was identified in comment 26 by kristiaanvandeneynde OCD/spidy-sense
2. Get the #3452181: VariationCache needs to be more defensive about cache context manipulation to avoid broken redirects so it can spot potential issues revealed by this fix
1. Fix #3454346: JsonApiRequestValidator does not set cacheable metadata when the filter allows the request that was discovered in the VariationCache hardening issue
2. Fix #2719721: BreadcrumbBuilder::applies() mismatch with cacheability metadata that was discovered in the VariationCache hardening issue

User interface changes

None.

API changes

None.

Data model changes

Yes: Dynamic Page Cache would vary not just by the Response's cacheability, but also by the route access result's cacheability.

Problem/Motivation

Access cacheability is not correct when the "view own unpublished content" is in use, leading to improperly cached render arrays.

Steps to reproduce

(See even more minimalist reproduction steps is MR !8198)

1. Standard install
2. Add an entity reference field to the Page content type called "Related Articles" where article content can be referenced.
3. Configure the "Related Articles" field to display as a rendered entity.
4. Create Content Editor named "Dan"
5. Log in as Dan
6. Create an Article named "Dan's Article".
7. Create a Page named "Test Page" and add "Dan's Article" as a Related Article.
8. As the admin, unpublish "Dan's Article"
9. As Dan, View "Test Page". You will see "Dan's Article" rendered in pink. Good.
10. Create a new Content Editor named Flan.
11. Log in as Flan.
12. As Flan, view "Test Page". You will NOT see "Dan's Article". Good.
13. Clear Caches.
14. As Flan, view "Test Page". You will NOT see "Dan's Article". Good.
15. As Dan, view "Test Page". You will NOT see "Dan's Article". This is not correct.

Note that you will never see MORE than you are supposed to see. This is not an access bypass problem. Rather you will potentially see less than you are supposed to see.

In this particular case, the incorrect cacheable metadata is being created within EntityReferenceFormatterBase::getEntitiesToView:

$access = $this->checkAccess($entity);
// Add the access result's cacheability, ::view() needs it.
$item->_accessCacheability = CacheableMetadata::createFromObject($access);

Proposed resolution

Bubble up user cache context when there is no other option, since the lack of proper cache context on the final render result causes this problem.

Remaining tasks

1. Fix #2973356: Cacheability information from route access checker access results are ignored by dynamic_page_cache because it is currently a blocker of fixing this one, see more details in https://git.drupalcode.org/project/drupal/-/merge_requests/8198#note_317834

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/A

Problem/Motivation

Discovered while working on #3072906: Deprecate and remove jQuery UI datepicker
Core currently uses native datepickers when browsers support them. This approach introduces accessibility and consistency problems
Currently, If a browser supports native datepicker, then that is used instead of the jQueryUI datepicker. date.es6.js uses Modernizr to determine native datepicker support, and only applies jQueryUI to the ~9% of browsers that do not support it.
The accessibility capabilities and overall experience of native datepickers vary greatly depending on the browser. For example:
(Win 10) Edge:
- no indication of day of week (not a11y necessarily, but not consistent with other browsers).
- Can't exit datepicker with escape key, only the close button.
-Testing with NVDA. Datepicker will open with return key if field is in focus. Nothing is announced to make this evident (but unsure if SR users expect this behavior). Once opened, screenreader does not inform the user that it has been opened. Within the datepicker, screenreader does not announce any activity. Tab/Arrow activity has no response from screenreader. The only way to exit is to tab to the close button and hit return. This is unlikely to occur since the screenreader does not inform the user of what element they are on within the datepicker.
- While this technically meets contrast/not color-only requirements, it's awfully difficult to distinguish which column is focused.

(OSX) Opera & Firefox:
-Can't open datepicker with keyboard navigation
-An interactable "clear all" button is provided that can't be accessed via keyboard navigation

(OSX) Opera & Chrome
-Screenreader says that values in the stepper can be increased/decreased with control-option-arrow up/down. This key combination does not change the value. Arrow keys on their own do (which is better than nothing, but contradicts the instructions read to the user)

(OSX) Chrome
-Datepicker not at all usable for screenreader users, and the results too inconsistent to accurately summarize as text.

It's also worth noting that the accessibility of jQueryUI's datepicker is quite good, but that is unfortunately being deprecated due to jQueryUI end of life. It's still serves as a good reference

Proposed resolution

Find an accessible datepicker library or create a custom one that provides better accessibility.
Libraries evaluated:

• https://pikaday.com/ Screenreader does not read dates when focused - just reads the month/year twice and "Previous Button Next Button"
• https://flatpickr.js.org - poor keyboard navigation
• http://t1m0n.name/air-datepicker/docs/ (not to be confused with AirBnB's datepicker) - Screenreader does not repond to any actions within Datepicker
• Whatsock datepicker is quite good. However, it is part of a much larger library, it was not clear how to install it, the code is obfuscated, and the repos have very little activity (it's been almost two years since anything other than minor changes were implemented)
• http://haltersweb.github.io/Accessibility/date-picker.htmlDoes not work with IE11
• https://bootstrap-datepicker.readthedocs.io/en/latest/ screenreader does not acknowledge any activity within datepicker
• react-dates The smallest the minified library can get is 425k, even after stripping out momentjs locale files. That's a few K shy of the all of jQueryUI. There are also a few styling conflicts with Drupal core that could probably be addressed but likely not worth the effort for such a giant library.
• http://www.oaa-accessibility.org/examplep/datepicker1/ Keyboard nav is good. Screenreader is not perfect but responds where it should - changing what it says is not too difficult. However, from what I can tell there is no repo, just an online example (would love to find out otherwise). If no other good options come up, this could be used as a starting point for a custom one.

Another possibility is removing datepickers altogether, which I don't suspect would get full buy-in since there are benefits to datepickers that can't be replicated in other ways, and it would be taking it away from users accustomed to having it.

Remaining tasks

Add research findings from #20 to the issue summary.
Find a good library or created one

User interface changes

New datepicker.

API changes

Quite likely

Data model changes

n/a

Release notes snippet

n/a

Problem/Motivation

LocalesLocationAddIndexUpdateTest::testExistingIndex() is failing on PostgreSQL. The array of indexes has unique keys and the keys are sorted.

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/pgsql...
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/pgsql...

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In the StaticMap process plugin, it's documented that mapping NULL is supported: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/migra...

 * A NULL can be mapped. If the value of the source property 'foo' is NULL then
 * the value of the destination property bar will be 'to'.
 *
 * @code
 * process:
 *   bar:
 *     plugin: static_map
 *     source: foo
 *     map:
 *       NULL: to
 * @endcode

Doing this causes a YAML parse error

Non-string keys are not supported. Quote your evaluable mapping keys instead at line 57 (near "NULL: 0").

If you quote the NULL string then you don't get the parse error, but that then maps the literal string "NULL" not the NULL value so it doesn't have the desired effect.

Mapping NULL is required (in my case) to map a value when a field is empty.

Steps to reproduce

Either remove documentation for the support, or come up with a solution

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Found two warnings in dblog

Warning: Undefined array key "type" in Drupal\Core\Theme\ThemeManager->render() (Zeile 292 in html/core/lib/Drupal/Core/Theme/ThemeManager.php).:

Warning: Undefined array key "template" in Drupal\Core\Theme\ThemeManager->render() (Zeile 333 in html/core/lib/Drupal/Core/Theme/ThemeManager.php).:

Steps to reproduce

Don't remove from /html/sites/development.services.yml

  twig.config:
    debug: true
    auto_reload: true

part.

Proposed resolution

Use admin/config/development/settings instead

Problem/Motivation

If an autocomplete input's text fills the input, the text will appear underneath the magnifying glass icon.

This is also an issue in Seven, but may be less noticeable due to the size of the inputs and icons.

Steps to reproduce

• Set the claro theme as an administration theme
• Find a form with an autocomplete input field such as a tags input that accepts multiple values ( In my case I used the default tags field in
  article content type )
• Type a bunch of letters into the autocomplete field to fill it to the point that it fills the input all the way to the magnifying icon.
• See that the letters will overlap with the magnifying icon

Proposed resolution

Add margins and padding on either the right or left side depending on the text direction.

User interface changes

Before

After

Node bundles in the standard profile:
article
page

User bundle:
user

Block bundle:
basic

Taxonomy bundle:
tags

Why is only one plural and the other default bundles singular? We should aways be consistent when providing defaults.

I get that changing the machine name would possibly mess up a lot of sites because folks unfortunately just install Standard profile and run with it instead of considering their own install profile with their own bundles.

However, I stand that with the next major version change, we should strongly consider refactoring the "out of the box" entity bundles and re-think what kind of DX confusion is caused by having both plural and singular used across the "default" bundle names.

I have many times run into issues with 'tags' (or any bundle name that is plural) due to this inconsistency.

I am not saying we should enforce people to not use plurals in bundle names, we should encourage consistency.

If you try to use #ajax on a Views exposed filter form element, the callback is never invoked. This was discussed at length in the Views issue queue here:

#1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback

The same bug exists in the version of Views in Drupal 8 core. As merlinofchaos wrote:

Views are $_GET forms and they specifically remove the form_id and form_build_id and form_token because they are 'submitted' even when they aren't submitted. That means the standard #ajax tools don't work with them, since those rely on being able to cache the form in core's form cache. That system is to naive to work with core's filters. I've never really tried to do anything like this in D7 yet, so I don't know what the solutions might be, but I can say that it's going to provide very ugly URLs if you hack the form id back in.

The proposed solution is to add a little custom JS magic so that we identify all the form info via after_build callbacks, stash those in JS settings, and then inside the JS, we reattach the relevant form info to the #ajax-enabled form elements so that their callbacks can be properly invoked.

Hi,

In my project, I have a view with an exposed form style : value required.
When I load the view page, there are not result, it's ok.
But, if I submit it with empty values, there are results.

I will upload a path soon.

Thanks for your responses.