Description of the need
Currently, when you add a link to a menu via /admin/structure/menu/manage/menu_name/add?langcode=und, you choose the parent link via a drop-down selector, whose options include every possible parent link, including links in other menus.
Since you've just gone to this page to add/edit a link to/in this specific menu, it seems a bit odd to list links from all the other menus, too. "If I wanted to add a link to a different menu, I would have used 'add link' for that menu."
But there's a bigger problem if there are many menus; it's easy to get lost in the giant list when you're scrolling through a big menu. The admin bar alone adds lots of items to the select menu. For example, here's what the drop-down looks like when you're editing a link in the Account menu, which contains only two items:
On one of my sites, the organization has one or two events a year, and we create a new menu for each event for visitors to navigate through that event's pages (anywhere from 5 to 40 pages, i.e., 5 to 40 new menu links per event). And we don't throw away past events. So after several years, we've built up about 25 menus, and something like 2000 menu links in that selector to contend with when we're building up the next menu. It's very easy to get lost (especially since many of the menu links have similar names from year to year).
To deal with this, I wrote a small custom module that adds a separate selector for the "Parent menu" to the menu add/edit link form, so that admins can first select the menu, and then the "Parent link" selector only displays candidate parent links from that particular menu. It looks like this:
It was pretty simple to implement: a hook_form_FORM_ID_alter()
instantiation, plus an ajax callback to update the "Parent link" selector when the "Parent menu" is changed.
It occurs to me that this might be desirable default behavior for these two forms for others who don't want or need to see every possible menu link in the drop-down when they're trying to add or edit a link in a specific menu.
There's a couple of ways I could proceed from here. I'd like to get some feedback from people on the possibilities.
Submit a PR to change the core behavior to add the "Parent menu" selector for everyone.
Offer it as an option in core, via a "Menu settings" configuration checkbox (at admin/structure/menu/settings). That way the default behavior wouldn't change, but people could turn it on (at least, if they know to go look for the setting).
Don't change core, just make it a contrib module. (Currently it's custom.)
I'm happy to do any of the above, but there's two drawbacks to making it a contrib module. First, it's a lot less discoverable. Second, in a contrib module, the alteration happens via a hook_*_alter()
, so after the original form is fully built, which means that one is still constructing the list of all possible menu links before replacing it with the more narrowly targeted list—so, a bit inefficient.
What do people think? Is this worth putting into core? If folks are in favor, I'm happy to provide the PR.
Recent comments
It is an admin theme that's based upon the bootstrap 3. Maybe it's missing a piece to act as an admin theme?
Add blocks filtering problem
Thank you, Martin and Olaf! I had a feeling that there might be something out there already :) I will check all three options (I will look at porting modules) and report back which one...
Filter by text in "message" in /admin/reports/dblog
The Views Watchdog module for Backdrop "extends the Views module and allows to create custom lists of log entries". On Github, there is also a Wiki page with information about available fields,...
Filter by text in "message" in /admin/reports/dblog