[policy, no patch] Move Settings Tray to a contributed project

+1 if anyone can maintain it

Yes the off canvas logic was factored out of this a long time ago, and this only handles blocks + contextual links. I've never seen it used on any site I've worked on, and not sure I've even tried it out myself.

I think I can go ahead and remove the framework manager review tag as well so doing that.

For transparency, can we get some background on why would we remove the module instead of getting it to integrate with navigation module?

I don't have a strong opinion on this being removed but just would like to have a little documented rationale for it. As with @catch, I'm not aware of this being used much on live sites - I guess if it's not enabled by core in the Standard profile many won't go as far as enabling it.

We don't think it is widely used, and the functionality it provides is limited. For most blocks it allows you to change the title, for views blocks you can additionally change the number of displayed items. For anything else, there is a link to the normal block editing page (which is accessible via the contextual menu without settings tray).

It currently doesn't work as designed with Navigation installed, even if Toolbar is also installed. I also couldn't get it to work without Toolbar. In both cases the contextual link appears but it just opens the form as a full page instead of the tray (which is even more confusing!)

I think the original idea was that the functionality would be expanded over time so you could change more block settings, or that contrib would use it to provide additional options in the off-canvas tray, but these have not materialised. Other than ongoing maintenance to keep up with the rest of core there has been little work done on it since #2762505: Introduce "outside in" quick edit pattern to core. It was somewhat based on the Quick Edit pattern, and Quick Edit itself was removed from core some time ago.

Settings tray was originally added alongside quickedit. Quickedit was supposed to provide in-place editing of content while settings tray was meant to provide close-to-in-place editing of config. However it was very minimally implemented and never expanded. The menu item to launch it was even named Quick Edit :D But quick edit itself was removed from core over 3 years ago.

See https://www.drupal.org/documentation/modules/settings_tray/using-the-set...

With Canvas supporting global block placement (and configuration) and no current effort to expand Settings Tray, I think this makes total sense to remove.

On top of #6 Layout builder opens block settings in the off canvas tray, but this doesn't rely on settings tray, it uses off canvas directly.

We also have https://www.drupal.org/project/display_builder and https://www.drupal.org/project/canvas in contrib that can completely replace the core block UI. The most likely thing to happen to the core block UI is that it gets removed/replaced in favour of the contrib page builders at some point. #2924058: Discuss using Layout Builder to control full site layout and replace Block UI never happened but that was the plan ten years ago.

So what is the work this is needed here? Just removal of the module? Any transitional work needed?

Do we have the capability of scanning all contributed modules to see if anything is depending on settings_tray? (I have no idea why they would).

If we could run a command on a folder containing all drupal modules it would probably find that answer quickly.

@cosmicdreams there is an established process for deprecating and removing modules from core.

The main two at this stage:
1. Get comments / signoff from the subsystem maintainers which are you and mark
2. Find people willing to maintain it in contrib, doesn't have to be you guys, but certainly can be

@cosmicdreams https://search.tresbien.tech/search?q=settings_tray&num=1000&ctx=0 - I don't see much relevant there except support for Settings Tray in gin, menu_block, menu_block_override and maybe one or two more modules, but nothing seems to build on any API that it provides.

After this conversation, I don't see a future for Setting Tray in core, so happy to sign off on it being moved to contrib.

Would you want to maintain it?

I could offer to maintain it for a while. But to be honest, I have little interest in maintaining long term as I only have few scenarios where I use it. And if it's getting cut out of core, I'll have even less. Maybe zero scenarios where I'll be using it.

It's been fun to practice my contribution project.

So I'll want to complete the work I've started:
* Removing jQuery support
* Implementing simplier solutions
* Modern CSS.

I can offer a year of support.

@longwave, what a wonderful tool you have there. I've always wanted something like this to exist.

@cosmicdreams that's very reasonable, it's fine to immediately advertise for co-maintsiners. Settings tray doesn't store any data and is admin facing so even if no one wanted to maintain it after a year sites could safely uninstall (unlike an entity or field providing module etc.)

@cosmicdreams we have @nod_ to thank for that search tool, it's been really useful and much more effective than GitLab's own search.

I'm happy to sign up as co-maintainer for a year as well. I don't think I have any sites using it, but would be good to have a smooth transition from core to contrib for the module.

I note that we haven't announced the removal of settings tray (like we have for the contact module). Is there a plan on when we'll announce it?

@cosmicdreams: Could it be because it is a 11.5.0 release priority? At one point I thought that all the 11 Drupal core modules listed under "Modules" in #3466088: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 12 core would be removed in Drupal 11.4.0, but Search, Settings Tray, Shortcut, Telephone, and Toolbar are tagged with 11.5.0 release priority, in December 2026.