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
Why not insert the script using a custom block at the very top of the page, <header>? Who said that it won't work correctly if you don't place it in the <head>? Especially...
Google tag and event snippet on the conversion page
You can use https://statichost.host for hassle free static experience.
Generate a Static Site
that was the first thing i tried, but thanks. i cannot see css file changes without clearing the css/js cache. for that reason i have been adding css snippets (<style> tags) into my...
Bandwidth optimization settings