[UX] Remove the menu settings page

[jenlampton]

I think the page at admin/structure/menu/settings is left over from Drupal 7, where we had ideas of a primary and secondary menu that needed to be specified.

In Backdrop, our menus are configured 1) in the header block or 2) by placing other menu blocks into a layout. I believe this page has no purpose anymore.

[klonos]

Yeah, the concept of specific "Main links" and "Secondary links" and their "source" menu is kinda awkward now with layouts and the way we place menus.

May I propose we do the same with menus (menu blocks actually) as what I propose in #1277 for custom text blocks:

1. Add a "Place in a layout" action (secondary drop-button item) on the menu list page.
2. Add a "Used in" column that shows layout(s)/region(s) where each menu is placed.
3. Add a "Create new menu" or "Create new menu block" (secondary) action in the layout admin UI. Upon menu creation, the menu is placed in the respective layout/region where the action was initiated from.

[jenlampton]

1. Add a "Place in a layout" action on the menu list page.

Maybe. How would you envision this working? Would it take you to the layouts listing page, or a specific layout? Does it just alter the list of "available blocks" to show only a single choice when you click the "add block"? This could be a bit of a technical challenge... I think it needs a lot more thought, and perhaps a demonstrable solution in contrib before anything like this goes into core.

1. Add a "Used in" column that shows layout(s)/region(s) where each menu is placed.

How do you envision handling selection criteria & visibility rules in this list?

1. Add a "Create new menu" or "Create new menu block" (secondary) action in the layout admin UI.

I'm conflicted about this, it sounds like a good idea, but it's a slippery slope. Should everything that provides a block also add a link in the layouts UI? I think this is just a concept people need to understand.

[klonos]

1. Add a "Place in a layout" action on the menu list page.

Maybe. How would you envision this working?

Same as it would work for what I propose for custom blocks in #1277. That is:

-> The "Place in a layout" action is a secondary link in the already existing drop-button
-> hit the "Place in a layout" action
-> "Select a Layout" page (or modal) appears
-> user selects a layout
-> user is taken to a "Select region" variation of the layout admin UI for the layout they selected in the previous step. This variation has "Place menu block here" buttons in each region instead of the usual "Add block" ones
-> user selects a region by hitting the "Place menu block here" button of a region and the menu block is placed in that region
-> the layout UI switches back to the "normal" mode where user can re-arrange blocks or add more

[klonos]

1. Add a "Used in" column that shows layout(s)/region(s) where each menu is placed.

How do you envision handling selection criteria & visibility rules in this list?

Nope, nothing like that. Only layout(s) and respective region(s) shown. These should be enough to give the user a simple overview. They could be a link to the layout edit UI for each layout, in which case If we want to show any extras (selection criteria & visibility rules), then we can have them in some sort of hover-over popup.

[klonos]

1. Add a "Create new menu" or "Create new menu block" (secondary) action in the layout admin UI.

I'm conflicted about this, it sounds like a good idea, but it's a slippery slope. Should everything that provides a block also add a link in the layouts UI?

The current "Add block" button can be converted to a drop-button with the primary action still being "Add block". All (any) other links can be secondary actions, so almost no UI bloating - just a down arrow next to the existing button. So, yes.

[jenlampton]

I dont see the admin/structure/menu/settings page...

[klonos]

You're not alone. File separate issues for the ideas above and close this one?

...although it would be good to know which commit/PR was the one that fixed this.

[klonos]

This was removed in #1514 with backdrop/backdrop@3b446eb#diff-15b51389caccadadb7393e0380c3b624