Opened 8 years ago
Last modified 8 years ago
#38957 new enhancement
Customize Menus: Menu locations should be able to opt-out of menu item types that can be added to associated menus
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Future Release | Priority: | normal |
| Severity: | normal | Version: | 4.3 |
| Component: | Customize | Keywords: | needs-patch |
| Focuses: | Cc: |
Description
Certain menu locations are often designed to use a particular type of menu item - for example, social menus only make sense with custom links, or a custom nav menu walker may be used to display a deeper index of posts within taxonomy terms featured in a menu location.
If themes could specify what types of content a particular menu location is intended to contain, the menus UI could correspondingly show/hide or prioritize the types of menu items in the available menu items panel. This should be handled with the object and object_type menu item parameters.
As with #38956, this is difficult due to the current way the menu locations API works, and the fact that menus can be added to multiple locations. This should be considered a usability enhancement that is more conservative in hiding available menu items for items in multiple locations, and that adapts as menu locations are changed.
We'll also need to think about how the UX for this should work. I'm thinking that the available menu items panel would change based on the properties of the current menu's assigned location (if any). If a menu with unsupported types is assigned to a new location, there could be a warning That the current menu's location doesn't support some of the types already in the menu, or there could be a warning on each item in the menu that won't show up in the preview, explaining why.