Problem/Motivation

With the coming deprecation of Toolbar (#3484850: [meta] Tasks to deprecate Toolbar module) and release of Drupal 11.4 and Drupal 12, we should create a new major release (version 4) which will be compatible with Drupal 12.

So this issue's regular Admin Toolbar tickets are postponed until the "Transfer Toolbar tasks" below are solved, after the Toolbar module is ready in contrib.

A very likely scenario is that the 3.x branch will keep supporting the same versions: 9.5+, 10 and 11, while a new 4.x major branch will have to be created to support 11.4 and 12, due to new Composer constraints:

  • 3.x → D9.5 / D10 / D11.0–11.3 (maintenance/security only, current)
  • 4.x → D11.4+ / D12 (new development branch)

Why a new major?

The updated dependency on the contrib Toolbar module in composer.json is a breaking change. All the different versions of the Toolbar module for the minor core branches would also need to be added to the contrib module's repo, which seems like a lot of work to keep backwards compatibility.

Additionally, a breaking change with a new major would allow proper removal of the sub-module admin_toolbar_links_access_filter, which has been deprecated since Drupal 10.3.

We should be able to come back soon to the regular Admin Toolbar issues, when the contrib Toolbar is ready for use.

But as usual, these issues are for refactoring of the code, as well as adding new features, and this Meta issue gathers the relevant issues.

Steps to reproduce

  • See that Toolbar is moving from Drupal core to contrib in Drupal 12.
  • See that the code could be improved, and new features added.

Proposed resolution

Planned issues:

Transfer Toolbar tasks

Transfer ownership of Toolbar module project and set up Composer namespace to be drupal/toolbar:

Regular Admin Toolbar issues

 
Done:

  • None fixed yet.

 
Possibly postponed issues:

  • [...]

 
Nice to have issues:

 

Remaining tasks

User interface changes

API changes

Data model changes

Comments

dydave created an issue. See original summary.

dydave’s picture

dydave commented
Issue summary: View changes
Related issues: +#3565209: [Meta] Drop support for Drupal 10.2 and below

Added structuring key BC breaking issue.

dydave’s picture

dydave commented
Issue summary: View changes
Related issues: +#3529217: Determine and implement JS dependency approach, +#3565861: Add support for Ctrl + click in Search, or add as setting option?, +#3557369: Disabled, show on scroll-up does not work in Git-version

Stacking up potential issue candidates. 😊

ressa’s picture

ressa
he/him
commented
Issue summary: View changes
Related issues: +#3553200: Add support for compact display options

Looks good! Just adding the compact issue.

ressa’s picture

ressa
he/him
commented
Issue summary: View changes

On an Admin Toolbar related note, Toolbar will soon need a new home, after #3484850: [meta] Tasks to deprecate Toolbar module. Perhaps you could be interested in becoming a maintainer @dydave? 🙂 It could help facilitate fantastic changes and improvements, by allowing optimal coordination between the two projects.

dydave’s picture

dydave commented

Totally!! Super nice @ressa!

Thanks a lot! 🙏

In fact, there is already a ticket I was pushing in the core Toolbar module, see:
In AT: #3426402: zindex issue between admin toolbar and ckeditor 5
In Toolbar: #3410871-24: The CKEditor 5 toolbar is overlapping with the Admin toolbar .... looks like no one is actually going to answer anymore 😅

How would I go about asking to become maintainer for the Toolbar module?

I'll post a quick message in the ticket you indicated to let them know I would be interested in taking over the maintenance. 👌

Sorry for not having been very active in module's queue lately .... I've been a bit busy preparing my proposals for DrupalCamp France in April and DC Rotterdam in October ....
The submission deadlines are all this week 😅

I'm hoping I can get a bit more time the following weeks to get a few tickets landed 👍

But I'm following everything ... in case anything urgent pops up.

Thanks again very much @ressa!

ressa’s picture

ressa
he/him
commented

Thank you @dydave for a fast reply, as always!

It's fantastic that you are ready to take on the task of Toolbar contrib maintainer, thank you very much! I see you asked about the process in the other issue, and hopefully they can help guide you.

And no problem about the quiet, Admin Toolbar is in really great shape after your coding frenzy last year, which really pays off now, as can be seen in the very low number of new bug issues. I wish you good luck with the applications!

dydave’s picture

dydave commented

I think I missed one of the main aspects in this issue:

A new 3.7 release would not be able to support D12, since it has a breaking change, moving the core toolbar module to contrib.

So all these tickets are most likely going to be paused for now, until we have a better vision of the toolbar module in contrib, see:
#3484850: [meta] Tasks to deprecate Toolbar module.

It is very likely that the 3.x branch will keep supporting the same versions: 9.5+, 10 and 11.

And that a new 4.x major branch will have to be created to support 11.4 and 12, mostly because the composer constraints will have to change.

3.x → D9.5 / D10 / D11.0–11.3 (maintenance/security only, current)
4.x → D11.4+ / D12 (new development branch)

Why a new major?

As mentioned this is a breaking change with the composer.json depending on the contrib toolbar module which would not have the different versions core has.
If the changes were made to the 3.x branch, the composer requirements would also have to work for all previous core versions 9.5, 10 and 11.
All the different versions of the toolbar module for the minor core branches would also need to be added to the contrib module's repo, which seems like a lot of work to keep backwards compatibility.

Additionally, a breaking change with a new major would allow proper removal of the sub-module admin_toolbar_links_access_filter, which has been deprecated since 10.3.

We should be able to come back soon on this issue, when 11.4.0 is released and see how the contrib toolbar module evolves.

ressa’s picture

ressa
he/him
commented
Title: [Meta] Roadplan for Admin Toolbar 3.7 » [Meta] Roadplan for Admin Toolbar 3.7 and 4.x
Issue summary: View changes
Related issues: +#3484850: [meta] Tasks to deprecate Toolbar module

Thanks for a great description of the situation @dydave, I think your plan sounds just perfect! I agree that being able to remove the deprecated sub-module admin_toolbar_links_access_filter would be very nice. I have attempted to update the Issue Summary based on your comment, and feel of course free to correct it, if something is not quite right.

About Toolbar as contrib, I wonder if the https://www.drupal.org/project/toolbar maintainer has been contacted to check if it can be Drupal core Toolbar's new home? Because Drupal 12 will be released December 2026 without Toolbar in Drupal core ... so wouldn't it be nice to have Toolbar contrib ready soonish, to be able to release Admin Toolbar 4.x-dev by mid-September 2026, and aim to have a stable Admin Toolbar 4.0 release ready by mid-November 2026?

dydave’s picture

dydave commented

@ressa!!! 🤩

Super nice to hear from you! 😊

YES! Definitely....

About Toolbar as contrib, I wonder if the https://www.drupal.org/project/toolbar maintainer has been contacted to check if it can be Drupal core Toolbar's new home?

How do we go about that? Do we have to do everything ourselves? Or do the Core maintainers have a procedure or play a role in this?

  • Request maintainer role for the Toolbar module.
  • Then import all the code from the core module.

 
Something like this?

I wouldn't be surprised we would need to do everything ourselves, given how busy the Core Team is, usually... 😅
Let's try getting this moving so we could potentially aim at a D12 release at the end of the summer.

Thanks again for keeping an eye on the module! 🙏

ressa’s picture

ressa
he/him
commented
Related issues: +#3575102: Taking over the Keyboard shortcut namespace, +#3569117: [meta] Tasks to deprecate the Shortcut module

Thank you @dydave! Your thoughts about the two steps look correct:

  1. Request Maintainer role for the Toolbar namespace (drupal/toolbar / drupal.org/project/toolbar)
    It seems like the next step is that the appointed contrib maintainer creates an issue in the project (https://www.drupal.org/project/toolbar) requesting transfer of namespace ownership. Something like #3575102: Taking over the Keyboard shortcut namespace which @andypost made for the drupal/shortcut namespace #3569117: [meta] Tasks to deprecate the Shortcut module.

    And when it's created, you could share it in #3484850: [meta] Tasks to deprecate Toolbar module? Perhaps a "Transfer of Toolbar namespace"-issue could be created at the same time in https://www.drupal.org/project/issues/infrastructure? (or maybe wait 14 days ...)

  2. Import code from the Drupal core Toolbar module
    Could the steps about infrastructure outlined in the documentation page about How to deprecate and remove an extension > Create the contrib project with a stable release work? I now see this on that doc page:

    The stable release of the contrib project should be released before the alpha version of the Major release in which the modules are removed. The stable release must support the version of core when the extension was deprecated.

    It says "Friday, September 11, 2026: Drupal 12 beta requirements must be completed" on the Drupal core release cycle page, and since Alpha is about a two weeks before, this means that Toolbar ideally has a stable release by mid-August 2026 :)

I like your plan of aiming for a D12 release at the end of the summer, I'll surely be ready to test the code as soon as there is something ready for testing! 🙂

dydave’s picture

dydave commented

Thanks a lot @ressa!

Let's get on with this and start the procedure... I had no idea we had to do everything ourselves 😅

OK : What if I ask for the Toolbar full project maintainership, as it currently is?
https://www.drupal.org/project/toolbar
The module only has code for D6, which should not be conflicting with any of our code.

Then close all the D6 outdated tickets, import everything in new branches, create new releases, etc...
That could work no?!

Do we really need to go through a namespace transfer, so move the current toolbar project to toolbar_d6, for example, then create a new blank project?

Looks like this is what they did for the Shortcut project: (It still has all the D7 code)
https://git.drupalcode.org/project/shortcut/-/blob/7.x-1.x/shortcut.modu...

For the time being, I went ahead and requested maintainership for the Toolbar module:
#3607179: Applying for 'Maintainer' role for the project Toolbar

Let me know what you think. 🙏

dydave’s picture

dydave commented

I've contacted the current maintainer by email ... I have great doubts the person will reply....

Let's maybe give it until the end of the week and then move the issue to project ownership.

ressa’s picture

ressa
he/him
commented

Thank you so much for the fast issue creation of request for maintainer-ship, it's great when momentum is kept, as you always do!

Requesting Maintainer-role seems to be the right approach like you did, but I don't know anything about all the technical parts, sorry ... Maybe ask in the deprecate Toolbar issue?

Then close all the D6 outdated tickets, import everything in new branches, create new releases, etc...

That sounds like a good plan!

I see that @elizondo already granted you the Maintainer role, which is fantastic, allowing us to keep moving forward with the Toolbar contrib task 🚀

dydave’s picture

dydave commented

Wew! That was fast! 🥳
Sometimes things just work out! 😆

I replied to Luis (the maintainer) to thank him very much for granting me maintainer's rights so quickly! 🙏

OK: at this point, I should have everything needed to move forward with the D12 releases of the modules, all the way 🥳

I've done a bit of research on the core modules or themes deprecated previously or themes, such as seven, bartik, shortcut, tour, etc...

I think at this point I have a clearer idea of the next steps. 👍

Let me start experimenting a bit with the Toolbar module and I'll report back here. 👌
Hopefully, this should greatly help unblocking the issue queue, since we would be able to make a great jump supporting 11.3 and above.
Thanks again for your help @ressa! 😊

ressa’s picture

ressa
he/him
commented

This is great @dydave! Yes, that was a pleasant surprise, because processes like this can drag out, as seen in other issues, sadly not rarely ...

Wew! That was fast! 🥳

Totally, your update comment (30 June 2026 at 00:08), granting of Maintainer-role, and committing Toolbar 1.x code on Gitlab (1 July 2026 at 00:06) happened in under 24 hours :)

Sounds fantastic that you got all you need to move forward. I have subscribed to "All issues" from the Toolbar contrib module, so I'll see new issues you create, and feel free to ask for testing of new code (or whatever assistance is needed) in this issue, or over there 🙂 Thanks!

dydave’s picture

dydave commented

Thanks a lot @ressa! 😊

I have subscribed to "All issues" from the Toolbar contrib module

Ha ! 😅 You've probably been spammed with all the D6 tickets I closed yesterday 😅 (~28)

OK, just to give you a quick update:
I've processed all the tasks listed in #3607275: Create an initial 1.x-dev release for module Toolbar ✅

In particular, I've created an initial DEV release: toolbar-1.x-dev
which should allow unblocking us for the development of the D12 version for AT.

Then, I realized we did not have the correct namespace for the composer command 😅
Which brought me back to your comment above #11, so I created #3607814: Reserve the Composer namespace drupal/toolbar for this project to ask for help.

Hopefully, if this could be unblocked, we should be able to start creating the 4.x branch with a composer dependency. 🤞

In any case, I'll definitely keep you posted on any progress... Hopefully soon! 😅
Thanks again @ressa!

ressa’s picture

ressa
he/him
commented

Awesome @dydave, it's great to see all the activity, following along from the side line, thanks for your great efforts!

And yes, I got a few mails yesterday :) But the current set up already inundates us with extra "time to give credit"-mail for all issues, or "Drupal 12 readiness"-alerts so I think we all have become experts in keeping the inbox under control, heh.

It sounds great with the transfer of name space, I wasn't exactly sure what it meant (as seen in my comment, where it's a bit jumbled up), so great that it can be sorted out. I thought about making an issue to clarify exactly which steps are needed, so it can be added to the https://www.drupal.org/about/core/policies/core-change-policies/how-to-d... doc page. But then I checked the #3158669: [policy, no patch] By default deprecate non-experimental modules that are used by less 5% of sites before the next major version issue, and it looks like most of the deprecations have happened already ... or maybe there are just as many in the pipeline for Drupal 13? If you feel like it and have time, you could consider spending a few minutes, just to add the most basic required steps under "Create the contrib project with a stable release", in case it would help another green core-to-contrib maintainer in the future?

But altogether just great to see everything moving along, thanks @dydave!

ressa’s picture

ressa
he/him
commented

I am sorry to see all the required steps you have to discover bit by bit, because the core-to-contrib process is not documented in enough detail, and "look at these other deprecation issues" is often the best advice. I understand that these processes secure that nothing bad happens, and that no mistakes are made ...

But it would help a lot if there was a minimal checklist or something. It's too bad that an experienced Drupal module owner such as yourself, main maintainer of one of the most installed modules (Admin Toolbar) cannot consult the infrastructure documentation page section How to deprecate and remove an extension > Create the contrib project with a stable release and follow a checklist of tasks, to as easily as possible transfer ownership of a project, get the Composer namespace set up correctly, etc.

But great to see that there were constructive comments in the transfer-issue, and that the process is moving along! Hopefully it will get done before too long, fingers crossed🤞

dydave’s picture

dydave commented

Thanks @ressa... I got a bit annoyed yesterday when Alberto (@avpaderno) announced a 2 weeks cooldown period for the transfer of the namespace 😅

Luckily Conrad (@cmlara) gave me another exploitable idea which seemed to be exactly what we were looking for.... So I created another ticket specifically for the composer namespace:
Gitlab issue #3583683: Ensure that Toolbar does not get special core treatment

Let's see if this pays off 🤞😅
Looks like Alberto (@avpaderno) has already taken a look at the issue and tagged it as namespaceRequest. 👌

After jumping through all these hoops, I'll certainly be glad to take some time to document my concrete experience going through this deprecation process 👍

I suppose with a little bit of patience we should be able to get everything we need to keep moving forward.

Let's see how things go in the coming days.
Thanks again for your great help @ressa! 😊

ressa’s picture

ressa
he/him
commented
Issue summary: View changes

Hah, yes after the meteoric progress in the first 24 hours, running into a two week blocker would be a bucket of cold water! 🥶 Great to see that it was already tagged by @avpaderno, let's hope the Drupal infra team can take a look at it in due time. It looks like other core-to-contrib modules share the namespace challenge, like drupal/shortcut-shortcut and drupal/telephone-telephone (found via project_composer "ensure treatment" search).

Thank you very much @dydave, it sounds fantastic that you may have time to document the basic steps, since that could help new core-to-contrib maintainers a lot, preventing a lot of wasted time and frustration. The whole Drupal community would be very grateful, I certainly would!

PS. Adding a list of "Transfer Toolbar" issues in the Issue Summary, to have them in one place :)

ressa’s picture

ressa
he/him
commented
Issue summary: View changes

Clarify in the Issue Summary that "Transfer Toolbar tasks" are the current priority.

dydave’s picture

dydave commented

Thanks so much @ressa!

and YES indeed !! 😆
You've summarized very accurately the big cooldown I experienced during this process 🤣

YES, definitely : This is for sure an issue that should be encountered by most contributors during the deprecation process of core modules 😅
So for sure, I will help documenting and assisting others going through this process 👍

But overall, after thinking again about it... We're not really blocked on the AT side :
We "should" be able to proceed with the 4.x branch, at least for the early development stages: we could surely use the current namespace toolbar-toolbar ==> It should not be a problem to start making changes, developing and testing on Gitlab CI....
Then, down the road, once the namespace change has been made, we would only need to change the dependency in module's composer.json to finalize the merge requests and release.

I'll get started on 4.x dev branch and initial rounds of changes this week and the following, so we could at least start getting the module prepared, until the namespace change is in place.

I'll surely keep you posted on the progress for the D12 compatible release of Admin Toolbar. 👌
Thanks again for all your help and support! 🙏

ressa’s picture

ressa
he/him
commented

Heh, yes it was good that we didn't hit a road block!

And I guess you're right, that in the initial phase, using the wrong Composer name drupal/telephone-telephone is probably all right, so long as it doesn't drag out for too long, so too many people start actually using it. It may not be a big deal to switch Composer name in a project, but ideally it shouldn't be needed for too many users. I tried to nudge the drupal/telephone-telephone issue in project_composer, and I hope that maybe the person who looks at that issue can handle Toolbar at the same time?

Sounds fantastic that you plan to look at 4.x dev branch, and will share any interesting and relevant changes, I'll be ready for testing. Thank you so much @dydave!

ressa’s picture

ressa
he/him
commented
Issue summary: View changes

The project_composer Toolbar issue was a duplicate, and I updated the Issue Summary to use the original one: Ensure that Toolbar does not get special core treatment. See also #3579778: Removed modules should be included as a replace in composer.json and #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib.

dydave’s picture

dydave commented

Thanks @ressa!

I've been trying to get in as many issues as possible before creating the new 4.x branch, so we could have a 3.6.4 release with the latest fixes (D9 compatible), then copy the branch to 4.x and start making the D12 compatibility changes.

There's a pretty big one in this ticket #3385337-16: admin_toolbar_tools more than doubles number of queries needed during site-install degrading performance for which we could use some help testing and reviewing the changes, if you get a chance. 🙏

This could be a pretty big win with a significant performance improvement for the admin_toolbar_tools module. 👍

oh ... and not sure if you have seen this, but I have #3609437: Enable Gitlab CI security scans 👌
The builds on Gitlab CI will now check for any secrets/confidential information and run SAST (static code analysis) scans on all module files.

Feel free to ping me directly in any issue in the module queue, to attract my attention, if you would like to see anything in particular included in the upcoming releases. 👍

I'll keep digging in the issue queue to see what other issues could be folded in.
Thanks in advance! 😊