[meta] Tasks to deprecate Toolbar module

Explicitly postponing this on navigation being stable, but that is close per #3421969: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable.

We will need to enable navigation in the standard profile and umami in order to actually deprecate toolbar, but there might be some other things that could happen in the meantime like making sure that no tests have explicit dependencies on it.

#3421969-81: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable onwards discusses that Settings Tray also has a hard dependency on Toolbar, however Settings Tray has such low usage that decoupling them may not be effort well spent. Should their move to contrib be handled together then?

Looks like we could tackle the things in #9 and #10 before navigation is in standard, that would mean less work to do later.

Not much we can do with #9 yet I'm afraid.

These need #3465299: Integrate Announcements module into Navigation's drawer/submenu:

core/modules/announcements_feed/tests/src/Functional/AnnouncementsCacheTest.php
core/modules/announcements_feed/tests/src/FunctionalJavascript/AccessAnnouncementTest.php
core/modules/announcements_feed/tests/src/FunctionalJavascript/AlertsJsonFeedTest.php
core/modules/announcements_feed/tests/src/Kernel/AnnounceFetcherUserTest.php

These uses can likely be removed:

core/modules/config_translation/tests/src/Functional/ConfigTranslationListUiTest.php
core/modules/contact/tests/src/Functional/ConfigTranslationListUiTest.php
core/modules/responsive_image/tests/src/Unit/ResponsiveImageStyleConfigEntityUnitTest.php
core/modules/system/tests/src/Functional/Menu/MenuAccessTest.php
core/modules/views_ui/tests/src/Functional/DisplayPathTest.php

Some parts of these test integration with contextual.module, so probably needs to be moved into toolbar.module?

core/modules/contextual/tests/src/FunctionalJavascript/ContextualLinksTest.php
core/modules/contextual/tests/src/FunctionalJavascript/EditModeTest.php

These are false positives:

core/modules/editor/tests/src/Functional/Rest/EditorResourceTestBase.php
core/modules/editor/tests/src/Kernel/EditorValidationTest.php
core/modules/jsonapi/tests/src/Functional/EditorTest.php

These need to move into toolbar.module:

core/modules/layout_builder/tests/src/FunctionalJavascript/LayoutBuilderToolbarTest.php
core/modules/system/tests/src/Functional/Theme/ToolbarClaroOverridesTest.php

These only uninstall toolbar from standard or Umami:

core/modules/navigation/tests/src/FunctionalJavascript/PerformanceTest.php
core/profiles/demo_umami/tests/src/FunctionalJavascript/OpenTelemetryAuthenticatedPerformanceTest.php

Some parts of these test integration with shortcut.module, but that is also moving to contrib:

core/modules/shortcut/tests/src/Functional/ShortcutCacheTagsTest.php
core/modules/shortcut/tests/src/Functional/ShortcutTestBase.php
core/modules/shortcut/tests/src/Functional/ShortcutTranslationUITest.php
core/modules/shortcut/tests/src/Kernel/ShortcutCacheTagsTest.php

This needs to stay until we update the database dump:

core/modules/system/tests/src/Functional/UpdateSystem/UpdatePathTestBaseFilledTest.php

This probably needs #3511374: Core Navigation + Workspace + Workspace UI modules crashes Drupal Installation and then the toolbar tests moving to toolbar.module:

core/modules/workspaces/tests/src/Functional/WorkspaceSwitcherTest.php
core/modules/workspaces/tests/src/Functional/WorkspaceTest.php
core/modules/workspaces_ui/tests/src/FunctionalJavascript/WorkspaceToolbarIntegrationTest.php

The toolbar hook implementations I think we could move all of those into the toolbar module with a moduleExists() check.

This can't be completed until #3560117: [meta] Add Navigation to the Standard profile and recipes lands, which in turn is waiting for accessibility issues in Navigation to be fixed.

It feels unlikely at this point that Toolbar will be removed from Drupal 12.

Also related to toolbar: _system_is_claro_admin_and_not_active() and the 3 hooks in system module that use it, I don't know why that stuff is in system and not in toolbar, should be easy enough to move, I guess including claro_system_module_invoked_library_info_alter() in claro.theme.

I bet there's one more blocker - who is willing to maintain it in contrib

I see the Drupal 6 module https://www.drupal.org/project/toolbar, perhaps it can be Drupal core Toolbar's new home?

@dydave maintains https://www.drupal.org/project/admin_toolbar and I made him aware of this issue in #3565206: [Meta] Roadplan for Admin Toolbar 3.7 and 4.x, as a potential maintainer.

That was originally a backport of the Drupal 7 module, makes sense to keep the namespace the same as core's.

As mentioned by my contrib partner @ressa above at #19, I've been maintaining the Admin Toolbar module for more than a year now and would certainly be interested in helping maintaining the Toolbar module if it moves over to contrib.

Feel free to add me directly as one of the maintainers, if you'd like, or please let me know if you would like me to formally apply in module's issue queue, I would be glad to do so.

Congrats everyone for all the great work and efforts getting core Navigation stabilized. 🥳

Thanks in advance! 😊

Running into #4 over at #3575909: Remove the Settings Tray dependency on Toolbar - settings tray doesn't really work without toolbar, looks like we either need to make settings tray work with Navigation instead, or remove settings tray as well.

The toolbar/claro stuff in system module is fully moved to toolbar module in #3579899: Remove remaining claro.theme functions, but we likely need a follow-up to that to clean up a few things around that such as hardcoded core/themes/claro paths (this will not prevent removing toolbar, but it will need to fixed eventually before claro is moved)

Re #21:
I've contacted the contrib Toolbar module maintainer who kindly granted me maintainer's rights, see:
#3607179: Applying for 'Maintainer' role for the project Toolbar

I went ahead and imported the core toolbar module with its complete history with the command:
git filter-repo --subdirectory-filter core/modules/toolbar/
into the 1.x branch in contrib Toolbar module's repo:
https://git.drupalcode.org/project/toolbar/-/commits/1.x

I'll make basic adjustments to the info, composer.json, .gitlab-ci files to get a minimal DEV release, which should allow unblocking the D12 compatible DEV for Admin Toolbar (4.x).

Added tests part 2 to issue summary.

I fed the current diff of #3611762: Move toolbar hook implementations to the toolbar module and #3612474: Move toolbar integration tests to toolbar module, part 2 to Claude (with Sonnet 4.6) to find any other missing gaps. It found these that seem like are not already covered:

There are also these shortcut module mentions that I don't think need to be done given that shortcut also is moving to contrib.

Pretty sure the contextual test should either be moved to toolbar or deleted, per #3465295: Integrate Top Bar Navigation with Contextual editing where it was decided not to implement similar functionality in navigation.

Added #3614955: Move library overrides for Toolbar from Claro and Default Admin to Toolbar for the library overrides, it seems pretty straightforward to move them from both Claro and Default Admin to Toolbar. Gets rid of some 'gin' mentions of default_admin even and also noticed that a CSS file was added by Default Admin that did not even exist. See there.

The contextual clicking integration test is already handled in #3612474: Move toolbar integration tests to toolbar module, part 2 by being removed, so that satisfies @catch's note in #38 :) No need to open an issue for that. So I think everything in #37 is now covered.

I found the following (used LLM to assist me, but verified the found code paths and even manually tested some stuff):

Will be removed with the Shortcut module, should be done before Toolbar IMHO, so it stays in contrib Shortcut:

1. ShortcutHooks.php:71 — uses #[Hook('toolbar')] and the toolbar_item render element

2. Shortcut tests heavily use Toolbar. ShortcutTestBase.php:20 , ShortcutTranslationUITest.php:43, ShortcutCacheTagsTest.php:32 and multiple shortcut tests grant 'access toolbar' permission.

Should still be moved to the Toolbar module to not loose these integrations

The backend parts of these were attempted to be moved in #3611762: Move toolbar hook implementations to the toolbar module but in many cases the utility classes, CSS/JS libraries, etc. stayed around with the modules apparently.

1. We already accepted the regression of announcements not appearing in the default toolbar (in Drupal CMS they are prominent on the dashboard). The base toolbar hook was moved but AnnouncementsFeedToolbarHooks.php:22 still implements hook_toolbar_alter() and LazyBuilders.php:48 — uses toolbar CSS classes and announcements_feed/drupal.announcements_feed.toolbar library.

2. User module integration in user.services.yml:53 — defines user.toolbar_link_builder and ToolbarLinkBuilder.php itself, despite the hook already moved to Toolbar.

3. Contextual menu integration for Toolbar has this toggle feature that shows ALL the contextually editable things. Navigation does not implement this. It was decided in #3465295: Integrate Top Bar Navigation with Contextual editing 2 years ago not do that. The hook implementation was moved to Toolbar already but contextual.libraries.yml:25 was not.

4. Workspaces UI module has integration with Toolbar. The hook implementation was moved already but WorkspacesUiLazyBuilders.php:44 remained. It uses toolbar-item, toolbar-icon CSS classes and workspaces_ui/drupal.workspaces_ui.toolbar library.

Should be removed at the same time as the Toolbar module:

1. Default Admin integration (this does not exist as contrib, so should be removed alongside Toolbar removal in core). PreprocessHooks.php:650 uses $this->currentUser->hasPermission('access toolbar'), ThemeHooks.php:222 overrides toolbar and menu__toolbar theme registry paths, PreprocessHooks.php:1223 — #[Hook('preprocess_toolbar_user_picture')] and template overrides in core/themes/default_admin/templates/navigation/.

2. Various small overrides and mentions.

• toolbar template overrides in core/themes/claro/templates/navigation/
• Umami profile has toolbar-warning.css, toolbar component CSS, toolbar template override
• PHPStan baseline — 6 suppressed entries for toolbar classes
• Navigation module — @see toolbar_page_top() docblock references
• core/misc — comments in displace.js and off-canvas CSS mentioning toolbar

I opened #3618746: Move Toolbar uses in Announcement, User, Contextual to Toolbar for the ones that still need moving (where we already moved hooks in #3611762: Move toolbar hook implementations to the toolbar module but left around other integrations.

@quietone opened and started working on the toolbar alter in announcements feed at #3618772: Move toolbar_alter hook implementations to the toolbar module, left some feedback there.

Thank you all for the great work on making Drupal core easier to maintain. I saw that the Toolbar is deprecated Change record was published yesterday and Drupal 12.0.0-alpha1 was released 2 September 2026, which is really great.

But Toolbar was supposed to have a stable release before the Drupal 12 alpha version release, number 4 on the list:

4. Create the contrib project with a stable release, before the alpha version of the major release. Follow the process in Create the contrib project with a stable release for creating the sub tree split.
5. ✅Deprecate the core extension #3560123: Deprecate the Toolbar module.
6. #3567861: Ensure that Toolbar does not get special core treatment

As I understand it, @dydave who graciously volunteered to maintain Toolbar is sort of blocked by #3567861: Ensure that Toolbar does not get special core treatment, since the Composer name for Toolbar is still drupal/toolbar-toolbar.

I guess the official release could be with drupal/toolbar-toolbar, but couldn't that cause problems later?

To prevent this from happening in the future, perhaps the order of the last items in "[meta] Tasks to deprecate XYZ module" issues could be re-ordered? Also, the list could include Publish Change record as the very last step, when all other prior tasks have a green check mark:

4. #3567861: Ensure that Toolbar does not get special core treatment
5. Create the contrib project with a stable release, before the alpha version of the major release. Follow the process in Create the contrib project with a stable release for creating the sub tree split.
6. ✅ Deprecate the core extension #3560123: Deprecate the Toolbar module.
7. Publish Change record

@quietone: The Composer name is still drupal/toolbar-toolbar, shouldn't that get corrected first, or maybe it's fine?

Also, what do you think about my suggestion about placing "Ensure that XYZ contrib module does not get special core treatment" much sooner in the process, so that it's handled well in advance?

It seems that getting the drupal/search Composer name space sorted out was also not trivial, and caused a delay.

I understand that the infrastructure team has a lot of tasks, but it would be nice if the contrib maintainer of deprecated core modules was not burdened with figuring infrastructure stuff out, so they can concentrate on the the actual project code.

@ressa see #3616593: Add all modules & themes to the composer replace section for the 'special core treatment' issue, we can get rid of that step once we finish that issue.

Thank you so much for clarifying @catch. I had been following along that issue, but did not realize that it was connected to the strange instances of doubled-up naming, like these:

• drupal/toolbar-toolbar
• drupal/webform_bootstrap-webform_bootstrap

It would be wonderful to prevent this, by making the structure more robust, so thanks for working on it!

PS. It is still unclear to me if a stable release should, or ought not to be made with the drupal/toolbar-toolbar name ... I would guess that it has to wait, until it has been changed to drupal/toolbar.

Re #53 : Thanks a lot @quietone!

I need to merge over all the changes to the core toolbar module made after my previous merge :
https://git.drupalcode.org/project/drupal/-/commits/11.x/core/modules/to...
Merge over everything after May 15 2026...

I'm on it! 👌

Quick questions just to confirm:

• Is the module deprecated as of 11.4 or 11.5?
• Should the contrib module support 11.4 and above or 11.5 and above?
• Do we really need a stable version ASAP or could it wait a little bit so we could do some more testing/debugging?
• Do we need a stable release in order to unblock the composer namespace issue? (See the exchanges above with my contrib partner @ressa)

 
I'll start looking at bringing over the remaining revisions ASAP.
 
Thanks in advance! 🙏

Super nice and speedy replies. Thanks a lot @quietone! 🙏
You've answered all my questions (at least for now 😅)
➡️ No blocker ... I'm working on making the necessary changes, give the module a round of tests and create the 1.0.0 initial stable release, as requested.

I'll get back to you on this as soon as it is ready for review. 👍
Thanks again!

OK, @ressa, @quietone:
The module's expected 1.0.0 version is ready to be tested in merge request:
https://git.drupalcode.org/project/toolbar/-/merge_requests/2

In short:
1 - Merged over all the missing revisions from the Core Toolbar module (everything after May 15 2026):
I'm quite happy with the result since I was able to retain the full history of the changes with the authors, the dates, etc... Even though I had to cherry-pick them and fix some conflicts.

2 - Added support for D11.4, which required a small adjustment in file:
/src/Hook/ToolbarHooks.php

@quietone:
Could you please help me do a very quick review of my additional commit?
https://git.drupalcode.org/project/toolbar/-/merge_requests/2/diffs?comm...
Just to get your final check on this.

@ressa:
Could you please help me do a quick round of manual testing locally, when you get a chance?
Just to confirm everything is working as expected.

This work is being tracked in #3624202: Prepare initial stable release 1.0.0. I've done some manual testing locally with D11.4.7 and everything seemed to work as expected. 🥳

As soon as I can have your confirmations on these changes I will merge the MR and create the corresponding 1.0.0 release.🤞
Overall, you can definitely expect this task to be completed in a very timely manner. 👌

Feel free to let me know if you spot anything or would have any questions, I would surely try answering as soon as possible.
Thanks in advance! 🙏

OK, no problem @quietone 👌

We'll just assume this commit is OK 😊

Let's just wait on @ressa's feedback on his tests of the changes and we'll be able to merge the MR.

Thanks again @quietone!

DONE @quietone in the MR:
https://git.drupalcode.org/project/toolbar/-/merge_requests/2/diffs?comm...
Changed to:
package: User interface
(Copied/inspired from the Tour and Shortcut modules)

For the tests modules (in toolbar/tests), should I keep the package property as 'Testing'?
package: Testing
Or change it to somethign else as well?

I'm not really on Slack and won't have much time this afternoon, but maybe @quietone, if you are already on Slack, could you perhaps share the MR / commit with co-contributors so we could maybe get some more feedback?

As a side note, my pipelines currently crash ... so I'd have to further adjust the gitlab-ci config... but that should not be a blocker for the 1.0.0 release.

Let me know if you see anything else, I would surely be glad to make any required or suggested revisions.
Thanks again @quietone! 🙏

Thank you both of you for fast responses, it's great to see so much progress! @dydave, I gave the MR a test spin, and it worked great. I did run into a problem if I freshly installed with contrib Toolbar, and left some comments.

@quietone, thank you for feedback on my suggestions, where some where based on my limited understanding of the infrastructure. It sounds good that the order of elements can be evaluated. And I do understand that it's not easy, since there are so many moving parts -- everyone of you involved have my deepest sympathy, and I very much respect the great work that you do. You all definitely deserve a break, after juggling this avalanche of deprecations :)

Re #66: Thanks @quietone!

The only thing we need is a stable release so that the steps #3488828: [meta] Tasks to remove Toolbar module can be completed.

How soon do we need this?
Should we create the stable release immediately, no matter if there are known issues or bugs?
Or could we wait just a little bit more, maybe until Tue. 10/22 or Wed. 10/23, so we could get more time to test, debug and refine before creating a more solid stable release?
 

Since I had a bit of time at the end of today, I followed your advice (#52) and requested some technical help in the #code-development Drupal Slack channel:
https://drupal.slack.com/archives/C079NQPQUEN/p1789749547318839

Hopefully, we'll get some more feedback and help reviewing the changes in the MR.
Thanks again very much @quietone!

@quietone: Really sorry for the delay, but finally:

The initial release of the Toolbar module compatible with Drupal 12 was just created:
https://www.drupal.org/project/toolbar/releases/2.0.0

Could you please let us know if you would need anything else in order to keep moving with your tasks and the tagging of the D12.0.0-beta issue?

Thanks in advance!