Problem/Motivation

\Drupal\FunctionalJavascriptTests\WebDriverWebAssert has a number of deprecation errors, e.g.

    @trigger_error('Support for statusCodeEquals is to be dropped from JavaScript tests. See https://www.drupal.org/node/2857562.');

This was added in 8.5.0, we should either actually drop this support, or reinstate it.

Steps to reproduce

Proposed resolution

- create meta issue to get rid of usage
- change deprecation message according standards for 11.0

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

After deleting the email listed under (/admin/reports/updates/settings), each time a cron run is started, the following error is created:
Error sending email (from info@website.de to with reply-to not set)

Steps to reproduce

go to: /admin/reports/updates/settings

1. Empty the list of email addresses
2. After the system finds a new update, based on your configuration of "Check for updates" and "Email notification threshold"
3. Run cron

The error disappears after adding back an Email into the notify list. But will reappear if it the email is delated again.

Doing a single export on update.settings results in: 
notification: emails: - ''


On a different website where this error doesn't appear we get: 
notification: emails: { }

Here the notification email was never set.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

We noticed that issue 2519362 improving menu edit form usability (https://www.drupal.org/i/2519362) reverted for 10.3. the fix for long stings breaking node edit form that was fixed with a 1-line css change for 10.2 in issue 3400762 (https://www.drupal.org/i/3400762) where the pcss file containing the codeline was renamed.

For more details about the problem addressed see the original issue #3400762: Long string breaks the layout of Claro.

Proposed resolution

On core/themes/claro/css/layout/form-two-columns.css line 23 instead of

grid-template-columns: 3fr minmax(22.5rem, 1fr);

we just need to add the second minmax function

grid-template-columns: minmax(0, 3fr) minmax(22.5rem, 1fr);

Problem/Motivation

In #540008: Add a container parameter that can remove the special behavior of UID#1 an approach was taken where we can simply flag tests that are failing if we turn off user 1's super user powers, so that they can be taken care of in a followup. This issue is to collect all of these followups.

The goal is to have no tests in Drupal core that rely on UID1's special privileges so that we:

1. Know these tests are correctly assigning the necessary permissions to run
2. Can turn off the super user access policy in D11, knowing it won't break core
3. Can remove the super user access policy in D12, providing an admin account recovery tool to replace it

Steps to reproduce

Go into any of the tests flagged with:

  /**
   * {@inheritdoc}
   *
   * @todo Remove and fix test to not rely on super user.
   * @see https://www.drupal.org/project/drupal/issues/3437620
   */

And:

1. Remove the code below that sets the usesSuperUserAccessPolicy to TRUE.
2. Run the test to see which test methods are failing

Proposed resolution

Assign the right permissions to make the test go green without the super user access policy. Those few tests that specifically test said policy can obviously stay, but will be removed along with the policy in D12.

Remaining tasks

1. core/modules/file/tests/src/
   • Kernel/SaveTest.php

Problem/Motivation

Too many theme functions and theme templates that duplicate the same resulting markup structure.

Proposed resolution

1. Consolidate theme functions and templates into single implementations
2. Leverage theme hook suggestions to allow targeted theme/template overrides and variable preprocessing.

Procedure

1. Go through the list and identify similar things and group them together. See Twig conversion/refactoring/clean-up issues
2. Find existing issues or create a new to consolidate groups of similar theme functions, using theme suggestions and preprocess to handle minor differences (or just skipping the differences if they're superfluous).

Details

• List of all theme functions and templates
  "unusable" means the function is located in a file that is not registered to hook_theme; "unclear" means that it is not clear where the theme function/template is located. (see #3.1)
• Related: Twig conversion/refactoring/clean-up issues
• Related: all theme functions and their status of conversion into Twig

Remaining tasks

Blockers

Not actually blockers for consolidating theme functions and templates, but without resolving these issues, modules and themes will not be able to easily target/override a specialized theme hook, which means a critical regression compared to D7:

• #2004872: [meta] Theme system architecture changes

Issues Pt 1 (theme functions that are grouped together)

Entities
TODO Can we do entity.html.twig entity--node.html.twig etc?

links

• #1595614: [meta] Remove all the theme functions and templates in core that simply output a link. Replace with #type 'link' render arrays
• #1833932: Convert theme_system_compact_link() into a #type link
• #2031301: Replace theme_more_link() and replace with #type 'more_link'
• #2036195: Remove views-more.html.twig and replace with #type link render arrays

tables

• #1812684: [meta] Consolidate all table templates and add theme_hook_suggestions
• #1751194: Introduce hook_theme_suggestions[_HOOK]() and hook_theme_suggestions[_HOOK]_alter()
• #2035897: remove theme_image_style_list() and call theme('table__image_styles__list') instead
• #2035903: Remove theme_image_style_effects() and call theme('table__image_styles__effects') instead.
• #2035905: Remove theme_book_admin_table and call theme('table__book_admin') instead
• #2092343: Consolidate forum.module and remove call to _theme_table_cell() within template_preprocess_forum_topic_list()

item lists

• #1813426: [meta] Consolidate all item list templates and add theme_hook_suggestions
• #311011: Replace links.html.twig with item-list--links.html.twig
• #1222254: Remove theme_task_list() and call theme('item_list__tasks') instead.
• #1777332: Replace theme_menu_link() and menu-tree.html.twig with a single Twig template

containers

• #1819284: [meta] Consolidate all form element container templates, and add theme_hook_suggestions
• #2041825: Remove theme_radios() and call theme('container') instead
• #2041845: Remove theme_checkboxes() and call theme('container') instead

Issues Pt 2 (other theme functions that need attention)

• #2032695: Use item-list.html.twig instead of views_view_summary.html.twig
• #54898: Add a description-list.html.twig template (ex. definition list)
• #1598886: Clean up pager theme functions
• #1777324: Remove theme_user_list() from core
• #1973418: Remove tablesort-indicator.html.twig, use CSS instead
• #1842232: Consolidate use of admin-page.html.twig and system-admin-index.html.twig
• #1812724: Consolidate all form element templates and add theme_hook_suggestons
• #2076301: Remove views-mini-pager.html.twig, use a pager theme suggestion instead
• #1926344: Consolidate search-result.html.twig and search-results.html.twig
• #2231853: Rename maintenance-page template into page--maintenance + install-page into page--maintenance--install

User interface changes

None.

API changes

None.

Related Issues

• #1781372: Add an API for listing (configuration) entities will replace administrative listing functions for Configurables.
• #1833920: [META] Markup Utility Functions
• #939462: Specific preprocess functions for theme hook suggestions are not invoked
• #1751194: Introduce hook_theme_suggestions[_HOOK]() and hook_theme_suggestions[_HOOK]_alter()
• #1804488: [meta] Introduce a Theme Component Library

Problem/Motivation

Following #2844452: Export configuration YAML strings as multiline, multiline syntax is used for yml that contains newline characters. This has caused a problem with a certain migration yml that describes doing a find-replace involving newlines. After a few configuration imports and exports, "\n" gets transformed into ''. The configuration for the process plugin starts out like this:

  plugin: str_replace
  source: post_content
  regex: TRUE
  search: "/(\r\n)+/"
  replace: "\n"

Some time later (apparently after any other configuration is changed), this will get exported using the multiline syntax:

  plugin: str_replace
  source: post_content
  regex: TRUE
  search: "/(\r\n)+/"
  replace: |

Then some time after that, the config will get exported like this:

  plugin: str_replace
  source: post_content
  regex: TRUE
  search: "/(\r\n)+/"
  replace: ''

which is very different from what we started with.

Steps to Reproduce

The bug takes two "round trips" of encoding and decoding to reveal itself. Here are some commands that can be run in drush.

drush ev 'print json_encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(["foo" => "\n"])))))'

Expected output is {"foo":"\n"}
Actual output: {"foo":""}

Compare this to adding bar next to the newline, which works fine.

drush ev 'print json_encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(["foo" => "bar\n"])))))'

Expected output is {"foo":"bar\n"}
Actual output: {"foo":"bar\n"}

What happens with other strings that are composed only of newlines?

drush ev 'print json_encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(["foo" => "\n\n"])))))'

Expected output is {"foo":"\n\n"}
Actual output: {"foo":""}

drush ev 'print json_encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(["foo" => "\n\n\n"])))))'

Expected output is {"foo":"\n\n\n"}
Actual output: {"foo":"\n"}

drush ev 'print json_encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(\Drupal\Component\Serialization\YamlSymfony::decode(\Drupal\Component\Serialization\YamlSymfony::encode(["foo" => "\n\n\n\n"])))))'

Expected output is {"foo":"\n\n\n\n"}
Actual output: {"foo":"\n\n"}

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

Umami does a good job of showing what's possible with Drupal core and no custom modules (except default content), however it still has some limitations:

1. There are a lot of template overrides and hard-coded assumptions about fields, we can probably just use display mode config/layouts and CSS. An if we can't that's a problem we should fix in the rest of core so we can fix in Umami.

2. It's falling behind on some core features - i.e. the responsive card listing of recipes on tags, doesn't use views responsive grid

Steps to reproduce

Proposed resolution

Remaining tasks

Old issue, but correctly identifying some of the problems: #2938911: Umami theme hardcodes too many assumptions about the install profile and site configuration

#3425104: Umami views should use responsive grid

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

follow up #3041659: Remove the layout tab from translations because Layout Builder does not support translations yet

Part of #3044386: [META] Make Layout Builder layouts translatable

Right now you are not able to translate layouts at all.

The most common use case is probably translating the block labels and inline blocks but having the actual layouts not change from language to language. For different layout per language: see #3040487: Allow Independent Layout Override Translations

Proposed resolution

1. Provide access to the Layout table on translations
2. On Translations the Layout builder would only allow translating labels and inline blocks
3. Translated settings for block would be stored a new field that would be translatable(the current Layout field would still be untranslatable)
4. Most blocks could only have labels as translated settings
5. Inline blocks could additionally have a block revision ID stored.

Remaining tasks

• Get#3013197: Cloning an implementation of SectionListInterface does not deep clone the Section or SectionComponent objectscommitted.
• Write more tests for Inline blocks. <-- We are here.
• Needs update path test for existing content before this change

User interface changes

API changes

Data model changes

Must-haves prior to tagging 11.0.0-beta2

Release notes: #3449818: 11.0.0-beta2 release notes

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

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

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

Should-haves prior to tagging 11.0.0-beta2

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

Problem/Motivation

Error accessing property of undefined, when resizing page with a dialog opened.

caught TypeError: Cannot read properties of undefined (reading 'settings')
 at HTMLDocument.resetSize (dialog.position.js?v=10.0.8:85:32)
 at later (debounce.js?v=10.0.8:37:23)

Steps to reproduce

1. Open a page and open a dialog: in my case, I use Layout Builder and can reproduce this problem when configuring a block in page node layout
2. With the dialog opened, resize the window
3. Error shows up in console

Proposed resolution

By looking into the function 

resetSize(event) {…
}

So it looks like the events parameter passed in this function are not the same. 
When resizing, they can be of type resize or type drupalViewportOffsetChange (called by debounce.js).

And if event is of type drupalViewportOffsetChange, data attribute is undefined, causing the error accessing event.data.settings

Remaining tasks

None

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Problem/Motivation

This task is a proof-of-concept for #3404409: [Plan] Gradually replace Drupal's AJAX system with HTMX as requested by @nod_.

Reference Links

• Ajax API
• HTMX reference documentation
• HTMX contrib module

Remaining tasks

1. One or two examples (at least) of replacements for existing core ajax
2. A list of the various ajax commands we have in core and their feasibility
   (with a very rough complexity estimate easy/hard) with htmx
   • #wrapper (content replacement) does this use InsertCommand or one of it's descendants for implementation?
   • AddCssCommand
   • AddJsCommand
   • AfterCommand
   • AlertCommand
   • AnnounceCommand
   • AppendCommand
   • BeforeCommand
   • ChangedCommand
   • CloseDialogCommand
   • CloseModalDialogCommand
   • CssCommand
   • DataCommand
   • FocusFirstCommand
   • HtmlCommand
   • InsertCommand
   • InvokeCommand
   • MessageCommand
   • OpenDialogCommand
   • OpenModalDialogCommand
   • OpenOffCanvasDialogCommand
   • PrependCommand
   • RedirectCommand
   • RemoveCommand
   • ReplaceCommand
   • RestripeCommand
   • SetDialogOptionCommand
   • SetDialogTitleCommand
   • SettingsCommand
   • TabledragWarningCommand
   • UpdateBuildIdCommand
   • UpdateSelectionCommand
3. Test runs don't need to be green, although it' be nice if a couple of them
   were passing.
4. can we use this to handle ajax form submit? if yes, how complex does it
   look? would be great to drop our jquery formsubmit fork
5. A big thing here is to improve DX, so a couple of examples of how it could
   make it easier to introduce some ajax stuff in contrib/projects would be
   good.
6. rough dependency evaluation
   (See Criteria for adding dependencies)
7. BC strategy (support existing calls, or a new codepath altogether, etc.)
   I'm not too keen on two separate mods. I feel it'll make adoption much, much
   slower than spending time on the BC layer even if it takes a long time. (we
   can always put restrictions on what the BC layer can do) if we have 2 code
   paths, we'd need a contrib module to bridge the two and let contrib
   maintainers test with htmx easily without changing their code

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

It is currently not possible to change the width and height of the media library modal. The values are hard-coded (in MediaLibraryUiBuilder::getDialogOptions()) and not changeable.

In #3127867-7: MediaLibraryWidget should use the media_library.ui_builder service when fetching modal dialog options, @seanB said:

I've had more questions about changing the width and height of the modal. We have discussed things like an alter hook before but since the class is also used in a lot of javascript we should not make it easy for people to change this.

As a first step I can see making this method non-static and fetch the options via the service is a good step to help with this. Calling the static method on the class is definitely not developer friendly. I guess if we make the width and height configurable this would even help other people from not needing to override the service as well, but that can be a followup.

This is that follow-up.

Steps to reproduce

N/A

Proposed resolution

Make the dimensions configurable in some way -- ideally as settings of the Media Library field widget.

Remaining tasks

Write a patch with tests
Review and commit

User interface changes

TBD; possibly a couple of new configuration options for the Media Library field widget.

API changes

None.

Data model changes

The Media Library field widget may get a couple of new settings.

Release notes snippet

TBD

Problem/Motivation

MySQL has released a new version of its database. It is version 8.4 and it has been promoted to a LTS version. MySQL has currently 2 LTS versions. The other one is 8.0. That version will be end of life in April 2026. See: https://en.wikipedia.org/wiki/MySQL
Drupal 12 will have to set the minimum required version for MySQL to at least 8.4. We shall need to do so, because Drupal 12 will be released after MySQL 8.0 will go EOL.

Steps to reproduce

https://dev.mysql.com/doc/relnotes/mysql/8.4/en/news-8-4-1.html

Proposed resolution

Add daily testing with new LTS and decide when to upgrade

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Blocks are some of the most widely used config entities. They should be validatable. This would be very valuable for the Recipes Initiative, especially now that Recipes uses config validation (see #3405328: [meta] Make recipes safer to use in the real world by supporting config validation and rolling back a broken recipe for details).

Proposed resolution

This can easily become a huge scope, so limit the scope to be reviewable:

1. Make block.block.* validatable.
2. Introduce type: block.settings.block_content:* to fix the accidental leftovers from when content blocks ("custom blocks" in Drupal 7) were split out — see #5
3. Make one concrete block plugin with settings fully validatable: the search block (type: block.settings.search_form_block)

.

4. Open blockers for essential problems that are out of scope:
   1. ✅ Reduction by 11 LoC in this MR: #3426309: Add config validation for weights (blocks, filters, etc. all use weights)
   2. ✅ Reduction by 1 file/11 LoC in this MR: #3426324: ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module
5. Open follow-ups for non-essential problems encountered along the way — see under "remaining tasks"

Remaining tasks

1. ✅ Implement proposed solution
2. ✅ Get tests passing
3. ✅ Search module must provide update path for search_form_block blocks'page_id setting
4. Explicit test coverage for each top-level property of a Block config entity in BlockValidationTest.

Follow-ups:

1. #3426278: [PP-1] Deprecate unused `provider` exported property from Block config entities
2. #3426279: [PP-1] Deprecate `null` as valid `weight` for Block config entities
3. #3426302: [PP-1] Deprecate and remove `status` and `info` settings from `block_content` blocks

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

Underscore.js was added to core as a dependency of Backbone.js. Outside of Backbone related code, our usage has been very light. It could take a while to remove all Backbone related code from core on #3145958: [META] Re-evaluate use of Backbone.js in core, so in the mean while we could remove our dependency on Underscore.js.

Proposed resolution

1. #3270395: Remove use of underscore from editor.admin.js and filter.filter_html.admin.js
2. Ensure QuickEdit is moving Image integration library there, instead of having it in Image, in #3265140: Move QuickEditImageController from image to quickedit.
3. Have a child issue to deprecate the library, which will be postponed on #3228986: [Meta] Tasks to deprecate Quick Edit.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As part of an automatic updates system we will need to decide if we need special considerations for multi-site installations.
Of course all the sites in a multi-site installation will be updating the same core code base.

At the very least if we allow all sites in a multi-site installation to perform automatic updates there will need to be a some locking system that prevent multiple sites from attempting an update at the same time whether through cron or through a form. Our current lock systems don't handle locking across multiple sites.

Another problem will be database updates. For a multi-site with just a few sites this may be easy to handle by just visiting update.php for each site after the core update is performed on 1 site. We should determine if having the update in the UI presents any new problems or if this just the same problem we have now with multi-site and database updates. One thing that is different is that currently because core updates now have to be performed outside of Drupal itself the person doing the update is likely aware that site is within a multi-site installation, whereas if this just a module an admin can turn on and run they might be aware of the affect it would have on other sites.

Proposed resolution

Here some ideas for solutions

For support:

1. Don't support multi-sites in the MVP
2. Support multi-site but warn the admin when performing the update that this will affect other sites
3. Only support multi-sites if a flag is set in sites.php, this setting could specific which site(s?) can perform updates

For the locking problem we could implement \Drupal\Core\Lock\LockBackendInterface and create a Lock that writes a lock file somewhere in core itself since our system will require a writable file system anyways. This could keep multiple sites from performing an update at the same time.

We will likely not support database updates in the MVP but it would be good to have a plan for once we do, at least good documentation what needs to be done on all sites in multi-site manually.

Remaining tasks

Determine the plan

Problem/Motivation

Update from 10.2.7 to 10.3.0 with error message as

The website encountered an unexpected error. Try again later.

InvalidArgumentException: The callable definition provided "[Drupal\claro\ClaroPreRender,tablePositionSticky]" is not a valid callable. in Drupal\Core\Utility\CallableResolver->getCallableFromDefinition() (line 69 of core/lib/Drupal/Core/Utility/CallableResolver.php).
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 432)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array) (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 55)
__TwigTemplate_a3164d23252000faf92139dbdc6c86e5->doDisplay(Array, Array) (Line: 360)
Twig\Template->yield(Array) (Line: 335)
Twig\Template->render(Array) (Line: 38)
Twig\TemplateWrapper->render(Array) (Line: 33)
twig_render_template('core/modules/update/templates/update-report.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('update_report', Array) (Line: 491)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 238)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 231)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 57)
Drupal\advban\AdvbanMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Please help.

Thank you very much.

Problem/Motivation

As example TermStorageInterface& CommentStorageInterface are overloaded with "implementation details" methods that should be moved to separate "repository" services like SearchPageRepository& BlockRepository

Proposed resolution

Implement new services & deprecate old methods before 9.x

Remaining tasks

discus, agree, file patches & change records

User interface changes

no

API changes

only introduce new services & deprecate old ones, TBD

Data model changes

no

Problem/Motivation

Draft mode returns wrong revision of includes. I get default revision of second level paragraph instead of latest revision.

Technical problem:
When trying to access the working revision entity data with resourceVersion=rel:working-copy and using includes, the current revision of the referenced entities is being returned by the method "resolveIncludeTree" in IncludeResolver class. This method should return the data as per the revision being passed in the API query or the working revision.

Steps to reproduce

Install Content moderation;
Add support version negotiation for any entity type: "https://git.drupalcode.org/project/drupal/-/merge_requests/1365.patch"
Create paragraph type A;
Create paragraph type B;
Add paragraph reference field to paragraph A;
Create node with paragraph A (+ paragraph B inside A)
Publish node;
Create draft with changed B;
Check node json data with resourceVersion=rel:working-copy. Returned wrong revision of includes.

Proposed resolution

web/core/modules/jsonapi/src/IncludeResolver.php
loads included entity by id
$targeted_entities = $entity_storage->loadMultiple(array_unique($ids));

I suggest to load entities by revision id:
$targeted_entities = $entity_storage->loadMultipleRevisions(array_unique($revision_ids));