Problem/Motivation

I use hook_form_alter() to alter the views exposed form and to change the widget of some filter. But more than that I need to change related condition in views query as well. To do that properly I need some params, but for now there is now good way to pass params to the query. So I can access the $view (ViewExecutable) object from form, but found no way to add params to it that can be later used in hook_query_alter().

Proposed resolution

As I can see the $views->query is a Drupal\views\Plugin\views\query\Sql object, and it has the query() method. That method constructs the actual query like this: $query = $this->getConnection()->select(...). And then adds some metadata to it like this: $query->addMetaData(). Looks like this is a good way to pass some key => value data to the query.

So it would be great to add the Drupal\views\Plugin\views\query\Sql::addMetaData() method just like the addTag() method that it already has. And then inside the query() method use collected metadata to pass it to the actual sql query object (just like it does with the tags). And then it would be possible to use getMetaData() in hook_query_alter() to apply some advanced logic to the query conditions.

One of the obvious needs of the wysiwyg (ckeditor) is to have stylesheets that styles elements to match the theme front-end. This includes entity embeds, that probably will have class names like ".cards", ".tabs", etc.

Unfortunately, the Claro admin theme stylesheets clash with the site theme because the Claro selectors are WAY too generic. So, like there are Claro stylesheets called "tabs.css" with selectors like ".tabs", and "cards.css" with selectors like ".cards".

Now, a site custom theme is very likely going to have classes called cards and tabs and what not. This causes a problem because Claro's styles are being applied to custom theme styles inside ckeditor on the admin pages. For example, our ".cards" do not have borders, but Claro's do! So I have to write new styles to counteract Claro putting borders on my cards in the wysiwyg.

The point being that Claro's CSS should not be so generic. A class like ".cards" should be more like ".claro__cards" or whatever so that there's no danger of clashing with the user's CSS.

As it stands, I am going to have to write entire stylesheets just to counteract Claro's ill effects on our theme, and I am sure I'm not alone. It would make a lot more sense to me if Claro gave its CSS a namespace of sorts, so it is careful not to mess with the site's theme.

The changes to the UI for list type fields in 10.2 has made it much more cumbersome for adding large lists of options. Instead of entering a simple list of key|value pairs, now each element must be added separately. This works fine for small lists of options but is incredibly cumbersome if you need to add a large list such as states or countries. It would be very useful to bring back the ability to easily add a large list of options. Perhaps a way to toggle between the new allowed values UI and the old textarea UI.

Problem/Motivation

After updating Drupal 10 site from version 10.0.11 to 10.2.1 , getting drupal ajax error on adding media, blocks from layout builder. Also quick edit links are disappeared from blocks ,menus etc

Steps to reproduce

I checked on Drupal 10.2.2

• Open layout builder page (as /node/xxxx/layout)
• Enabled browsder debug tool
• When mouse-over to block, pencil icon is showed at right
• Click the pencil icon, click the delete option, then check the console, below error occured

An error occurred during the execution of the Ajax response: TypeError: Cannot read properties of undefined (reading 'style')

• And right pane showed the opition button about `delete` or `cancel`, push the `cancel` button
• After that, then check the console, below error occured

Uncaught TypeError: Cannot read properties of undefined (reading `style`)

• And click the pencil icon click the delete option again, the right pane is not showed unless you reload the page

Proposed resolution

The reason why this error is in off-canvas.js, because the style property is not exsisted in jQuery type.

https://git.drupalcode.org/project/drupal/-/blob/6a43b511df9e26aa5abf0d1...

• To change the type of $mainCanvasWrapper to NodeListOf and handle when the element is undefined. (I understand the refactor of jQuery css() to use Vanilla (native) that is good things.)
• Or Revert https://git.drupalcode.org/project/drupal/-/commit/6a43b511df9e26aa5abf0...

Remaining tasks

Nothing

User interface changes

Nothing

API changes

Nothing

Data model changes

Nothing

Release notes snippet

Problem/Motivation

The change in validation introduced in #3396628: Fix <ol start> → native CKEditor 5 functionality and fix bug in SourceEditingRedundantTagsConstraintValidator that allowed it to slip by triggers validation errors for previously valid config when "Source" / Source editing button is added and "Manually editable HTML tags" are specified.

The intent of the validation was that because a plugin supported <ol start> that tests should have failed when trying to manually configure source editing to allow start <ol start> on the basis that the UX for source editing is worse that the UX of a plugin.

There are several use cases where this has caused frustration, a lot related to the fact you can no longer allow the class attribute in source editing as it expects you to use the style plugin.

Several use cases were raised where the old behavior is preferred, such as:

• Adding classes that are not supported by the style plugin, e.g. classes can not be added to img elements through the style plugin, but should be able to through manual source editing
• Making classes available through CKEditor templates but not intending them to be selectable via the ckeditor style drop down
• Frameworks such as bootstrap or tailwind which contain utility classes, which can be used by exerienced editors but are not appropriate to all be selected in the dropdown
• Support for classes related to legacy styles or content, which need to be retained but not necessarily "promoted" to the styles plugin to be used

Steps to reproduce

1. Install using the Standard installation profile on Drupal 10.2.3
2. Create a new text format, setting the editor to "CKEditor 5" and adding the following toolbar items: Blockquote, Styles, and Source editor.
3. Configure one style for the dropdown, p.fancy|Fancy Paragraph
4. Add the "Limit allowed HTML tags and correct faulty HTML" text format filter.
5. Save the form. Everything should be fine.
6. Edit the text format. Under "Source editing"> "Manually editable tags", add <blockquote class>, indicating that you want content editors to manually add the `class` attribute to the `blockquote` tag, which is allowed on the CKEditor toolbar.
7. Attempt to save the form. A validation check will prevent the form save: The following attribute(s) can optionally be supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: Style (<blockquote class>).

Proposed resolution

Allow source editing to define what can be edited in source regardless of other plugins that might also allow the change.

At the very least, an option to ignore the error and save anyway would be preferable. There are many use cases for arbitrary-but-allowed source editing including migrations and upgrades for existing Drupal installations with these patterns in place since the allowed HTML feature was converted to source editing with the CKEditor 4 to 5 upgrade.

Remaining tasks

TBC

User interface changes

TBC

API changes

TBC

Data model changes

TBC

Release notes snippet

TBC

Problem/Motivation

Views currently does not show theme suggestions, due to a bug in core: #2118743: Twig debug output does not display all suggestions when an array of theme hooks is passed to #theme
Mark Carver though pointed out in #2118743-167: Twig debug output does not display all suggestions when an array of theme hooks is passed to #theme that views could also use hook_theme_suggestions

Proposed resolution

Use hook_theme_suggestions() instead of arrayed theme hooks.

Remaining tasks

Postponed till #2511548: Add a "context" array variable to all theme hooks and "#context" array property to all elements to provide optional contextual data is finished.

User interface changes

None

API changes

Deprecates ViewsPluginInterface::themeFunctions and ViewExecutable::buildThemeFunctions and replaces them with equivilent themeSuggestions methods.

Data model changes

None

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-data, which targets the jQuery data function.

Steps to reproduce

Proposed resolution

Remaining tasks

See #9 for questions about direction.

• In core/.eslintrc.jquery.json Change "jquery/no-data": 0, to "jquery/no-data": 2, to enable eslint checks for uses of jQuery .data(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery .data() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If you have a drupal/core-recommended composer site, and want to run tests, you're supposed to composer require drupal/core-dev. However, that package doesn't depend on core, so if you're not careful, you end up with a different version of core-dev than the version of core you're using.

Steps to reproduce

1. composer create-project 'drupal/recommended-project:^8.9' d8_9_composer
2. cd d8_9_composer
3. composer require drupal/core-dev

Would expect to get drupal/core-dev for 8.9.x and have a working testable site. Instead, you see this:

Using version ^9.0 for drupal/core-dev
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: don't install drupal/core-dev 9.0.2
    - Conclusion: don't install drupal/core-dev 9.0.1
    - Conclusion: don't install drupal/core-dev 9.0.0
    - Conclusion: don't install drupal/core-dev 9.0.0-rc1
    - Conclusion: don't install drupal/core-dev 9.0.0-beta3
    - Conclusion: don't install drupal/core-dev 9.0.0-beta2
    - Conclusion: don't install drupal/core-dev 9.0.0-beta1
    - Conclusion: don't install drupal/core-dev 9.0.0-alpha2
    - Conclusion: don't install drupal/core-dev 9.0.0-alpha1
    - Conclusion: don't install drupal/core-dev 9.1.x-dev
    - Conclusion: remove masterminds/html5 2.3.0
    - Installation request for drupal/core-dev ^9.0 -> satisfiable by drupal/core-dev[9.0.0, 9.0.0-alpha1, 9.0.0-alpha2, 9.0.0-beta1, 9.0.0-beta2, 9.0.0-beta3, 9.0.0-rc1, 9.0.1, 9.0.2, 9.0.x-dev, 9.1.x-dev].

For this to work, step #3 has to be composer require 'drupal/core-dev:^8.9'.

Proposed resolution

Add a dependency on drupal/core to the drupal/core-dev metapackage so that you always end up with the right version of core-dev based on the version of core you've got.

Remaining tasks

1. Discuss if this is indeed the right solution.
2. Implement it.
3. Tests? Not sure how the composer tests work for stuff like this.
4. Reviews / refinements.
5. RTBC.
6. Commit.

User interface changes

Nope.

API changes

Nada.

Data model changes

Zilch.

Release notes snippet

TBD.

Problem/Motivation

Form modes have 3 property paths that are not yet validatable:

vendor/bin/drush config:inspect --filter-keys=core.entity_form_mode.user.register --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                                                                       
 ---------------------------------------------------------------- --------- ------------- ------ --------------------------------------------------------------------------------------------- 
  core.entity_form_mode.user.register                              Correct   79%           ✅❓   ValidKeys: '<infer>'                                                                         
   core.entity_form_mode.user.register:                            Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   core.entity_form_mode.user.register:_core                       Correct   Validatable   ✅✅   ValidKeys:                                                                                   
                                                                                                    - default_config_hash                                                                      
   core.entity_form_mode.user.register:_core.default_config_hash   Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                                  Regex: '/^[a-zA-Z0-9\-_]+$/'                                                                 
                                                                                                  Length: 43                                                                                   
                                                                                                  ↣ PrimitiveType: {  }                                                                        
   core.entity_form_mode.user.register:cache                       Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   core.entity_form_mode.user.register:dependencies                Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   core.entity_form_mode.user.register:dependencies.module         Correct   NOT           ✅❓   ❌ @todo Add validation constraints to ancestor type: config_dependencies                    
   core.entity_form_mode.user.register:dependencies.module.0       Correct   Validatable   ✅✅   NotBlank: {  }                                                                               
                                                                                                  ExtensionName: {  }                                                                          
                                                                                                  ExtensionExists: module                                                                      
                                                                                                  ↣ PrimitiveType: {  }                                                                        
   core.entity_form_mode.user.register:description                 Correct   Validatable   ✅✅   Regex:                                                                                       
                                                                                                    pattern: '/([^\PC\x09\x0a\x0d])/u'                                                         
                                                                                                    match: false                                                                               
                                                                                                    message: 'Text is not allowed to contain control characters, only visible characters.'↣ PrimitiveType: {  }                                                                        
   core.entity_form_mode.user.register:id                          Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: core.entity_form_mode.*.*        
   core.entity_form_mode.user.register:label                       Correct   Validatable   ✅✅   Regex:                                                                                       
                                                                                                    pattern: '/([^\PC])/u'                                                                     
                                                                                                    match: false                                                                               
                                                                                                    message: 'Labels are not allowed to span multiple lines or contain control characters.'    
                                                                                                  NotBlank: {  }                                                                               
                                                                                                  ↣ PrimitiveType: {  }                                                                        
   core.entity_form_mode.user.register:langcode                    Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                                  Choice:                                                                                      
                                                                                                    callback: 'Drupal\Core\TypedData\Plugin\DataType\LanguageReference::getAllValidLangcodes'↣ PrimitiveType: {  }                                                                        
   core.entity_form_mode.user.register:status                      Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   core.entity_form_mode.user.register:targetEntityType            Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: core.entity_form_mode.*.*        
   core.entity_form_mode.user.register: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=core.entity_form_mode.user.register --detail --list-constraints

Proposed resolution

Add validation constraints to:

1. core.entity_form_mode.*.*:dependencies.module
2. core.entity_form_mode.*.*:id
3. core.entity_form_mode.*.*:targetEntityType

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

To support the model of deployable configuration, Views configuration with filters on taxonomy terms (or any entity reference field for that matter) should use the UUID of the entity chosen.

For example, creating a view which has a filter on a term from a node field should export to configuration with UUID filter values rather than taxonomy term entity IDs.

Current proposal

On the front-end, keep everything using entity IDs. On the back-end (storage), store IDs as UUIDs, and convert them when passing between the front-end.

Tasks

1. Support viewing, editing and saving the filter form with text/autocomplete.
2. Support viewing, editing and saving the filter form with select options.
3. Ensure that views are displaying the correct results.
4. Update existing schema: Ensure that views can be saved and re-read properly, with the same config.
5. Migrate existing data: Add update hook to convert entity IDs in config to UUIDs.
6. Fix test failures.

Original proposal

Add a checkbox to the filter configuration form to allow users to use the uuid of the term as the filter value rather than the tid.

As a stop-gap until this is implemented in core, I implemented it as a custom filter which extends the current taxonomy term id filter. This may help in determining which parts of the code need to be touched when implementing https://gist.github.com/acbramley/1127c4698a9ae86885e03716f47e3281

Problem/Motivation

Because core's recipe uses the config folder to create the configuration, the recipe cannot be re-applied because that configuration already exists in the Drupal site.

This is bad as two recipes cannot depend on the same recipe, as is expected to be possible. This will quickly become apparent in Starshot when users try to add more "site feature" recipes on top of their "site" recipes.

Steps to reproduce

Create two recipes that have dependencies on core/recipes/image_media_type
Apply the first
Then, apply the second and verify it fails.

Proposed resolution

Rework the standard recipes to to use the createIfNotExists (formerly ensure_exist) config action to create the needed configs.

This is already done in the administrator_role and content_editor_role recipes.

Recreating all of the configs using this method may not be completely possible now. We will most likely need additional config actions, a lot of which are being worked on in #3303127: Determine which core config entity methods should be config actions.

Remaining tasks

Doing it.

User interface changes

N/A

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

While using CKeditor 4 I can resize table, but not on CKE5.

On 2 colums table, even when I put Image with 600x275px and choose CKE5 image size to 100%, Drupal will resize to smaller size while there is long text on another column.

This CK5 behavior makes WYSIWYG editor useless. To meet my need, I must manually add CSS styles to table in CKE5 .
So, I must reactived CKE4 to have WYSIWYG behavior in Drupal 9/10.

This is how it looks in CKEditor 5:

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

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.

Problem/Motivation

This is an issue that we haven't had to deal with since the Drupal 6 to Drupal 7 upgrade path, but now we do again.

The following scenarios are broken:

hook_update_N()

system_update_100000() is added to 11.0.x and 10.3.x

[time elapses]

system_update_100100() is added to 11.1.x to support a new feature, it is not backported to 10.4.x

[time elapses]

A critical bug fix which is eligible for backport to 10.4.x, but requires a small update, is committed to 11.1.x

[dragons emerge from the darkness, volcanos erupt]

If this update is added as system_update_100101() and backported to 10.4.x, then when 10.4.x sites are updated to 11.1.x, they won't run system_update_100100() because their schema version will be higher already.

If this update is added as system_update_100001() in 11.1.x, and 10.4.x, it won't run on 11.x sites because their schema version will be 100100 already.

hook_post_update_NAME()

This is less of an issue, but still a problem:

system_post_update_fix_config() is added to 11.1.x, it is backported to 10.4.x, but not 11.0.x because it's security-only.

If a site updates from 10.4.x to 11.0.x, then the post update goes 'missing' from the code base. It will then re-emerge when the site updates again to 11.1.x or 11.2.x

Sequential backports to minor branches without skipping a release are OK though for post updates regardless of how far they go back, since they don't interfere with other post updates.

Proposed resolution

This is only a serious problem for hook_update_N() due to sequential update ordering. Because post updates are tracked individually and order isn't guaranteed, the only issue with those is a site updating from 10.4 to 11.0 (i.e. 'backwards' in terms of minor release parity).

For hook_update_N(), we can add a small API addition to the update system, which will probably be exclusively used by core updates.

1. An 11.x hook_update_N() would be added as normal, with no extra method calls or metadata. Let's say system_update_11100()

2. When that same update is backported to 10.x, we backport it with it's own update number, say system_update_10400().

In system_update_10400(), we call \Drupal::service('update.update_hook_registry')->skipUpdate(11100)

This logs the module, update being run, and future update, to a key value collection.

When a site updates to 11.1 from 10.4, it will have this information in key value. In update_do_one() we then check against the key value collection, and if an 11.1 update should be skipped, we skip it and log a success message.

The huge advantage of this is that there is no 11.x-specific code dealing with the 10.4.x update numbers, we just need the API in place to check key/value and that's it. 11.x updates can be committed with no API changes. 10.4 update backports need to call one method with a small amount of information.

If a site tries to update to 11.0 from 10.4, then in terms of database updates it will be going 'backwards' - however because we have the key value store, we can detect this, and issue an update requirements error telling them to go to 11.1 instead.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Currently postponed on #3208766: Add UUID to sections

Problem/Motivation

Some complex page layouts leverage multiple section containers for long-form content, where reordering sections would be helpful.

Proposed resolution

Allow re-ordering of sections through the UI in mobile-friendly, accessible manner.

Completed tasks

• Determine the best UI for re-ordering sections
• Write patch with functionality
• Write tests
• Community review and confirmation
• Usability review

Remaining tasks

Additional tasks and optimizations prior to follow-up review:

• #3080606-77: [PP-1] Reorder Layout Builder sections: Move the "Reorder sections" trigger to be in-line with each section, alongside the remove X and the "Configure section" link. This is inspired by http://www.drupal.org/project/lb_ux. Reasons for this include: the "reorder sections" is something likely done while looking at a given section, and scrolling back to the top takes you away from that focus. Also, the "Save layout" and "Discard buttons" are actual buttons that perform a standard operation, and it's easy to scroll past that and miss the "Reorder sections" link
• #3080606-77: [PP-1] Reorder Layout Builder sections: By having the reorder section be triggered from a specific section, we can highlight that section in the tabledrag. Compare to the highlight effect when you use the "Move" contextual link for any block in Layout Builder. See also the Block UI, after placing a new block, it scrolls to and highlights the newly placed box.
• #3080606-77: [PP-1] Reorder Layout Builder sections: Add a second column to the tabledrag with the human-readable label of the layout plugin used for each section. This additional metadata will be very helpful when trying to keep track of which section is which, especially if you haven't added custom labels to your sections (by default they are only numbered). If needed, it should be possible to specify a greater width for the off-canvas sidebar.
• #3080606-84: [PP-1] Reorder Layout Builder sections: Try to make the UI for reordering sections as much like the UI for reordering components as you can. That applies to the interaction in the off-canvas sidebar. It also applies to the link that opens the sidebar. For reordering components, I think that is a contextual link, along with Configure and Delete. Would it make sense to have similar contextual links, or a drop button, for sections?
• #3080606-84: [PP-1] Reorder Layout Builder sections: I see links to some screenshots in #74, but nothing under "User interface changes" in the issue summary. Once the suggestions in #77 are implemented, it will help to get updated screenshots and add them to the issue summary.
• Receive @tim.plunkett (subsystem maintainer) review signoff (per #3080606-55: [PP-1] Reorder Layout Builder sections and #3080606-60: [PP-1] Reorder Layout Builder sections, as stated in #3080606-77: [PP-1] Reorder Layout Builder sections).
• #3080606-85: [PP-1] Reorder Layout Builder sections: I think this issue needs a change record, so I am adding the tag for that. It might also need a release-note snippet at the end of the issue summary.

User interface changes

Needed, see #3080606-84: [PP-1] Reorder Layout Builder sections or remaining tasks above for process to create UI changes.

API changes

None anticipated.

Data model changes

None anticipated.

Release notes snippet

TBD

Follow-up issues

TBD
#3293787: Section reorder through click-and-drag
#3293789: Replace "Show Content Preview" checkbox with collapseable sections

Screenshots

New reorder section task

Off canvas to reorder sections

•	Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getCssAssets() (line 133 of core\lib\Drupal\Core\Asset\AssetResolver.php).
•	Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getJsAssets() (line 239 of core\lib\Drupal\Core\Asset\AssetResolver.php).
•	Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getJsAssets() (line 251 of core\lib\Drupal\Core\Asset\AssetResolver.php).
•	Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getJsSettingsAssets() (line 199 of core\lib\Drupal\Core\Asset\AssetResolver.php).

Problem/Motivation

This was added to support RDF module which is now in contrib, we should deprecate then remove it.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

assert($typed_config instanceof Mapping) in system.post_update.php gives a failure, but it is difficult for less experienced developers to know what caused that failure.

The failure is frequently caused by contributed modules and a quick search for 'assert($typed_config instanceof Mapping' in google reveals many modules have had this issue. Letting the developer know what the failure is could make the process much easier for them to find the culprit module.

Steps to reproduce

Attempt to run update database with a contrib module that fails this assertion

Proposed resolution

Add a description to the assertion

Remaining tasks

Review merge request
Backport to 10.3.x

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

If we have a view with multiple displays for example:
Display 1
Display 2
Feed 1 (attached to display 1)
Feed 2 (attached to display 2)

The method getAttachedDisplays() when called on the display handler for Display 1 will return [Feed 1, Feed 2] instead of the expected [Feed 1].

Proposed resolution

// Go through all displays and search displays which link to this one.
    foreach ($this->view->storage->get('display') as $display_id => $display) {
      if (isset($display['display_options']['displays'])) {
        $displays = $display['display_options']['displays'];
        if (isset($displays[$current_display_id])) {
          $attached_displays[] = $display_id;
        }
      }
    }

if (isset($displays[$current_display_id])) needs an extra check for !empty($displays[$current_display_id]) because for the feed displays, the value $displays[$current_display_id] is set but is 0 if the feed is not attached.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet