🇳🇿New Zealand @quietone

This was applied to 10.3.x, 10.4.x, 10.5.x, 11.1.x, and 11.x. It was applied to 11.0.x, which is no longer supported, but then reverted.
Therefore restoring the fixed status.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Thanks for the work on fixing this Critical bug.

About this time last year this was set to 11.0.x for backport to 11.0.x and 10.3.x. Since both of those versions are no longer supported this will not be backported to those versions. And the last report of this causing a problem was in Jan of this year so hopefully that has been resolved over the year. It is time to close this as fixed.

I updated credit.

@randy tang, did you see my comment in #7 and #12 about the version?

Everyone, the version for this issue is 11.x, our main development branch. Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Please leave the version at 11.x.

Hi, if this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

There is very little information here. If you are still experience this problem, are you able to provide complete steps to reproduce the issue → starting from "Install Drupal core"?

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

For Drupal core, it is preferred that contributors add a comment that they are working on an issue instead of assigning it to themselves. See Assigning ownership of a Drupal core issue → .

Has this been resolved?

There is very little information here. The configuration of the view given in the issue summary has lost all the formatting so it can't be imported, so I am not able to test anything here. I am not aware of other reports of problems with the responsiveness of Olivero. Maybe this is a support request like the duplicate?

If this is a support request, then I'll add that the Drupal Core issue queue is not the ideal place for support requests. The 'support request' option is there for filing support issues for contributed modules and themes. There are several support options listed on our Support page → , including the Drupal Forums → and Drupal Answers. There is also Drupal Slack → . You may get better replies in one of those places.

It looks like it is this issue, https://github.com/ckeditor/ckeditor5/issues/10118

I am inclined to agree that this should be moved. The composer output can still be added.

This is filed on drupal 10.0 which hasn't been supported ended since Dec 2023. And I am not aware of an event listing in drupal core although there is one in Drupal CMS. I am moving this to that project.

Support for 10.0 ended in Dec 2023.

I tested this today on simplytestme, 11.2.x-dev. I wasn't able to reproduce the problem using the steps in the issue summary. However, using the steps in the related issue, I was able to reproduce the problem. The difference is that that issue specifies the precision and scale whereas this issue does not. But having played with both I think this really is a duplicate of that issue.

Therefore closing this as a duplicate.

I tested this with simplytestme using 11.2.x-dev. I followed the steps in the issue summary and was not able to reproduce the problem. Are there other steps needed to reproduce the problem?

Changing version because in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

This also needs to be converted to a merge request.

🐛 Drupal\Core\Render\Component\Exception\InvalidComponentException: [slots.messages] Array value found, but an object is required in Drupal\Core\Theme\Component\ComponentValidator->validateDefinition() Active

@mrogers, thanks for the link.

I am closing this as a duplicate of that issue.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Updated the API link to 11.x and changed to the standard template.

Support ended for Drupal 10.3 in June of this year. I am changing the version to 11.x.

Support for Drupal 10.2 ended in Dec 2024.

Does this happen on a currently supported version of Drupal? I am tentatively setting this to 11.x so that more people see this issue.

Just dropping to ask if you have read the drupal 11.1.9 release notes → ?

Another issue committed

The timezone plugin implements a very specific case and hard codes 2 of the 3 the input parameters to timezone_name_from_abbr. The process plugins in the migrate module are more generic and flexible. For that reason I think it should not stay in core.

@benjifisher, thanks for reviewing all the process plugins!

I have restored link_uri in the MR since it was used in a custom migration. I agree that user_langcode is one to keep. The others are possible too but let's hear from others before changing the MR. So far, there has been no response in the Slack thread.

I don't think it matters but I have asked the other release managers about deprecating the migrate_drupal process plugins:

Right now I don't think the kept process plugins should move to the migrate module. But let's explore that in a meeting or a separate issue.

why some items are struck through?

They were ones that I subsequently resolved.

However, I have updated the 'problem' section of the issue summary and removed the strike throughs.

Working on reviewing this in detail with support from @nod_.

Follow up created, 📌 Add 'Core JavaScript packages' core committers Active

quietone → created an issue.

Linting checks are passing so back to review.

Thanks for identifying the category for each change! Now, to review those, it will actually be better in separate MR's per the remaining tasks in the issue summary. xjm set that up according to the Issue Scope Guidelines → , which are to improve things like the quality of the review. It will also separate the category 3 changes which will require input from the accessibility team. Waiting on those discussion should not delay the other categories.

Therefor, setting to needs work for step 3, 4, and 5.

Move beta 1 to this week

quietone → made their first commit to this issue’s fork.

Correct name of Field Layout in the Field Layout section.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

So, I see my grep was limited to *Test.php, I have updated the issue summary with an improved search.

There are out of scope changes in core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5Test.php and
core/modules/ckeditor5/tests/src/FunctionalJavascript/ImageTestBaselineTrait.php that need to be removed.

After applying the diff and searching these are the remaining instances that need to be checked.

1. core/modules/config/tests/config_test/src/ConfigTestForm.php
2. core/modules/filter/tests/filter_test/src/Plugin/Filter/FilterTestPlaceholders.php
3. core/modules/search/tests/modules/search_extra_type/src/Plugin/Search/SearchExtraTypeSearch.php
4. core/modules/system/tests/modules/entity_test/src/Hook/EntityTestHooks.php
5. core/modules/system/tests/modules/menu_test/src/TestControllers.php
6. core/modules/system/tests/modules/session_test/src/Form/SessionTestForm.php
7. core/modules/system/tests/modules/update_test_schema/src/Hook/UpdateTestSchemaRequirements.php
8. core/modules/system/tests/modules/update_test_schema/update_test_schema.install
9. core/tests/Drupal/KernelTests/AssertContentTrait.php
10. core/tests/Drupal/Tests/Core/Logger/LogMessageParserTest.php
11. core/tests/Drupal/Tests/WebAssert.php

#14 is OK with me.

Having said that I would like to have a definition of when to use 'docs'. Right now they are task but it could be helpful to distinguish those in the commit type.

Updates because Field Layout and Migrate Drupal UI have been deprecated.

Reworded the change record and published.

Migrate Drupal is used in tests in the migrate module. There are also usages in comments in the migrate module.

Committed 8127fb7 and pushed to 11.x and cherry-picked to 11.3.x.

Thanks!

I just used this new format and was stuck at figuring what the type should be. There is no information about the types at all. I eventually found this issue, the list of choices, and a link to the the list of commit types.

I also learned that I could add any string to the field. Should the even be possible since there is a set list of types in the convention?

For me, this is not a feature request, this is a task. I am tempted to make it a bug because the type is not limited to the convention. The committer should see the options available and not have to go to outside documentation when making a commit. Since this is interfering with commit workflow, changing to Major.

Hi, if this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

@freelylw, if the problem is solved then it is best to close the issue.

There is no bug so changing to a support request.

quietone → changed the visibility of the branch 3552766-update-composer-dependencies to active.

quietone → changed the visibility of the branch 3552766-update-composer-dependencies to hidden.

quietone → changed the visibility of the branch 3552766-update-composer-dependencies to hidden.

Needs issues for Coder, refer to comment 185

The comment above is wrong, in the last meeting longwave reviewed the MR and said it was fine, 📌 Coding Standards Meeting Wednesday 2025-10-29 0900 UTC Active .

Created a coder issue, 📌 Enforce traits should always have the suffix "Trait" Active

quietone → created an issue.

Oops, sorry. @borisson_ confirmed the MR is correct in the last meeting, 📌 Coding Standards Meeting Wednesday 2025-10-29 0900 UTC Active

Can someone confirm the MR matches the changes in the issue summary?

This just needs someone to confirm that the MR matches the changes in the issue summary.

This was brought up in this meeting 📌 Coding Standards Meeting Wednesday 2025-10-29 0900 UTC Active . The members agreed to close this as won't fix for the reasons summarized in #27.

Thanks to everyone to help resolve this.

Thanks!

I have deleted the change record since it is not needed. And updated credit to include those from Drupalcon Atlanta who worked on the change record.

@aaronmchale, thank for the help!

I have followed the steps to remove a committee member, this is currently in internal Coding Standard Committee files. That includes removal as a maintainer, from the calendar etc.

Re-open if there is more to do or you think I should not have closed this.

Thanks

@aaronmchale, thanks you and best wishes!

I have followed the steps to remove a committee member, this is currently in internal Coding Standard Committee files. That includes removal as a maintainer, from the calendar etc.

Re-open if there is more to do or you think I should not have closed this.

Thanks

I have followed the steps to remove a committee member, this is currently in internal Coding Standard Committee files. That includes removal as a maintainer, from the calendar etc.

Re-open if there is more to do or you think I should not have closed this.

Thanks

Good point, let's move that to a new issue so we can discuss that point.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

This change here be in the release notes for 11.3.x, so I think we can skip the change record. I am changing the title of the change record so it can be deleted later.

Published the change record.

Reviewing the list in #12
1, 2, 3, 4: Fixed in 📌 Remove use of Contact from config_translation tests Active
5: Todo, core/modules/system/tests/src/Functional/UpdateSystem/UpdatePathTestBaseFilledTest.php
7: 📌 Change use of Contact in \Drupal\Tests\user\Functional\UserPermissionsTest::testAccessBundlePermission Active
8, 9: 📌 Remove unused modules from kernel tests RTBC
10: Will likely be fixed in 📌 Change use of Contact in ajax_test test module Active ; core/tests/Drupal/FunctionalJavascriptTests/Ajax/DialogTest.php
11: 📌 Change use of Contact in ContentEntityNullStorageTest Active

A fair bit of work went into adding examples to all the process plugins. This removes the example without adding a replacement. This needs a followup to add the api documentation.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . So, I am closing this as a duplicate of 🐛 Html errors in pages when using olivero Active .

Add 2025

quietone → created an issue.

quietone → created an issue.

quietone → created an issue.

I search for field_layout only found instances in the baseline and the module itself.