Problem/Motivation

Media Library field widget unintentionally removes items when adding or removing items. Likely, the remove_button (of '#type' => 'submit') submit callback (::removeItem) is always executed with the regular submit.

Steps to reproduce

Additional references are removed when removing a single item:

1. Have a reference field for media entities, using the Media Library widget
2. Have a node with at least two referenced media entities
3. Remove item #2 (delta = 1)
4. Submit form

Expected result:
The node has only one referenced media item (delta = 0). We're directed to the media collection/canonical page.

Actual result:
The node has zero referenced media items and we're still on the edit form, the node was not saved. Items #2 (the one we wanted to remove) and #1 (which we wanted to keep) were removed.

Something similar happens when adding an item:

1. Have a reference field for media entities, using the Media Library widget
2. Have a node with N referenced media entities
3. Add an item
4. Submit form

Expected result:
The node has only one referenced media item (delta = 0). We're directed to the media collection/canonical page.

Actual result:
The node still has N referenced media items, the Nth item is missing and replaced by our addition. We're also still on the edit form, the node was not saved.

Proposed resolution

Prevent the additional call to ::removeItem.

Remaining tasks

Write tests & patch.

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

-

Problem/Motivation

Split off from #2543334: Auto-placeholdering for #lazy_builder with bubbling of contexts and tags to make that one more easily reviewable. Details to follow.

Proposed resolution

Details to follow.

Remaining tasks

Details to follow.

User interface changes

None.

API changes

None.

Data model changes

None.

Why this should be an RC target

From #10:

Without this, max-age=0 blocks will not be placeholdered automatically, which means that any page with uncacheable blocks will not be able to use Dynamic Page Cache.

This would therefore IMO be a great RC target.

Problem/Motivation

After multiple failed login attempts (default set to 5 tries), a user can no longer login until a certain amount is time passed (default set to 6 hours), and instead sees the message "There have been more than 5 failed login attempts for this account. It is temporarily blocked. Try again later or request a new password.". When a user uses the one-time login link to log in, then changes his/her password and logs out, the temporary block is still in place, the user cannot still cannot log in until the window has passed.

There is no way (other than removing the flood records from the database, or through contrib solutions #67) to remove the temporary ban (implemented through the Flood API) from the account.

This issue is about lifting the ban after a successful login through the reset password functionality. There is a separate issue to lift the ban after an account's password is changed (#2881572: User login flood lock doesn't clear when reset password as admin).

D7 issue: #2880910: [D7] Nothing clears the "5 failed login attempts" security message when a user resets their own password

Proposed resolution

When a user logs in using the one-time login link, the temporary ban on the account should be lifted. The IP-based ban, if present, should remain in place (#35).

Remaining tasks

Patch review.

User interface changes

None.

API changes

None.

Data model changes

None.

Original report by jazzdrive3

I have a user who forgot his password, and he started getting the "5 failed attempts" message. So I go in and reset the password manually as an admin.

But the new password will not work, and he continues to get the "5 failed attempts" message. The only thing we could do was delete his user, then recreate it.

Once their password has been changed in the interface by an admin, it should clear the security block, correct? Or is there a manual way to clear the security block? Because the user still says "active".

Problem/Motivation

We would like to get programatically an entity object of block added in Layout Builder, but since `getEntity` method (/core/modules/layout_builder/src/Plugin/Block/InlineBlock.php:233) is protected, we can only get already rendered object, which doesn't fully cover our needs.

It would be great to make `getEntity` method public, so other developers could easily get added block objects if necessary.

Proposed resolution

Change `getEntity` method visibility from protected to public in `ExtraFieldBlock.php`, `FieldBlock.php` and `InlineBlock.php` files.

Problem/Motivation

Split from #3118143: [meta] Release Drupal 10 in 2022.

We released Drupal 8 without the migration path from Drupal 7 being finished, this was in November 2015.

The Drupal 7 migration path should be stable by the time Drupal 9.0.0 releases, this will be just under five years since Drupal 8 was released.

However, there are still more than 700,000 Drupal 7 sites, and Drupal 7 EOL is due on Novermber 28, 2022.

This means we're likely to see an acceleration of Drupal 7-9 migrations in the next 18 months, more bugs uncovered, and migrations added for contrib modules that previously didn't have them (in contrib rather than core except possibly some remaining cases where core replaced a contributed module and there's something to migrate).

Drupal 9 EOL will be 2023.

Drupal 10 will be released in 2022.

On the other hand, Drupal 7 vendor extended support will be provided until at least end of 2024 (well after Drupal 9 EOL and two and a half years into Drupal 10).

Proposed resolution

1. Continue to support Drupal 7 migrations to Drupal 10 in core.

Remaining tasks

None.

User interface changes

API changes

Data model changes

Release notes snippet

Hello all, it’s time for the weekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ 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. See the parent issue for an idea of the typical agenda.
➤*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.

Core migration issues

• RTBC
• NR
• all open
• Statistics, Google spreadsheet

Next video meeting

2021-07-15 - The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

Recording of the video meeting: https://youtu.be/7IjRQkzEBD4

Problem/Motivation

migrate_drupal_ui migration credentials are stored in as a key_value pair in the database. However, uninstalling the migrate_drupal_ui module does not delete these key_value pairs from the database. This can cause issues when a user may not want to use the migrate_drupal_ui and instead would prefer to run migrations via command line as the command line migrations are still using the previous credentials.

Steps to reproduce

1. install and set up migrate_drupal_ui
2. verify the contents of the `migrate_drupal_7` row in the key_value table
3. uninstall migrate_drupal_ui
4. verify the contents of the `migrate_drupal_7` row in the key_value table
5. in settings.php, set up migration credentials with different values (different host or user for example)
6. attempt to run migration via command line, migration will attempt to use credentials from `migrate_drupal_7` row in the key_value table, rather than settings.php

Proposed resolution

When migrate_drupal_ui is uninstalled, key_value pairs should be removed

Problem/Motivation

Sometimes it is necessary to deprecate theme suggestions. For example, #2831144: Bundle / field name / view mode theme suggestions can conflict needs to remove some of the pre-existing theme suggestions.

Proposed resolution

Allow marking theme suggestions as deprecated.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

From @andrewmacpherson's original extensive issue summary which can be seen here

We're in deeply experimental territory here - there isn't a well-established, reliable pattern we can just copy to make the current layout builder accessible. Essentially, we're making stuff up in a hurry, for a novel UI, with limited opportunity for design validation. There's no guarantee that users are going to understand it, or find it easy to use.

Proposed resolution

Provide a "Layout Overview"(better wording?) link at the top of the Layout Builder
This link would open up an overview in the off-canvas dialog that would allow the user to perform all the operations they can in the current live preview version.

All of the actions currently in the Layout Builder are performed in the off-canvas dialog either through selecting items in a list(adding blocks and sections) or interacting with a form. The only exception to this is dragging and dropping blocks but #2995689: Allow reordering blocks without a pointer device would provide a way to do this via a form.

The overview in the off-canvas would allow all users to share most of the UI's for taking actions on the Layout but provide a more standard way to access those actions than the current live preview.

After each action the users take via the overview they be would shown the overview again at the end of the action. This would allow a user to take multiple actions via the overview without having to open the overview for each action.

Remaining tasks

User interface changes

A new layout overview in the off-canvas dialog

API changes

None

Data model changes

None

Release notes snippet

@todo

Under the current node revisions overview logic, it is possible for a page of the revisions listing to show no revisions. This is confusing.

The NodeController->revisionsOverview() method reads in all revisions of the current node, and then filters them down according to whether the revision in question has a translation for the currently active language, and whether that revision translation is 'affected'. This was done in #2465907: Node revision UI reverts multiple languages when only one language should be reverted to address the issue of the revision UI reverting multiple translations when it shouldn't be.

Because the paging of the revisions query doesn't account for language and 'affected' state, it is possible for the revisions query to return a set of revisions for a node of which none of the revisions belong to the language being tested, nor are any of them marked as 'affected'. This filters the list down to zero, which results in an empty table of revisions for that page, which is confusing.

It's possible for this situation to arise on a site with many active languages. Given a site with 55 languages, if a node goes through translation, and there is a new revision for each language that is translated, it would be very possible for a given page of revisions to contain no revisions eligible for display.

The logic which filters down the returned page of revisions to the current language and 'affected' should be able to be pushed into the revision query itself (NodeController->getRevisionIds()). Since this is a protected method not called anywhere else, it should be safe to add these conditions to the query, to allow the pager to function properly.

PHP 7.4 ships with opcache preloading - https://wiki.php.net/rfc/preload - which allows a framework to specify a preload file which will:

...load a certain set of PHP files into memory - and make their contents “permanently available” to all subsequent requests that will be served by that server.

All the functions and classes defined in these files will be available to requests out of the box, exactly like internal entities (e.g. strlen() or Exception). In this way, we may preload entire or partial frameworks, and even the entire application class library. It will also allow for introducing “built-in” functions that will be written in PHP (similar to HHVM's sytemlib).

Notably, this comes with some drawbacks that may not make preloading advisable/possible in certain environments (e.g. shared servers) but is well suited for more "modern" runtime environments such as containers, which generally map to 1 "server" (container) per codebase.

The traded-in flexibility would include the inability to update these files once the server has been started (updating these files on the filesystem will not do anything; A server restart will be required to apply the changes); And also, this approach will not be compatible with servers that host multiple applications, or multiple versions of applications - that would have different implementations for certain classes with the same name - if such classes are preloaded from the codebase of one app, it will conflict with loading the different class implementation from the other app(s).

Akin to Symfony 4.4's compatibility: https://symfony.com/blog/new-in-symfony-4-4-preloading-symfony-applicati...

The proposal would therefore be to ship a preload file which may be optionally included in the site's php ini configuration set; this would be a default-OFF (since it requires manual intervention in the hosting environment) and opt-in ON situation.

As Drupal has much of its core imported from Symfony and already boasts an extensions API, I would imagine extending Symfony's model would be a starting point.

Hi all,
i want to upgrade my project's drupl version to 9. So i followed
https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-to-...
But unfortunately i am stuck in some areas.Could you please help me to upgrade 9??

OS :Windows10
Composer version : 2.0.0
also attaching the json file

after running composer update command, getting the error like

Problem 1
- composer/installers[v1.7.0, ..., v1.8.0] require composer-plugin-api ^1.0 -> found composer-plugin-api[2.0.0] but it does not match the constraint.
- Root composer.json requires drush/drush 10.0.0 -> satisfiable by drush/drush[10.0.0].
- drupal/core-recommended[9.2.0-beta1, ..., 9.2.0-beta2] require symfony/var-dumper v5.2.8 -> satisfiable by symfony/var-dumper[v5.2.8].
- Conclusion: don't install symfony/var-dumper v5.2.8 (conflict analysis result)
- drupal/core-recommended 9.2.0-beta3 requires symfony/var-dumper v5.3.0-RC1 -> satisfiable by symfony/var-dumper[v5.3.0-RC1].
- Conclusion: don't install symfony/var-dumper v5.3.0-RC1 (conflict analysis result)
- drupal/core-recommended[9.0.0-beta3, ..., 9.0.0-rc1] require symfony/var-dumper v5.0.8 -> satisfiable by symfony/var-dumper[v5.0.8].
- Conclusion: don't install symfony/var-dumper v5.0.8 (conflict analysis result)
- drupal/core-recommended[9.0.0, ..., 9.0.12] require symfony/var-dumper v5.1.0 -> satisfiable by symfony/var-dumper[v5.1.0].
- Conclusion: don't install symfony/var-dumper v5.1.0 (conflict analysis result)
- drupal/core-recommended[9.1.0-beta1, ..., 9.1.7] require symfony/var-dumper v5.1.8 -> satisfiable by symfony/var-dumper[v5.1.8].
- Conclusion: don't install symfony/var-dumper v5.1.8 (conflict analysis result)
- drupal/core-recommended[9.0.13, ..., 9.1.x-dev] require symfony/var-dumper v5.1.11 -> satisfiable by symfony/var-dumper[v5.1.11].
- Conclusion: don't install symfony/var-dumper v5.1.11 (conflict analysis result)
- drupal/core-recommended[9.2.0-rc1, ..., 9.3.x-dev] require symfony/var-dumper v5.3.0 -> satisfiable by symfony/var-dumper[v5.3.0].
- Conclusion: don't install symfony/var-dumper v5.3.0 (conflict analysis result)
- drupal/core-recommended 9.0.0-alpha1 requires composer/installers v1.7.0 -> satisfiable by composer/installers[v1.7.0].
- drupal/core-recommended[9.0.0-alpha2, ..., 9.0.0-beta2] require composer/installers v1.8.0 -> satisfiable by composer/installers[v1.8.0].
- drupal/core-recommended 9.2.0-alpha1 requires symfony/var-dumper v5.2.6 -> satisfiable by symfony/var-dumper[v5.2.6].
- Conclusion: don't install symfony/var-dumper v5.2.6 (conflict analysis result)
- drush/drush 10.0.0 requires symfony/var-dumper ^3.4 || ^4.0 -> satisfiable by symfony/var-dumper[v3.4.0-BETA1, ..., 3.4.x-dev, v4.0.0-BETA1, ..., 4.4.x-dev].
- You can only install one version of a package, so only one of these can be installed: symfony/var-dumper[v2.7.0-BETA1, ..., 2.8.x-dev, v3.0.0-BETA1, ..., 3.4.x-dev, v4.0.0-BETA1, ..., 4.4.x-dev, v5.0.0-BETA1, ..., 5.4.x-dev, 6.0.x-dev].
- drupal/core-recommended 9.1.0-alpha1 requires symfony/var-dumper v5.1.7 -> satisfiable by symfony/var-dumper[v5.1.7].
- Root composer.json requires drupal/core-recommended ^9 -> satisfiable by drupal/core-recommended[9.0.0-alpha1, ..., 9.3.x-dev].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

You are using Composer 2, which some of your plugins seem to be incompatible with. Make sure you update your plugins or report a plugin-issue to ask them to support Composer 2.

so i am running composer require symfony/var-dumper:"^5" symfony/console:"^5" and get another like

./composer.json has been updated
Running composer update symfony/console
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires drupal/core-composer-scaffold ^9, found drupal/core-composer-scaffold[9.0.0-alpha1, ..., 9.3.x-dev] but the package is fixed to 8.9.17 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Problem 2
- Root composer.json requires drupal/core-recommended ^9, found drupal/core-recommended[9.0.0-alpha1, ..., 9.3.x-dev] but the package is fixed to 8.9.17 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Problem 3
- Root composer.json requires drupal/ldap ^4.0.0-beta3, found drupal/ldap[dev-4.x, 4.0.0-beta3, 4.x-dev (alias of dev-4.x)] but the package is fixed to 3.0.0-beta7 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Problem 4
- Root composer.json requires drupal/ldap_servers ^4.0.0-beta3, found drupal/ldap_servers[dev-4.x, 4.0.0-beta3, 4.x-dev (alias of dev-4.x)] but the package is fixed to 3.0.0-beta7 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Problem 5
- Root composer.json requires drupal/permissions_by_term ^3.1.16, found drupal/permissions_by_term[3.1.16] but the package is fixed to 2.34.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Problem 6
- Root composer.json requires drush/drush 10.0.0, found drush/drush[10.0.0] but the package is fixed to 9.7.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Problem 7
- drupal/core 8.9.17 requires symfony/console ~3.4.0 -> found symfony/console[v3.4.0-BETA1, ..., 3.4.x-dev] but it conflicts with your root composer.json require (^5).
- drupal/devel 4.1.1 requires drupal/core ^8.8 || ^9 -> satisfiable by drupal/core[8.9.17].
- drupal/devel is locked to version 4.1.1 and an update of this package was not requested.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

pls lead me if i'm wrong!

Adding the required state to radios, adds the required marker to all available options.

$form['field_options']['#states']['required'] = array(
  ':input[name="field_required[und]"]' => array('value' => 1)
);

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

In the not-so-distant (Drupal 10) future, we want Olivero to be able to support changing design by changing base CSS variables. In order make this process easier, it makes sense to re-architect the CSS variables sooner than later.

1. Convert all of the hex values for blues and grays to HSL values.
2. Normalize the values for the hues and saturations.

This will require designer sign off, as there will be slightly different shades of blue and gray. We'll also want to triple check that the new colors still meet WCAG accessibility contrast guidelines.

Original Gray Hex to HSL conversion

Note that the hues and saturations will be normalized.

--color--gray-0: #0d1214; - Black 1 - hsl(197, 21%, 6%)
--color--gray-10: #313637; - Black 2 - hsl(190, 6%, 20%)
--color--gray-20: #6e7172; - Black 3 - hsl(195, 2%, 44%)
--color--gray-25: #5d7585; - Gray Dark - hsl(204, 18%, 44%)
--color--gray-28: #7d919d; - Gray Dark 2 - hsl(203, 14%, 55%)
--color--gray-30: #7e96a7; - Gray medium - hsl(205, 19%, 57%)
--color--gray-40: #98abb9; - Gray medium 1 - hsl(205, 19%, 66%)
--color--gray-45: #afb8be; - Gray medium 2 - hsl(204, 10%, 72%)
--color--gray-50: #9ea0a1; - Black 4 - hsl(200, 2%, 63%)
--color--gray-70: #d7e1e8; - Gray light - hsl(205, 27%, 88%)
--color--gray-80: #e7edf1; - Gray light 1 - hsl(204, 26%, 93%)
--color--gray-90: #f1f4f7 - hsl(210, 27%, 96%)
--color--gray-95: #f7f9fa; - Gray light 2 - hsl(200, 23%, 97%)

Original Blue Hex to HSL conversion

Note that the hues and saturations will be normalized.

--color--blue-20: #0d77b5; - Blue dark - hsl(202, 87%, 38%)
--color--blue-30: #3d92c4; - Blue dark 2 - hsl(202, 53%, 50%)
--color--blue-50: #2494db; - Blue medium - hsl(203, 72%, 50%)
--color--blue-70: #53b0eb; - Blue bright - hsl(203, 79%, 62%)
--color--blue-90: #ddeffb; - Blue bright 5 - hsl(204, 79%, 93%)

Problem/Motivation

The current Node preview form styles are missing. As a resut it looks broken

Proposed resolution

Keep the same behavior as Seven and give visual clues to explain the action is "going back". On the design system we already have an item for that: the Action link. It's a middle step between a button and a link, adding an icon into a normal link:

You can see the specs here: Drupal Design System Action link.

Luckily we already have the icon we need implemented on the pager:

Remaining tasks

Review changes.

User interface changes

After the patch

Improve horizontal alignment so that elements are aligned on a vertical line.

Currently the alignment is a bit mixed but should be nicely aligned.

Current

Possible alignement fix

See also a related issue #3086710: Primary tabs visually not aligned on left with other element

Problem/Motivation

To reproduce this issue, view the html in #9 in IE11.

In IE11, any element set to display: flex; can receive focus by being clicked. This has been narrowed down to an IE bug, but one that has very little evidence of it existing online because it is only noticeable if stylesheets include rules that provide focus outlines to non-interactive elements. This is the case with Claro's :focus styles, as they are are applied as *:focus, impacting all elements. This can result in the green focus ring appearing in unexpected places.

The bug does not result in making these elements tabbable via tab navigation, but clicking on one of these non-interactive-but-focusable elements will take focus away from another element .

Proposed resolution

Any number of CSS rules could address the problem.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In form-text.css, .form-element width is set to 100% at widths up to 600px. This pushes prefixes and suffixes to a new line in a way that doesn't look good. (Found using Umami profile on Chrome at admin/config/media/image-toolkit)

Proposed resolution

Implement a new design to solve this:

This image is just a reference. Please use this Figma link to check spacing and other definitions.

Remaining tasks

• Create a new design
• Accessibility review
• Create a new patch

User interface changes

A new design for prefix will be available.

Release notes snippet

Problem/Motivation

Several places in Claro use the regular size for input fields and take a lot of vertical space.

Proposed resolution

As we have for buttons, we need smaller and more compact input and selects for smaller forms like the content page filter or the people page filter.

Input full specs: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...
Select full specs: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

Remaining tasks

• Create designs
• Create specs
• Create styles for smaller inputs/selects.
• It should be possible to target a single element by adding a class to that element
• It should also be possible to target all elements within a form by adding a single wrapper class to the form. Although button variants already exist, button CSS will need updating to allow variant-styling based on a parent class such as .form--small
• Implement it on views filters, views bulk actions, and block layout. Block layout won't have any visible differences, but refactor so the form itself is styled as extrasmall instead of each element being targeted with the styling.

User interface changes

Some forms will occupy lest space.

Testing instructions

Small size:
- Filters for the following lists:
/admin/content
/admin/people
Extra Small size:
Block layout
admin/structure/block

Problem/Motivation

Seems like some quite significant changes have been encountered in #3220021: [meta] Ensure compatibility of Drupal 9 with PHP 8.1 (as it evolves).

Steps to reproduce

Try testing D7 core with PHP 8.1

Proposed resolution

Make tests pass.

Remaining tasks

?

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

tbc