backdrop
[UX] Reduce the size of the potentially unwieldy parent link selector on content type and content edit pages
This is a follow-on to https://github.com/backdrop/backdrop-issues/issues/6390. In that issue, on the menu add/edit link page, the "Parent link" selector contains almost all possible menu items, and so is large and unwieldy. That issue solved the problem by adding a separate selector to choose the menu, and then the 'Parent link" selector only contains choices from that menu.
It was requested there by @klonos:
...also, can we please extend the scope of this to also add the same behavior in the "Menu settings" vertical tab of content types as well as the content edit form? (when more than one menu has been configured to be available for a content type)
@bugfolder replied:
It looks like the vertical tab of content types already has this behavior (or perhaps I'm misunderstanding what you're talking about). Here's the content type edit page with two menus selected, and only those two menus' items are being shown in the default parent link:
And here's the content edit form, which shows the same thing:
@klonos replied:
...perhaps I didn't provide enough information to make it clear. If you enable all checkboxes for all available menus, including the admin menu, then the parent menu selection becomes unwieldy again.
So OK, allowing content links to be added to the admin bar is an edge case, however I used the admin menu as an out-of-the-box example which is easy to test. You could generate a fresh, rather huge menu with devel (or a few smaller menus and enable all of them). Then the problem we are trying to solve here is present in the content type configuration form, as well as the content edit form.
We'll continue the discussion from here.
It's not yet clear to me what the desired behavior would be. Looking at the content type vtab (first example above), although one may check multiple menus, one can only select a single "Default parent item". What would be the desired UI for that selection?
On the content edit page (second example), I could envision having radio buttons for the allowed menus, and then the parent item selector is limited to just the entries of the selected menu.
Having pondered this a bit, I can see having the same UI for content types and content edit vtabs for selecting the (default) parent item. (And it's a bit different from what we're doing in #6390).
- For content types, we keep the checkboxes to choose which menus to allow.
- Below that (on content types) and for "Parent item" (on content edit), we have both
- radio buttons for the allowed menu(s),
- a selector listing only the menu items of the selected radio button.
How's that sound?
Doi. Of course, use a select for the menu here, too:
Logic is a bit different from #6390 due to it being a subset of all menus and different default values for the form elements.
In the PR for #6390 the labels are:
- Menu
- Parent link
In the screenshot here we have:
- Default menu for parent item
- Default parent item
Should we align the labels more with the other PR instead? For instance:
- Default menu
- Default parent link
I did some quick testing of this PR with the menu_link_weight module, and unfortunately, this change breaks it, unless the "Parent item" dropdown is toggled.
If a menu just hasn't any items yet, or if people choose to stick with top level, menu_link_weight can't update its values accordingly, resulting in wrong parent/child relation.
But I see a real improvement in this change. Maybe we can make it more compatible with existing hook_form_alter implementations (as menu_link_weight does)? It's a huge change, though, not sure, how to make it less ... dangerous. :wink: Or if backwards compatibility is possible in this case.
There are lots of modules altering the node form (and possibly relying on a certain structure), but we might also want to check, whether menu_views, auto_menu_settings or content_menu are affected as well.
Thanks, @indigoxela, for pointing out those modules and the (real/potential) B/C issues. I'll work on improviing the B/C, using those modules for further checking.
Looks like there is consensus on the main menu setting for adding a menu selector, so the same setting could be used here as well.
(Aside: I wonder if Menu Link Weight is a good candidate for core. It's a small UI improvement that most people would find useful. Maybe it would just need a toggle on a content type to use the old weight field instead if there are lots of menu items.)
How does the merging of https://github.com/backdrop/backdrop-issues/issues/6390 impact this issue?
How does the merging of https://github.com/backdrop/backdrop-issues/issues/6390 impact this issue?
@docwilmot's JS magic on 6390 provides a good example for an improved approach to this one.
@bugfolder So, it sounds like this one possibly needs a new PR based upon the new approach provided by @docwilmot in #6390.
As a reminder, that issue made it possible to select a parent link when creating a new menu item directly to a menu. This issue would add that same option (I think) to the vertical tab in node or content type edit forms.