Hello I have a problem recently update to drupal 8.7.1 but now the personal body class I did in mytheme.theme does not work this is the error that I get

Notice: Indirect modification of overloaded element of Drupal\Core\Template\Attribute has no effect in mytheme_preprocess_html() (line 43 of /home/mytheme/public_html/themes/mytheme/mytheme.theme) #0 /home/mytheme/public_html/core/includes/bootstrap.inc(584): _drupal_error_handler_real(8, 'Indirect modifi...', '/home/mytheme/...', 43, Array) #1 /home/mytheme/public_html/themes/mytheme/mytheme.theme(43): _drupal_error_handler(8, 'Indirect modifi...', '/home/mytheme/...', 43, Array) #2 /home/mytheme/public_html/core/lib/Drupal/Core/Theme/ThemeManager.php(287): mytheme_preprocess_html(Array, 'html', Array) #3 /home/mytheme/public_html/core/lib/Drupal/Core/Render/Renderer.php(437): Drupal\Core\Theme\ThemeManager->render('html', Array) #4 /home/mytheme/public_html/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false) #5 /home/mytheme/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(147): Drupal\Core\Render\Renderer->render(Array) #6 /home/mytheme/public_html/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() #7 /home/mytheme/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(148): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #8 /home/mytheme/public_html/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch)) #9 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #10 /home/mytheme/public_html/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #11 /home/mytheme/public_html/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent)) #12 /home/mytheme/public_html/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #13 /home/mytheme/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #14 /home/mytheme/public_html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /home/mytheme/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(184): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /home/mytheme/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(121): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /home/mytheme/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(75): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true) #18 /home/mytheme/public_html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #19 /home/mytheme/public_html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #20 /home/mytheme/public_html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 /home/mytheme/public_html/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 /home/mytheme/public_html/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #23 {main}.

Problem/Motivation

The workflow transitions are not working properly when using preview mode , prior to saving content.

When clicking to preview and returning to edit mode, the content moderation current state (initial state ) is changed.
The workflow transition when saving would then not be the same ( the "from" being different).

If that new transition is not allowed , it would not even allow saving the modifications
if some rules are set for each independant transition, the whole thing is messed up.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Currently LB has a @todo, which when resolved would introduce dataloss and integrity issues with content revisions:

      if ($entity instanceof RevisionableInterface) {
        // If the parent entity will have a new revision create a new revision
        // of the block.
        // @todo Currently revisions are never created for the parent entity.
        //   This will be fixed in https://www.drupal.org/node/2937199.
        //   To work around this always make a revision when the parent entity
        //   is an instance of RevisionableInterface. After the issue is fixed
        //   only create a new revision if '$entity->isNewRevision()'.
        $new_revision = TRUE;
      }

Work is already underway to fix that in #2937199: Track Layout override revisions on entities which support revisioning. The patch that resolves the @todo goes completely green, despite the actual solution being problematic.

Proposed resolution

Resolve the @todo by removing it and proving with tests why it's actually a required component of the current revisioning model.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#314385: Make position of #description configurable via the API introduced option #description_display which controls placement of the form element #description.

The options for #description_display are "before", "after", "invisible".

But when using the option #description_display with the form element fieldset ('#type' => 'fieldset') the description is always placed after and the Form API ignores the option at all.

How to reproduce it

1. Install Drupal 8 with the Normal profile.
2. Create and enable a small custom module that alter the Node form. On this form add a simple fieldset. Here is a small sandbox module to test with the 3 options (before, after, invisible) https://www.drupal.org/sandbox/tplcom/2575395
3. Go to node/add/page to see the new fieldset. All the fieldset descriptions are displayed after the elements.

Before (description is always displayed after the elements)

After the patch (what we want!)

Proposed resolution

Applying patch from https://www.drupal.org/node/2396145#comment-10372343 fixes the #description_display the issue but it needs work.

Check comment https://www.drupal.org/node/2396145#comment-10374153 for more details about the patch and what needs to be done.

Problem/Motivation

#states do not work with 'datetime' form elements.

Proposed resolution

• Update logic in the Datetime element to handle the nested elements.
• Fix datetime-wrapper twig templates to actually generate a wrapper div.
• Consistently use <label> not <h4> for the datetime wrapper label.

Remaining tasks

1. Write and verify automated tests. Complete. See comments #91-102
2. Markup review of all the changes to the datetime-wrapper twig templates.
3. JavaScript review of the changes to core/misc/states.es6.js.
4. Other reviews + manual testing (optional).
5. Commit.
6. Unblock child issues.

User interface changes

#states actually works on datetime form elements.

Changes to the datetime-wrapper.html.twig templates (default templates from system and both the classy and stable themes) to:

• Actually include a wrapper div (!)
• Always use <label> not <h4> for the label. The label is generated using the existing core theme templates for form labels (form_element_label).

API changes

None.

Data model changes

None.

Original Report

While trying to create a custom field widget containing a "datetime" form element, I discovered that the #states attribute does not work on it.

Some states can be achieved with a workaround: put the datetime element in a container, and put the #states on the container. But this is obviously no clean fix, and it doesn't work for all states. (Works for "visible" for example, but not for "required".)

I was not able to figure out why this is not working, but I noticed that there have been a lot of issues regarding the #states attribute in the issue tracker. Most of them for were for specific elements like submit buttons, select elements with multiple values, ...

Problem/Motivation

States on radios and checkboxes elements are currently broken until #994360: #states cannot check/uncheck 'radios' and 'checkboxes' elements is resolved, but when that issue is fixed another appears.

When the states API manipulates the 'disabled' or 'checked' state of form elements, it looks for the closest 'form-item' or 'form-wrapper' element of the state target and changes the attribute on all of its children.
'checkboxes' and 'radios' elements do not have the 'form-wrapper' class, which causes the wrapper element higher in the hierarchy to be found and have all of its children affected instead of just the desired element.

e.g. with the following form, when the radios element is changed from 'one' to 'two', the checkboxes should be hidden. Instead, the entire fieldset is hidden.

$form['group'] = [
  '#type' => 'fieldset',
  '#tree' => TRUE,
];
$form['group']['radios'] = [
  '#type' => 'radios',
  '#title' => 'Radios',
  '#options' => [
    'one' => 'One',
    'two' => 'Two',
  ],
  '#default_value' => 'one',
];
$form['group']['checkboxes'] = [
  '#type' => 'checkboxes',
  '#title' => 'Checkboxes',
  '#options' => [
    'alpha' => 'Alpha',
    'beta' => 'Beta',
  ],
  '#states' => [
    'visible' => [
      [':input[name="group[radios]"]' => ['value' => 'one']],
  ],
];

Proposed resolution

The issues #2041845: Remove theme_checkboxes() and call theme('container') instead and #2041825: Remove theme_radios() and call theme('container') instead intended to remove the 'checkboxes' and 'radios' templates in favour of a generic 'container' template, which would have the 'form-wrapper' class. These templates can no longer be removed for BC reasons, but they should be made to match the classes of the container template.

Problem/Motivation

The various datetime-wrapper.html.twig templates ignore the #description_display from the form API system.

Proposed resolution

Respect this parameter and display the description accordingly.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The 'checkboxes.html.twig' templates for core, stable, and classy all apply the form-checkboxes class, but only the classy 'radios.html.twig' template applies the form-radios class.

A theme inheriting from stable must override the radios template in order to apply styles in the same way as is possible with checkboxes. Individual checkbox and radio inputs receive the 'form-checkbox' and 'form-radio' classes, respectively (see \Drupal\Core\Render\Element\Checkbox::preRenderCheckbox and \Drupal\Core\Render\Element\Radio::preRenderRadio()).

Proposed resolution

Add the form-radios class to the radios.html.twig templates in core and stable for consistency.

Problem/Motivation

We want to create a roadmap for Drupal 8.8 release.
Starting by putting together a list of our ambitious goals and then prioritize it into:
Must have & Nice to have.

Whatever we cannot complete by the week of October 14, 2019, the scheduled Drupal 8.8.0 Feature Freeze (alpha1 release), we can move to Drupal 8.9 or Drupal 9.

This list will evolve and will be updated through comments and additional conversations.

Some of the items can be achieved by getting help from volunteers in other teams, like Documentation and Translation.

Kanban Board

Proposed resolution

(not sorted by importance)

Improving installation experience
Ambitious goal
Reduce installation time:
(Profiling installation process)
Add an option to install Umami with/without multilingual (#1356276: Allow profiles to define a base/parent profile and load them in the correct order)

SimplyTest improvements:
#3048708: Installation of Umami takes almost 20 minutes(!) and kicks back 504 errors
#3047290: One button Umami drupal installation

Low hanging fruit
#3034784: Displaying translation string counts and string errors is too much detail in the installer

Language Switcher improvement
Low hanging fruit
#3042417: Umami's language-switcher as a drop-down menu

Tour
Ambitious goal
Adding Tour content to many more pages (mostly a documentation effort).
Teaching people Drupal with hands-on experience, explaining backend/frontend choices we made to build Umami.
Low hanging fruit
Improve Tour experience, by loading it automatically after installation.
#3038406: How do we make sure people new to Drupal know about the Umami Tour?

404 page
Ambitious goal
Add a View search results of whatever was typed in the URL.
Low hanging fruit
Theme the page with a friendly message, also relevant to 403 pages.

Multilingual
Ambitious goal
Allow installing Umami in any language by switching from CSV import to localize.drupal.org translation import.

1. #3048283: Read content from Drupal 8 core's demo_umami
2. #3048295: Install Umami in any language (import content from https://localize.drupal.org)

Low hanging fruit
To add RTL functionality in Umami, add Hebrew / Arabic as a 3rd language (mostly content translation effort).

Media Library
Ambitious goal
Add (an external) video and audio to some of the pages / recipes / articles.
Low hanging fruit
#2954378: Use Media images in Umami demo Replace all exising image fields with media fields.

Theme Structure / Layout Builder
Ambitious goal
Update Umami's theme to a component-based design.
Low hanging fruit
Implement Layout Builder on every page, recipe & article.

Json:API
Ambitious goal
FE addition that suggests recipes according to groceries you have at home.
Low hanging fruit

Try Umami
Ambitious goal
#3047290: One button Umami drupal installation One button on Drupal.org that installs for you Umami demo on simplytest platform

Miscellaneous
Low hanging fruit
#3044366: Fix styling of Umami for layout builder
#2985551: Style and show content moderation form in Umami
#2940023: Improve accessibility of Umami's responsive main menu
#3051465: Revert "Taxonomies are only displayed in English"
#3041039: Search for content in current language/#3045362: Search for node content in current language

We should keep an eye on https://www.drupal.org/core/roadmap to see which modules could potentially become stable in the next Drupal release.
In the process of Drupal 8.7 development, Layout Builder and JSON:API modules became stable at the very end of the process.
We can prepare patches in advance for Media Library and other upcoming new functionality that might be ready in time for when Drupal 8.8 is going to be released.

Drupal 9 Wishlist

Multiple types of demo sites
Ambitious goal
Finding free and open content repository, that we can either copy to into our own CSV files or use their APIs directly.
Create a content model for each type of website and import the content into it.
Create one global theme that can work for all these types of websites.

New core theme (Umami)
Ambitious goal
#3054838: Remove umami theme from profile and add it to core/themes

Fresh Images
Ambitious goal
Fresh new photos for Drupal 9

Problem/Motivation

Following #description_display work defined for elements in issue : #314385: Make position of #description configurable via the API and what has been done more specifically for fieldsets here #2396145: Option #description_display for form element fieldset is not changing anything, this issue defines the same work to be done for details type element. Two issue found :

1. The description id is wrong, currently details-description instead of $field_id . '--description as other elements.
2. The description_display position is not taken into consideration.

Proposed resolution

Change template_preprocess_details() in form.inc to include accounting of #description_display element key. Also update the details.html.twig templates to use description_display setting.
NOTE: contrarily to fieldset, the description for details is before by default.

Remaining tasks

- Create a WebBaseTest test to check the rendering of the description position in details.
- Create a patch to solve the two points of this issue.
- Review patch and fix.

User interface changes

Description of details elements will now be positionned before or after details content depending of description_display.

API changes

None: #description_display should already be part of formAPI regarding #314385: Make position of #description configurable via the API.

Hi,

When I trying to update Drupal core to 8.7.0 using composer I am getting the following error.

$ composer require drupal/core:8.7.0 --update-with-dependencies

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- drupal/core 8.7.0 requires egulias/email-validator ^2.0 -> satisfiable by egulias/email-validator[2.0.x-dev].
- Installation request for drupal/core 8.7.0 -> satisfiable by drupal/core[8.7.0].
- Installation request for egulias/email-validator (locked at 1.2.14, required as ^1.2) -> satisfiable by egulias/email-validator[1.2.14].

When I try to update the egulias/email-validator[ package separately it shows:
$ composer require egulias/email-validator:2.0.1 --update-with-dependencies

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for egulias/email-validator 2.0.1 -> satisfiable by egulias/email-validator[2.0.1].
- Can only install one of: egulias/email-validator[2.0.1, 1.2.x-dev].
- Installation request for egulias/email-validator ^1.2 -> satisfiable by egulias/email-validator[1.2.x-dev].

Drupal 8.6.15 reqquires email-validator with ^1.2 version and 8.7.0 requires ^2.0 email-validator.

Any solution? help please.

Problem/Motivation

The "content_moderation_state" entity is a mechansim for tracking state information about content entities. It is exposed through a computed field on entities called moderation_state.

Previously a views relationship was required from entities to "content_moderation_state" in order to display and filter by state. Ideally users shouldn't need to understand how states are stored and should just be able to reason about the "moderation_state" field on their moderated entities directly. For this reason, lets provide first class filtering and displaying of the state by way of the computed field.

Blockers:

#2862041: Provide useful Views filters for Content Moderation State fields
#2852067: Add support for rendering computed fields to the "field" views field handler

Given the "content_moderation_state" entity is going to become @internal, we shouldn't allow people to add a relationship to it. There shouldn't be a reason to once the above blockers are resolved.

Proposed resolution

Remove the views relationship to this entity type.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

With #2799987: Datetime and Datelist element's timezone handling is fragile, buggy and wrongly documented we improved and enforced timezone handling for Datetime and Datelist through the #date_timezone property. We should now make sure its documentation reflects the changes.

#3015647: $element['value']['#date_timezone'] is not a string fatal error. is an example of how #date_timezone has been (ab)used before, and after the new change a fatal error is raised due a string being expected rather than a \DateTimeZone object.

The current documentation for #date_timezone reads:

#date_timezone: The local timezone to use when displaying or interpreting dates. Defaults to the value returned by

Without specifying *a string* is expected.

Proposed resolution

Update the documentation.

Remaining tasks

• Update the #date_timezone documentation, specifying a timezone name string is expected
• Understands if more documentation improvements are needed

User interface changes

Nope.

API changes

No, however change record https://www.drupal.org/node/2880055 doesn't specify a timezone name string is expected so although this changes doesn't change the API it does affect its usage as well as documentation.

Data model changes

No.

The applied validation error messages are not shown for a view exposed filter on failure when "Ajax" is on.

the messages are displayed again on next page load.

There is an older issue opened for Drupal 7

https://www.drupal.org/node/1833322

Recommended solution:


function MODULE_views_ajax_data_alter(&$commands, $view) {
$commands[] = ajax_command_prepend($commands[0]['selector'], theme('status_messages'));
}


Is the correct way to solve the problem or solution should be implemented in views module itself ?

Problem/Motivation

As discoverd in #2832672: [PP-1] Upgrade jcalderonzumba/* for better test performance a test opening a dialog and then peforming actions within the opened dialog are at risk for random failure.

The random failure is caused by a dialog resize/reposition after content has been inserted. Currently there is no way to wait for this as this behavior is debounced.

Currently the random failures do not occur because the Mink Phantomjs driver waits an additional 100ms on each wait statement. However on upgrading the driver or switching to another driver (#2775653: JavascriptTests with webDriver) this problem will become relevant.

Proposed resolution

Either:
1. Provide a better way to assert the dialog has opened.
2. Remove the random failure factor for opening a dialog.

Steps to reproduce:

This issue improves the way we wait for a dialog to open. The reason is random failure and therefore difficult to reproduce.

To reproduce the random fail do the following:
- Apply the patch from #2832672: [PP-1] Upgrade jcalderonzumba/* for better test performance, this will make the random fail occur more often.
- Do not apply the patch from this issue.
- Run the test in views_ui/tests/src/FunctionalJavascript/FilterCriteriaTest.php multiple times untill the test fails.
- See the excellent research in #2832672: [PP-1] Upgrade jcalderonzumba/* for better test performance by @tacituseu to see an explaination on the fails.

I have run the tests on multiple 25x runs locally and I got the fails frequently before applying this patch and no more after applying this patch.

Thanks @michielnugter for the patch. And tacituseu & droplet did a lot of researching on #2832672: [PP-1] Upgrade jcalderonzumba/* for better test performance. Please credit them also if we can.

Problem/Motivation

In Drupal core installation under the Choose language, It suggesting the external link https://localize.drupal.org/download. For better usability, open the external links in a new tab. So the end-user will not affect on-screen navigations.

Proposed resolution

Open the https://localize.drupal.org/download in new tab.

Remaining tasks

Nil

User interface changes

Nil

API changes

Nil

Data model changes

Nil

Release notes snippet

Nil

Problem/Motivation

Resizing a window in \Drupal\Tests\layout_builder\FunctionalJavascript\BlockFormMessagesTest::testValidationMessage() appears to fix a random fail.

Looking at the html again - we have a Placeholder for the "New title" block but we're expecting the block to have been replaced real block and be identified by #layout-builder .block-system-powered-by-block

Proposed resolution

tbd

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

Postponed on #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields, which is introducing the BaseFieldOverride class described in this issue.

Problem/Motivation

• When a new 'base_field_override' config entity is created, BaseFieldOverride::preSave() calls the target entity type's storage handler's onFieldDefinitionUpdate() method, passing it the base field definition as the "previous" definition. And similarly, when the override config entity is deleted, BaseFieldOverride::postDelete() calls onFieldDefinitionUpdate, passing it the base field definition as the "new" definition.
• However, if it happens that a base_field_override config entity is being added to or deleted from a site that also implements an override via ContentEntityInterface::bundleFieldDefinitions(), then the above behavior is incorrect, since the previous definition prior to base_field_override insertion and the new definition after base_field_override deletion is the one returned by ContentEntityInterface::bundleFieldDefinitions(), rather than the base definition.
• The above might be an extreme edge case, because using ContentEntityInterface::bundleFieldDefinitions() rather than config to override base field definition is specifically intended for when you need you content entity type completely decoupled from config, in which case there shouldn't be code adding and removing base_field_override config entities for it.
• Also, it's not really clear what FieldableEntityStorageDefinitionInterface::onFieldDefinitionUpdate() is even for. The only implementation of it in HEAD is a completely empty function, even after #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions. Perhaps we should consider removing it? Do storage handlers need to be notified of non-storage-related changes to field definitions?

Proposed resolution

Discuss the above and figure out what to do.

Remaining tasks

User interface changes

API changes

In bootstrap.inc last modified headers check`s by strongest condition
If modified since and etag headers MUST be exists. And if-modified-since header MUST be equal to last modified ($cache->created) date.

See the https://tools.ietf.org/html/rfc7232#section-3.3

A recipient MUST ignore If-Modified-Since if the request contains an
If-None-Match header field; the condition in If-None-Match is
considered to be a more accurate replacement for the condition in
If-Modified-Since, and the two are only combined for the sake of
interoperating with older intermediaries that might not implement
If-None-Match.

But https://tools.ietf.org/html/rfc2616##section-13.3.4 says

An HTTP/1.1 origin server, upon receiving a conditional request that
includes both a Last-Modified date (e.g., in an If-Modified-Since or
If-Unmodified-Since header field) and one or more entity tags (e.g.,
in an If-Match, If-None-Match, or If-Range header field) as cache
validators, MUST NOT return a response status of 304 (Not Modified)
unless doing so is consistent with all of the conditional header
fields in the request.

I try to use new logic for checking content modified or not.

Problem/Motivation

Occasionally whilst running \Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockPrivateFilesTest::testPrivateFiles there are locks on the cache_config table.

Proposed resolution

tbd

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a