I installed a second language (Swedish) and set it as default in /admin/config/regional/language.

Now all my views suddenly show Swedish as original language, which means I can not translate them to Swedish.

How do I change them back to English?

Changing the default language back to English and clearing the caches did not work.

Problem/Motivation

#3055180: [META] Symfony 5 compatibility resolved Symfony 4 deprecations in Drupal 9 for Symfony 5. We want to keep resolving deprecations in Symfony 5 towards Symfony 6 compatibility. If it is feasible to move directly from Symfony 4 in Drupal 9 to Symfony 6 in Drupal 10, it would be useful to have that option.

Proposed resolution

Keep surfacing new deprecated APIs affecting Drupal as new Symfony deprecations are added in Symfony 5 versions. This issue is used to update Symfony 4 to Symfony 5 for testing purposes only. This is also a META tracking issue for individual fixes that should go into child issues. Repeat until Symfony 5.4 is available.

Remaining tasks

We have a problem with dev requirement Prophecy. It has to do with "static" return type hinting. See: https://github.com/phpspec/prophecy/issues/527

Must haves

None at this time.

Should have for Drupal 9/10, must have for Drupal 10/11

• #3162981: [PP-1] [Symfony 6] Use Symfony\Component\HttpFoundation\InputBag where appropriate instead of ParameterBag
• #3209723: [Symfony 6] Symfony\Component\HttpKernel\HttpKernelInterface::MASTER_REQUEST is deprecated, use ::MAIN_REQUEST instead
• #3258380: [Symfony 6][Second try] A number of methods of the class Drupal\Core\TypedData\Validation\ExecutionContext are considered internal and Drupal should not override them.

If we are to update to Symfony 6 in Drupal 10, we also need to bridge the gap somehow for deprecation checking and updates. See #3196027: Contrib support solution needed for potential Symfony 4 to 6 upgrade, Symfony 5 only deprecations are not available in Symfony 4.

API changes

Ideally none. See child issues.

Data model changes

None.

Release notes snippet

Drupal has been updated for compatibility with Symfony 5.4. This includes adding return type hints to some methods where we were unable to find any examples or use-cases for subclassing. However, should custom code subclass one of these methods, a return type hint can be added. A list is available in the change record

Since this issue https://www.drupal.org/project/drupal/issues/3029819 is closed, can anyone explain how to add the Page Title block as a block in the layout builder?

Thanks!

I am running a Drupal 8 site behind a load balancer/reverse proxy. There are three Drupal servers, one primary database and one replication database. We have cookie connection persistence enabled on the load balancer.

The configuration works well, except for CSS and JS aggregation. The servers have inconsistent sets of files in the sites/default/files/[js|css] directories, and this can result in 404 errors when people are loading the pages.

I have cleared cache repeatedly on the servers, but cannot get consistent results. As a result, we have disabled aggregation.

Is there a way to maintain consistency of aggregated css/js files across multiple servers behind a reverse proxy?

Problem/Motivation

Discovered in #3161889-221: [META] Symfony 6 compatibility, run-tests.sh calls \Drupal::service('app.root'), which is deprecated in favour of a container parameter.

Steps to reproduce

Proposed resolution

Use \Drupal::root() instead.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hi, I am very new to php coding so please don't shout at me if I missed anything.

I worked to RTLize the Admin_Toolbar css file, which is named "admin.toolbar.css". I created an extra RTLized file named "admin.toolbar-rtl.css". The file is RTLized properly (verified by the Front-end developer).

After I created the file and flushed all caches (FACed), nothing happened, even though in the first time I RTLized the original file the change worked 100%.

Thus, it seems to me that the locale_css_alter function doesn't work in Drupal 8, and the program maybe ignoring the -rtl in the RTLized file.

Problem/Motivation

Symfony 5.1 added an InputBag class to store user input. In Drupal core we have a number of places - mostly tests, but not all - where we directly refer to ParameterBag, and at first glance these seem to often be used to store or mock user supplied input.

Proposed resolution

Replace relevant instances of ParameterBag with InputBag for Symfony 5.

Remaining tasks

• Identify which instances need to be replaced
• Determine if we can do this in Drupal 9 with a BC layer or can wait for Symfony 5/6 in Drupal 10

User interface changes

API changes

Data model changes

Release notes snippet

The function returns array not string.

/**
 * Returns the hash of the per-user rendered toolbar subtrees.
 *
 * @return string
 *   The hash of the admin_menu subtrees.
 */
function _toolbar_get_subtrees_hash() {
  [$subtrees, $cacheability] = toolbar_get_rendered_subtrees();
  $hash = Crypt::hashBase64(serialize($subtrees));
  return [$hash, $cacheability];
}

Problem/Motivation

For the release of Drupal 10 the minimum required version will be ??? and the json1 extension will also be required. The minimum supported version for SQLite in Drupal 10 will be determined in #3190641: [policy] Require SQLite 3.26 for Drupal 10 (same as Drupal 9) with the json1 extension required (new requirement for Drupal 10).

Proposed resolution

Update the requirements test for the SQLite database driver.

Remaining tasks

TBD

User interface changes

API changes

None

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

Even if no link text is given for internal links, the link display should still be useful. At the moment it just renders /node/123 even if a node has a node title or an alias, and the editors need to copy the link text from the auto complete above ...

Proposed resolution

Add a link field to a node (related links)
Make link text optional
Add an internal like with link text
Add an internal like without link text
Add an external link without link text

Please note: the screenshot is taken form the Sector distribution. So there has been some additional configuration but the issue remains.

Proposed resolution

(Description of the proposed solution, the rationale behind it, and workarounds for people who cannot use the patch.)
In a perfect world the link would be displayed as
1 - node or entity title (if exists ... in almost all cases nodes will have titles
2 - Site domain + node alias (if exists ... even if it is a relative link, the full URL makes it easier to understand for the user)
3 - Site domain + node path (see above)

Remaining tasks

Review and decide on next steps.

Meeting will happen in #d10readiness on drupal.slack.com.

Hello and welcome to this Drupal 10 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 10 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3257144`
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

:zero: Who is here today? Comment in the thread below to introduce yourself.

:one: Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.

:two: TBD

Problem/Motivation

When accessing Layout Builder overrides via REST (i.e. when accessing an overridden entity's layout field), the contents of sections are empty.

Proposed resolution

Add a normalizer for the layout_section DataType, which ensures that sections can be properly serialized and unserialized via the serialization API (and REST).

Remaining tasks

N/A

User interface changes

N/A

API changes

A new normalizer will be added for the layout_section DataType.
Layout section data will be exposed for all serialization types.

Data model changes

N/A

Problem/Motivation

When #3124762: Add 'lifecycle' key to .info.yml files is committed, we will have three new non-stable theme states. At present there is a visual affordance to experimental themes at admin/appearance. But nothing at present for obsolete and deprecated.

Proposed resolution

Promote the non-stable statuses in admin/appearance page, optionally even visually

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Updated: Comment #0

Problem/Motivation

Currently a bunch of comment module issues hangs in queue blocked by
#2081585: Introduce HistoryRepository service
#148849: Refactor {comment_entity_statistics} into performant Field
#2101183: Move {comment_entity_statistics} to proper service
a comment module clean-up issue #1847540-14: [META] Clean up comment module tests and decouple from node

Also part of history and comment modules already converted to use JS for counting.
But here a details: the current User account is not properly injected into comment form and comment field formatter.
Views plugins are affected too
Also there's some custom code in node and forum modules that chaotically uses field code.

Controller mostly uses \Drupal::currentUser()

Proposed resolution

#1903138: Move global comment permissions to comment-type level and finally #1901110: Improve the UX for comment bundle pages and comment field settings
Decide with history service #2081585: Introduce HistoryRepository service and storage #1029708: History table for any entity and #2031883: Markup for: comment.html.twig

Remaining tasks

Properly split comment code into sets of "storage-affected" , "view-builder", field, "pre-render" code

User interface changes

tbd

API changes

tbd

Problem/Motivation

Split from #2069073: Allow Tours to be taken by users that cannot access the Toolbar (e.g. anonymous users).

Right now it's impossible to trigger a tour without the toolbar. This is because the toolbar tour button HTML ID is hardcoded in core/modules/tour/js/tour.es6.js:

new Drupal.tour.views.ToggleTourView({
  el: $(context).find('#toolbar-tab-tour'),
  model,
});

Proposed resolution

Use a class to trigger the tour, so that other elements are able to do it.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

In earlier releases, it was only possible to start the tour from the toolbar button. Now it's possible to trigger the tour from any HTML element having the js-tour-start-button class. The toolbar tour button #toolbar-tab-tour selector is no more available. Use the .js-tour-start-button class as selector instead.

Problem/Motivation

When a deprecated module or theme is enabled, we could trigger a deprecation notice. This would help to notify contrib modules depending on a deprecated module, and also ensure that core test coverage is cleaned up when something is deprecated - we often have to remove modules from tests before removing the module.

Per #3124762: Add 'lifecycle' key to .info.yml files there's an exception when you try to install an obsolete module, so that's already covered.

Steps to reproduce

Proposed resolution

Deprecation message, "The module 'foo' is deprecated." or "The theme 'foo' is deprecated."

Remaining tasks

Review

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We don't have a formal way to deprecate modules in core. In #3062281: Deprecate block_place module for removal in Drupal 9, we deprecated the Place Block module by deprecating basically everything inside it, including the .module file itself. The module had already been hidden in a previous minor release. It was a bit tedious and ad-hoc, and took a long time to implement even though we were deprecating a module that had been already hidden for many releases.

This issue is not for defining the conditions under which a module will be deprecated; that's a separate product management discussion. Rather, it's for discussing how to deprecate a module once the decision has been made to do so.

Proposed resolution

Define a policy for how modules are deprecated, and provide a clean API to do so. This could be as simple as a deprecated: true in the module's info.yml, or maybe deprecated: "Deprecation message". (Compare #3064017: Create a means to mark an asset library as deprecated in a *.libraries.yml file).

There are two possible scenarios:

1. The module is being moved to contrib for future major versions
2. The module has no replacement because its functionality has been moved into other modules or APIs (Example: #3111645: Uninstall entity_reference module and prevent it being enabled again, remove deprecated code)

What happens as a result will depend on which of these scenarios are the case.

• If the module is not installed on a site, it should be hidden from the UI, same as hidden: true.
• There should be a requirements warning for both install and runtime.
• If the module is not being moved to contrib, its APIs should be deprecated.
• If a contrib replacement is being created, the Composer façade should somehow be able to resolve the core module versus the contrib module (whether based on version, project sub-namespacing, or some other mechanism) and the messaging should explain the correct actions to take.
• Modules that have the deprecated module as a dependency should also receive a warning.
• Composer projects that declare a dependency on the module should also receive a deprecation warning and recommend the replacement.
• Automated tooling like Upgrade Status should detect and warn the user about the deprecated module.

Completed child issues

1. #3124762: Add 'lifecycle' key to .info.yml files

Remaining tasks

1. #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib
2. DONE: #3215043: Indicate the non-stable statuses in admin/modules page
3. #3215044: Promote the non-stable statuses in admin/appearance page, optionally even visually
4. #3250585: Highlight deprecated modules and themes at admin/reports/status page, providing warning and link with explanation
5. #3257127: Trigger a deprecation message when a deprecated module or theme is enabled
6. DONE: #3223453: Check for uses of deprecated and obsolete projects based on the lifecycle info file key
7. Can rector or Project Update Bot do anything with this, e.g. replace a dependency on a deprecated extension with its replacement or contrib equivalent?

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

Vertical tabs have the following accessibility issues:

1. Drupal.verticalTab doesn't take care of the right aria attributes. Whatever happens, every details summary element (of a single VerticalTabs) are described with aria-expanded="false" and aria-pressed="false".
2. Drupal.verticalTab marks active vertical tab menu items with an element that text is active tab. The element has a non-unique CSS id #active-vertical-tab. Sadly, this will be very wrong on the filter format and editor configuration form where multiple vertical tabs may appear (e.g. /admin/config/content/formats/manage/basic_html).

   Fearing the duplicated id, if the user changes the active tab, this marker will be removed from every other vertical tab's of the page as well

3. Auto-focus bug: When a vertical tab is activated (triggered to be shown) by pressing Enter on the tab menu link Drupal.verticalTab tries to focus the first visible :input element in a vertical tab content. But the implementation is wrong: on the Filter format and editor form (/admin/config/content/formats/manage/basic_html), if the user presses the Enter key on the last vertical tabs element's menu link (Filter settings), the focused element will be the first vertical tabs (CKEditor plugin settings) visible input, and not the expected one. This is because the focus trigger happens globally; it isn't limited to the current vertical tabs.
4. The label of a vertical tabs element has invalid for attribute value.

   From #3023310-85: Vertical Tabs style update.2:

   (...) the for attribute is looking for an ID that is not present on the page. The value it is looking for does appear in a div's data-drupal-selector attribute, an element that can't receive focus.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

@todo

Problem

1. Drupal has adopted Views’ dropbutton in several common places in core. Since its introduction in #1608878: Add CTools dropbutton to core, we've spent lots of time refactoring the existing button: #1799498: Improve dropbutton and others [which?]. This component is now even being used for primary form actions on the new node edit form: #1751606: Move published status checkbox next to "Save". However, the implementation there has made the dropbutton harder to theme by pushing it beyond its initial design. (Specifically, allowing its to consist of buttons instead of links, and by introducing sub-elements using #prefix and #suffix).
2. From a UX standpoint, the existing dropbutton’s behaviour is sub-optimal. Since the sub-items are contained within the button, when the button is opened it often must grow in width to accommodate the width of the sub-items. This change moves the click target out from under the user’s cursor, forcing them to hit a slightly different spot in order to close the menu again. In some cases, such as the one reported in #3168326: Dropbuttons in table cells are potentially unusable if it includes options with long text length., opening the dropbutton can result in a reposition that takes the pointer off the dropbotton, which results in it being closed moments after it was opened. The standard implementation of this design pattern does not suffer from this issue: Twitter Bootstrap, Zurb Foundation, jQuery UI. Drupal is the odd one out here.
3. The open/closed state of the menu isn't conveyed to assistive technology, it is only apparent visually.
4. The current focus style for the more-actions button is weak, and won't pass WCAG 1.4.11 Non-text contrast.

Proposed Resolution

Since we cannot change the current Dropbutton (and Operations) implementation for BC reasons, the way to move on is:

1. Create a new Splitbutton element with the required markup, functionality and (accessibility) features.

   • The new Splitbutton element must allow having buttons as well as links, and it should be able to replace the hard-coded fake Dropbutton in Views UI.
   • It should be easy to add modifier CSS classes (described in #2160481: Componentize the dropbutton CSS).
   • Use aria-haspopup and aria-expanded to define the list and toggle to assistive tech.
   • Should have the proper focus styles, to satisfy WCAG success criteria 1.4.11 Non-text contrast. Using an outline (i.e. shape) change is recommended, rather than changing colour alone.
2. In a followup: Replace core's Dropbutton and Operations usage with the new Splitbutton element.
3. In a followup: Deprecate Dropbutton.

User interface changes

Splitbutton is a slightly different experience than dropbutton. Dropbutton has a primary item that is always visible. Although it's a primary item, it's sematically part of the the list that is fully visible when the dropbutton is open.
Seven Dropbutton
The primary item being part of the larger list is more evident in Seven, as primary and list items are styled the same way.

Claro Dropbutton
Claro is styled so the primary and list items look different although they are part of the same list. This visually resembles what splitbutton will be doing semantically.

Seven Splitbutton
Uses the styles defined here: https://groups.drupal.org/node/283223#Split_Buttons_and_Dropbuttons

Claro Splitbutton
Uses Claro's existing component styles, applied to this new element.

API changes

TBD.

Original Proposed Resolution

• Refactor the implementation in core to allow for buttons as well as links in the element while maintaining theme-ability. This is a good opportunity to implement the splitbutton design. — #2278479: Change the dropbutton theme function to ensure consistent output and accommodate the splitbutton design
• Refactor the markup, CSS and JS to be as simple as possible — #2278473: Simplify Dropbutton markup in line with our CSS standards
• Componentize the primary and regular dropbuttons — #2160481: Componentize the dropbutton CSS
• Convey the behaviour and state to assistive technology, in line with the Menu Button pattern from the WAI-ARIA Authoring Practices.
• Follow the keyboard-control behaviour from the Menu Button pattern in the WAI-ARIA Authoring Practices.
• Improve the focus styles, to satisfy WCAG success criteria 1.4.11 Non-text contrast. Using an outline (i.e. shape) change is recommended, rather than changing colour alone.

Child of #3217923: [Plan] Organize and refactor CSS color variables for Olivero

Rename blue name-spaced variables to primary, and rename numbers to correspond with luminosity.

Once the colors are converted to HSL in #3217924: Olivero: Convert all colors (blues and grays) to HSL and normalize hues and saturations. , we need to do the following:

1. Rename the blue variable to primary
2. Change the number value appended to the variable to roughly correspond with the luminosity.

For example, --color--blue-20 will correspond to hsl(202, 79%, 38%). This means that its updated variable name can be something like --color--primary-40.