🇳🇿New Zealand @quietone

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.

Moved the info from #23 to the issue. At least 3 more issues are needed.

@rmahi_14, thanks for the interest in this issue. However, this issue does not need an issue fork. I suggest you consult the Drupal Contributor Guide → to find a task suited to your interests and skills.

I'm wondering, should we add a component "Admin theme" to the core project?

I couldn't think of a reason not to, so I did.

@jurgenhaas, I've updated it again.

@pameeela, thanks! I've updated the issue summary with that.

I also added remaining tasks to help keep track of things to do

There are instances of "Gin" in comments that I think should now be changed to "Admin". I was making suggestions for those but GitLab was being a bit faster. But then I discovered that it isn't showing all the files in the change. So, I am going to step away from this for now. Maybe tomorrow I will make a commit for those changes.

I followed the steps in the issue summary after logging in the admin pages result in

Twig\Error\LoaderError: Template "core/themes/admin/templates/navigation/menu--toolbar.html.twig" is not defined in "core/themes/admin/templates/html.html.twig" at line 51. in Twig\Loader\ChainLoader->getCacheKey() (line 51 of core/themes/admin/templates/html.html.twig).

I get 28 words flagged by cspell. Of those 11 are in the cpp dictionary and one in the css dictionary. That is not enough to consider enabling those dictionaries, not that we would use the C++ dictionary anyway. And using the css one is for another issue. Next, is to consider renaming. I think that improves readability so I would prefer that option. However, js and css are not my area so this needs more opinions are needed. If it helps the discussion I can do the renaming work.

I made a commit of a what I wanted to add as suggestions but GitLab is painfully slow for me so I gave up. The commit includes changes like 'dark mode' instead of 'darkmode' because it is referring to the mode, not the name of the setting. Also, in a few cases I tried to make the distinction between any admin theme and this particular admin theme. Those are user facing and should be checked carefully.

In fact, it is usually confusing what is meant by 'admin' and 'admin theme' in the comments. Is it referring to this particular theme or any administrative theme?

And, I think the doc pages should include an introductory remark for developers that Admin involved from Gin and thus many settings etc use the word 'gin'.

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

Remove steps 5 - 10 of "Procedure for removing alpha modules".

I did talk to confirm this with catch a few weeks ago. Finally coming back to write that up. The short answer is that nothing should change for the migrations.

So, if a legacy site migrates to Drupal 11, and text_with_summary is deprecated, the migration will still work. Then, after the migration, such a site can choose to use a contrib module that provides text_with_summary. The migration has already happened so the contrib module does not need to supply the migration or test it. Of course, such a site may just upgrade to Drupal 12 which should be providing an upgrade path for text_with_summary.

Add item to save the maintainers page on the project

@smaz, thank you!

Committed to 11.x and backported.

I can also confirm this is working for Claro.

@sirclickalot, Hi. I suggest you ask in other places as well. 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.

Cheers

@mstrelan, thanks

Committed to 11.x and cherry-picked to 11.3.x

Thanks!

That is being done in  https://www.drupal.org/project/infrastructure/issues/3530663 📌 Redirects for Coding standard pages to GitLab pages Active . .

I think a better title would say that this is a deprecation. I didn't see any comment that the change record has been reviewed, that is really part of the process to set an issue to RTBC.

I took a look and thought it could use some wording changes and an 'after' example. I have made those changes.

@benjifisher, thanks.

I think the title doesn't need to state that 'Drupal' is doing something.

Committed to 11.x and cherry-picked to 11.3.x

Thanks!

Committed to 11.x and cherry-picked to 11.3.x

Thanks!

There are two files being changed, so updating title.

For the first point, I think a comment on the removal issue is sufficient. So, I have added an item in 📌 [12.x] [Meta] Tasks to remove Migrate Drupal UI module Postponed to remove the lines from testCoreLibraryCompletenessDeprecated(). And added another item to 📌 [12.x] [Meta] Tasks to remove Migrate Drupal UI module Postponed for stable9.info.yml.

Yes, that search looks sufficient to me.

For the docs, I added Migrate Drupal UI to the documentation page. It will need updating when this is committed to correct the tense but at least the link will work. It should probably say that the community can move it to contrib but my words aren't flowing this late in the day. I tagged this for doc updates.

Add item to remove usage from stable9.info.yml.

There are items in the issue summary that are only relevant for an extension being moved to contrib. Those need to be removed.

Add Migrate Drupal UI to recommendations.

Fails for me as well. Git bisect reports that 5d387a is the commit where the failure started. That is about CSS not PHPUnit error handling.

Following are some questions and comments as I reviewed this.

Having the grep command in the Issue Summary would make this easier to review.

These are listed in the issue summary as needing to be changed but they are not changed in the MR. Nor is there discussion of why they are not changed.

• core/modules/system/tests/themes/test_theme_mixed_module_dependencies/test_theme_mixed_module_dependencies.info.yml
• core/modules/system/tests/themes/test_theme_depending_on_nonexisting_module/test_theme_depending_on_nonexisting_module.info.yml
• core/modules/system/tests/themes/test_theme_depending_on_modules/test_theme_depending_on_modules.info.yml
• core/modules/system/tests/themes/test_theme_depending_on_constrained_modules/test_theme_depending_on_constrained_modules.info.yml
• core/modules/package_manager/tests/modules/package_manager_test_validation/package_manager_test_validation.info.yml

The title could also be more specific add state that it is adding the "{project}:" portion to module dependency keys were possible. I tried to do that.

Setting to NW for comment on MR.

Thanks for helping to improve our testing messages.

While I agree the assertion message is confusing in context, Drupal does not provide guidelines on whether an assertion message should be written as what is expected or as a failure message. So, technically the assertion message is not correct. So, I think the title should change.

The issue mentioned in #7 resulted in doc changes. They are at Drupal Test coding standards → . That says that assertion messages can be added when the assertion is in a helper method, which it is in this issue. Since this is a helper method let's keep the message but make it sensible, I suggest, but there may be better choices, that it could be changed to Log in of User {$account->getAccountName()} failed.

There are also other usages of this string in an assertion message. All instances should be changed in this one issue.

$ git grep 'successfully log'
core/profiles/demo_umami/tests/src/Functional/DemoUmamiProfileTest.php:    $this->assertTrue($this->drupalUserIsLoggedIn($account), "User {$account->getAccountName()} successfully logged in.");
core/tests/Drupal/Tests/UiHelperTrait.php:    $this->assertTrue($this->drupalUserIsLoggedIn($account), "User {$account->getAccountName()} successfully logged in.");

@shubham_pareek_19, thanks for explaining what you did to review this MR.

Committed to 11.x and cherry-picked to 11.3.x

Thanks.

This looks lovely, I do like a cleanup. I found 2 migrate tests that should be change. Sadly, I couldn't make a suggestion, GitLab isn't giving me that option. There are lots of files changed here and I relied heavily on the file name to find ones that may need adjustment. After that I checked about a range of files and most often found that the removed modules were loaded in a parent class. And for those that weren't the change to $modules seemed just obvious.

When the changes are made, I think this can go back to RTBC.

Setting to needs work to check the usages I found and, at least, an issue to update comments referring to these annotations, such as in core.api.php.

I also found some @coversClass

core/modules/jsonapi/tests/src/Kernel/ResourceType/RelatedResourceTypesTest.php: * @coversClass \Drupal\jsonapi\ResourceType\ResourceTypeRepository
core/modules/jsonapi/tests/src/Kernel/Serializer/SerializerTest.php: * @coversClass \Drupal\jsonapi\Serializer\Serializer
core/modules/media/tests/src/FunctionalJavascript/MediaEmbedFilterTestBase.php:    // Necessary for @covers to work.
core/tests/Drupal/Tests/Core/GroupIncludesTestTrait.php: * @coversDefaultClass \Drupal\Core\Hook\HookCollectorPass

And @dataProviders

core/tests/Drupal/FunctionalJavascriptTests/Core/Field/TimestampFormatterWithTimeDiffTest.php:    // Unit testing Drupal.timeDiff.format(). Not using @dataProvider mechanism
core/tests/Drupal/FunctionalJavascriptTests/Core/Field/TimestampFormatterWithTimeDiffTest.php:    // Unit testing Drupal.timeDiff.refreshInterval(). Not using @dataProvider
core/tests/Drupal/Tests/Core/Asset/LibraryDiscoveryParserTest.php:   * @dataProvider providerTestCssAssert

I searched and found instances of @group in 20 files

$ git grep @group | grep .php | awk -F: '{print $1}' | sort -u | nl
     1  core/core.api.php
     2  core/lib/Drupal/Core/Test/TestDiscovery.php
     3  core/modules/layout_builder/tests/modules/layout_builder_field_block_test/src/ContextProvider/FakeViewModeContext.php
     4  <del>core/modules/migrate_drupal/tests/fixtures/drupal6.php</del>
     5  core/modules/migrate_drupal/tests/src/Traits/ValidateMigrationStateTestTrait.php
     6  <del>core/modules/views/src/FieldViewsDataProvider.php</del>
     7  <del>core/modules/views/src/Plugin/views/HandlerBase.php</del>
     8  <del>core/modules/views_ui/src/Form/Ajax/RearrangeFilter.php</del>
     9  core/tests/Drupal/KernelTests/Core/Hook/HookOrderTestTrait.php
    10  core/tests/Drupal/Tests/Component/DependencyInjection/ContainerTest.php
    11  core/tests/Drupal/Tests/Core/GroupIncludesTestTrait.php
    12  core/tests/Drupal/Tests/Core/Test/TestDiscoveryTest.php
    13  core/tests/Drupal/TestTools/Extension/DeprecationBridge/DeprecationHandler.php
    14  core/tests/Drupal/TestTools/Extension/DeprecationBridge/ExpectDeprecationTrait.php
    15  core/tests/PHPStan/fixtures/test-classes-with-metadata.php
    16  core/tests/PHPStan/fixtures/test-methods-with-metadata.php
    17  core/tests/PHPStan/Rules/TestClassClassMetadata.php
    18  core/tests/PHPStan/Rules/TestClassMethodMetadata.php
    19  core/tests/PHPStan/tests/TestClassClassMetadataTest.php
    20  core/tests/PHPStan/tests/TestClassMethodMetadataTest.php

Some things I found:

• An issue is needed for comments, at lease core.api.php needs to be updated to not recommend @group. Is there an issue?
• There are traits with @group, where I guess the @group can be removed..
• There are usages in ContainerTest.php

I didn't check others closely, although most appear needed for testing.

Committed to 11.x and cherry-picked to 11.3.x.

Thanks for the cleanup!