Problem/Motivation

When running the drush locale:check command on our Drupal site, we have encountered a recurring issue where existing .po files are deleted and replaced with more general .po files if a specific .po file for a module or core version is not found. For example, we are currently running Drupal core version 10.2.7 and have a drupal-10.2.6-de.po file. When drush locale:check is executed, this file gets deleted and replaced with a drupal-10.x-de.po file.

Steps to reproduce (only until a new 10.2.7 .po file is available)

Steps to Reproduce
Use Drupal core version 10.2.7.
Place a specific .po file (e.g., drupal-10.2.6-de.po) in the translations directory.
Run the command drush locale:check.
Observe that the specific .po file is deleted and replaced by a more general drupal-10.x-de.po file.

Expected Behavior
The drush locale:check command should check for and update translations without deleting existing .po files that are specific to the current Drupal core version or modules.

Actual Behavior
The drush locale:check command deletes existing version-specific .po files if they are not matched and replaces them with more general .po files. This causes a loss of specific translations that were manually added.

Impact
This behavior is problematic as it leads to the loss of detailed and specific translations. It also introduces additional manual steps to ensure translations are correctly reapplied after running drush locale:check.

Possible Workarounds
Manually download and place the necessary .po files after running drush locale:check.
Use scripts to ensure the presence of specific .po files and prevent their deletion.

Suggested Solution
Enhance the drush locale:check functionality to preserve existing .po files and avoid replacing them with general files unless explicitly instructed. Alternatively, implement a more intelligent matching mechanism that respects version-specific files and only updates when a correct replacement is found.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I check my code with this validator: http://validator.w3.org/check
And throwing this error:

Line 57, Column 105: Attribute hreflang not allowed on element li at this point.
<li hreflang="es" data-drupal-link-system-path ...

This code was generated by block Language switcher.

Seem that the code generate by Drupal does not meet standards.

Beta phase evaluation

Problem/Motivation

The URL prefix for language negotiation is not imported correctly from the configuration during site installation with existing config. Instead, it is overridden by the default value.

Steps to reproduce

1. Go to the "Configure Interface Text Language Detection" page.
2. Enable the URL method for language detection.
3. Configure the URL method to have an empty prefix for the default language.
4. Export the configuration.

The exported configuration in language.negotiation.yml should look like this:

url:
  source: path_prefix
  prefixes:
    uk: ''
    en: en

At this point, language negotiation should work correctly.

5. Install the site using Drush with the existing configuration:

drush si --existing-config

6. Go back to the "Configure Interface Text Language Detection" page.
7. Observe the prefix value for the default language in the form.

Expected Result:

The form should display an empty value for the default language prefix as specified in the configuration.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In Views media_library » Widget and Widget (table) displays » Exposed form options, when enabling the Include reset button, clicking the Reset button in the modal when inserting media into a Wysiwyg leads to an Access Denied outside the modal.

Steps to reproduce

It's easy to reproduce this on https://SimplyTest.me using the Umami Demo.

• Add the Reset button to the media _library view
• Create a new Basic page
• Click the Insert Media button
• Filter the medias any way you want, then click the Reset button

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

"Administration pages language" setting is not taken in account after an ajax call (views/ajax): labels and field options return to current interface language (selected by language prefix) right after applying ajax filtering or sorting.

Steps to reproduce

On a vanilla Drupal, activate at least two languages (for example English and Italian, setting Italian as default).
Enable in language "Detection and selection""Account administration pages" and "URL" items, leaving default values and weights.
Set Administration pages language English for current user.
Enable ajax for a view, for example admin/content.
Visit the view page at /admin/content (default interface language don't have prefix): view is correctly rendered in English (admin language selected for the user).
Try to click on Filter submit button or on a table header for sorting.
The view rebuilt by ajax call is now rendered in Italian language (labels, filters, table heading), which is wrong (current interface language).

Proposed resolution

N/A

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

Field label unchanged after add new default language

Steps to reproduce

1. Install Drupal using standard profile and english language.
2. Enable module "Interface translation".
3. Add language Russian.
4. Set default language Russian.
5. Goto page body field editing form /admin/structure/types/manage/page/fields/node.page.body.
6. Change field label and submit form.

After this steps label on /admin/structure/types/manage/page/fields not changed, and equal "Содержимое", also label not change on following pages:
/admin/structure/types/manage/page/form-display
/admin/structure/types/manage/page/display
/node/add/page

Tested on 10.2.6 and 10.0.0

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Hi, I have a problem with fetching translatable images via JSON:API. I use default article node type, there I have a field allowing to upload images, but this field is translatable, so you can upload different image and set different alternative text per language.

I cannot fetch images via JSON:API when I'm using image from the default translation and this translation is unpublished.

Steps to reproduce

1. Add a translatable image field to node article.
2. Add an article in two translations (i.e. English and Italian).
3. Make EN translation the default / original one.
4. For EN translation upload image and don't do it for the IT translation (let Drupal use default one, from EN translation).
5. Unpublish EN translation and publish IT translation.
6. Go to /it/jsonapi/node/article/{uuid}.
7. You should see under meta.omitted that it wasn't possible to get image (error saying Some resources have been omitted because of insufficient authorization). If you publish EN translation, this error should disappear and you should get image normally.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

During installation, an entity's base field definitions can be populated and cached before other modules with additional base field definitions on the same entity can make their changes.

Proposed resolution

In order to avoid this, we need to clear the entity_field.manager's caches and recalculate available base field definitions.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When we add the settings "target_bundles" in TermSelection the getReferenceableEntities return directly the default one.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Tentatively opening as bug report but might also be a support request to get direction for debugging in Markup module.

Problem/Motivation

A markup field does not show on nodes with layout builder enabled. It does show in the Layout Builder form, but not on the node view. The markup module Maintainer spent quite some time on debugging and couldn't find an error in the module.

Steps to reproduce:

- Install https://www.drupal.org/project/backfill_formatter module
- Create some taxonomies
- Create entity reference field to terms on any content type (i.e., Article)
- Try to add that entity reference field as block with layout builder (i.e., On Article content type's default display mode)
- Add "Backfill terms" as formatter
- Create some articles with similar terms (The motto of backfill formatter is it will automatically select content based on terms tagging, in order they set in the field formatter hence the term backfill)
- Visit the articles you created you won't see that block.

Proposed resolution

Let the field appear on node view.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Premise: "Limit allowed HTML tags and correct faulty HTML" setting is unchecked.

For already saved pages, it is not possible to change the link around the image again.

Steps to reproduce

1. Go to /admin/config/content/formats/manage/full_text page, uncheck the "Limit allowed HTML tags and correct faulty HTML" option and save.
2. Create a new article, insert an image in CKEditor, add a link to the image, and save. Source code: <a href="https://www.google.com"><img src="demo.png"></a>
3. Edit the article again, modify the image link, and save the page. The link is not updated.

Proposed resolution

Add logic to update htmlLinkAttributes in core/modules/ckeditor5/js/ckeditor5_plugins/drupalImage/src/drupalimageediting.js.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While working with the Translation Management Tool module on Drupal 10.2, I encountered the following error while reviewing translation:
TypeError: round(): Argument #1 ($num) must be of type int|float, string given in round() (line 114 of core/lib/Drupal/Core/Field/Plugin/Field/FieldType/DecimalItem.php).

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

This issue is about maintaining the profiles patch for those that need it *but* that for many reasons explained by nedjo below and others in the parent issue profiles defining a base parent profile will never be a part of core. Click to find out more about the Recipes, Starter Kits, Distributions strategic initiative,

If you starting a build from scratch today using this patch would not be a good choice because you would be taking on the maintenance and tech debt burden of this issue.

Progress is being made on the strategic initiative, if you wish to accelerate the recipes initiative then please have a look at these issues:

Recipes and starter kids plan and related issues
Recipes

As work moves forward on recipes, this issue will be rendered obsolete.

At the moment, it is impossible to post a new comment or add a new patch to the original issue #1356276: Allow profiles to define a base/parent profile.
The problem was reported in #3265696: 5xx on any update to #1356276 issue.
This issue was created to continue patch maintenance.

For full details see original issue #1356276: Allow profiles to define a base/parent profile.

Problem/Motivation

Deleting a user account while requiring email confirmation creates a one time link that is emailed to the user. The one time login link uses the user last login date as part of it's hash, so if the user logs out the logs back in during the process, the link automatically invalidates.

Steps to reproduce

* Create an account.
* Log in.
* Request to delete the account.
* Log out.
* Log back in.
* Click email link.

Proposed resolution

I can see the value in having `$account->getLastLoginTime()` for password resets, but don't understand why it would form part of the hash for
account deletion requests. I would suggest refactoring the one time password hashing method, so that there's an option to generate a hash without getLastLoginTime() for scenarios such as account deletion.

Remaining tasks

Yes

User interface changes

No

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

Fatal indicating that getEntityTypeId() method cannot be called on NULL block in core/modules/layout_builder/src/Plugin/Block/InlineBlock.php

Steps to reproduce

1. Install lb_plus
2. Turn on individual layouts for a vocabulary
3. Visit layout page for vocabulary
4. See fatal indicating that getEntityTypeId() method cannot be called on NULL block.

Proposed resolution

Add this to build method:

    if (empty($block)) {
      return [];
    }

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Part of #2571965: [meta] Fix PHP coding standards in core.

Approach

We are testing coding standards with PHP CodeSniffer, using the Drupal coding standards from the Coder module. We need to do a couple of steps in order to download and configure them so we can run a coding standards check.

Step 1: Add the coding standard to the whitelist

Every coding standard is identified by a "sniff". For example, an imaginary coding standard that would require all llamas to be placed inside a square bracket fence would be called the "Drupal.AnimalControlStructure.BracketedFence sniff". There are dozens of such coding standards, and to make the work easier we have started by only whitelisting the sniffs that pass. For the moment all coding standards that are not yet fixed are simply skipped during the test.

Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket or remove the line if it's currently excluded. The sniff name is in the issue title. Make sure your patch will include the addition / removal of this line.

Step 2: Install PHP CodeSniffer and the ruleset from the Coder module

$ composer install
$ ./vendor/bin/phpcs --config-set installed_paths ../../drupal/coder/coder_sniffer

Once you have installed the phpcs package, you can list all the sniffs available to you like this:

$ ./vendor/bin/phpcs --standard=Drupal -e

This will give you a big list of sniffs, and the Drupal-based ones should be present.

Step 3: Prepare the phpcs.xml file

To speed up the testing you should make a copy of the file phpcs.xml.dist (in the core/ folder) and save it as phpcs.xml. This is the configuration file for PHP CodeSniffer.

We only want this phpcs.xml file to specify the sniff we're interested in. So we need to remove all the rule items, and add only our own sniff's rule. Rule items look like this:

<rule ref="Drupal.Classes.UnusedUseStatement"/>

Remove all of them, and add only the sniff from this issue title. This will make sure that our tests run quickly, and are not going to contain any output from unrelated sniffs.

Step 4: Run the test

Now you are ready to run the test! From within the drupal root, run the following command to launch the test:

$ composer phpcs -- -ps

This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running. The -s flag shows the sniffs when displaying results.

Step 5: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur. You could fix all of these manually, but thankfully phpcbf can fix many of them. You can call phpcbf like this:

$ composer phpcbf

This will fix the errors in place. You can then make a diff of the changes using git. You can also re-run the test with phpcs and determine if that fixed all of them.

List of sub-sniffs related to Drupal.Commenting.VariableComment

We should create an issue for each, or at least for those with multiple violations. Those issue will have this issue as parent and will mention in the title the fixed sniff.

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
----------------------------------------------------------------------
SOURCE                                                           COUNT
----------------------------------------------------------------------
Drupal.Commenting.VariableComment.Missing                        248
Drupal.Commenting.VariableComment.VarOrder                       113
Drupal.Commenting.VariableComment.MissingVar                     83
----------------------------------------------------------------------
A TOTAL OF 444 SNIFF VIOLATIONS WERE FOUND IN 3 SOURCES
----------------------------------------------------------------------

To get this list add to phpcs.xml:

<rule ref="Drupal.Commenting.VariableComment"/>

and then run from root folder:

composer phpcs -- -ps  --report=source --report-width=120 --report-file=../phpcs-results.txt

Problem/Motivation

When returning a list of entities that are not the same, or a list of nodes with different content-types, if the "include" parameters is used, it checks for the first entity if this field can be included and if not possible, it raises an error with message:

title: "Bad Request",
status: "400",
detail: "`field_brighcove_video` is not a valid relationship field name. Possible values: node_type, uid, field_author, field_content, field_entity, field_main_publication_channel, field_other_publication_channel, field_section, field_series, field_source, field_team, field_teaser, field_topics, field_topic_entity.",

An example of module that uses JSON:API Resources is JSON:API Search API, which makes a lot of sense to return node within different content types.

Steps to reproduce

Trying get multiple type of data in a single JSON API with include parameters having fields that are not common between different entity types you are trying to fetch.

Proposed resolution

My suggestion is to receive the resource identifier as part of include path and check that before include it, something like ?include=node--video.field_brighcove_video.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

No graphics on site

Drupal 10.2.7 - 10.3.0
php8.0-8.3
mysql8.0
nginx 1.18
ubuntu lts 22.0

Problem/Motivation

I want to display content in all translation and show the content type label in English.

When using "Content language of view row", translatable fields are shown in the language of the view row. There is no option to change the language on a field level.

How to reproduce

See https://drupal.stackexchange.com/questions/261523/how-to-create-a-view-t...

Proposed resolution

For instance, add a field views formatter "translation" that has a setting for language selection

Problem/Motivation

Layout Builder throws errors when the system Breadcrumbs block is in a layout and any blocks are moved. Further, after moving the Breadcrumbs block, the "Move" contextual link stops working.

The error looks something like this:

InvalidArgumentException: Invalid UUID "first" in Drupal\layout_builder\Section->getComponent() (line 177 of /var/www/web/core/modules/layout_builder/src/Section.php).

Steps to reproduce

Simple

1. Do a Standard Install
2. Enable Layout Builder
3. Configure Basic Page content type to use Layout Builder
4. Add a Breadcrumbs block to the Basic Page layout
5. Move any block via drag-and-drop in the Basic Page layout through the Layout Builder UI
6. Go to the Recent Log Messages and see something about an invalid UUID

More Interesting

1. Do a Standard Install
2. Enable Layout Builder
3. Configure Basic Page content type to use Layout Builder
4. Add a Breadcrumbs block to the Basic Page layout
5. Move any block to a different section via drag-and-drop in the Basic Page layout through the Layout Builder UI
6. Click the "Move" contextual link for the any block. Instead of the offscreen dialog flying in, the throbber will just give up.
7. Right-click the "Move" contextual link for any block and open the link in a new tab. WSOD.

Proposed resolution

The error results for the Breadcrumbs getting built and rebuilt as part of the layout builder preview. It tries to build breadcrumbs for the layout_builder.move_block_form route and the title callback is called with bad arguments.

Current Proposal

We can add a LayoutBuilderBreadcrumbBuilder class and a layout_builder.breadcrumb to build breadcrumbs on routes related to moving blocks. See #20.

Older proposals

Old Proposal 1
Add some defensive coding into \Drupal\layout_builder\Form\MoveBlockForm::title to confirm that the uuid argument looks like a uuid before using it in a getComponent() call. Return some sort of placeholder text as the title instead.

Old Proposal 2
SystemBreadcrumbBlock::build could vary depending on context. This would depend on #3027653: Allow block and layout plugins to determine if they are being previewed getting fixed first.

Old Proposal 3
SystemBreadcrumbBlock::build do a special case when the route name is layout_builder.move_block

Other proposals?

Remaining tasks

Write tests (this is started in #14 but can probably be improved)
Add a fix

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Original Report

When using the drag and drop interface for Layout Builder, dragging a custom block generates the following error:

InvalidArgumentException: Invalid UUID "first" in Drupal\layout_builder\Section->getComponent() (line 177 of /var/www/web/core/modules/layout_builder/src/Section.php).

Where "first" is the label of the region inside the section. This is thrown on any move, whether between sections or not. There is no further backtrace listed, but I was able to track it back to MoveBlockForm::title. This error does not get thrown if I open the Move Block Form from the contextual menu.

The only module we have installed I know of that does anything with this form is layout_builder_restrictions, but I am not seeing anything in that code that would do this.

Just being an old code rat, I am not conversant enough with the JS Drag and Drop interface to be able to troubleshoot this further without some help, and I haven't seen this in any other issue queues.