Customize Menus: Menu locations should be able to opt-out of menu item types that can be added to associated menus

[celloexpressions]

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.

[celloexpressions]

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.

[oleksiitsioma]

Hello @celloexpressions. This is a very old ticket, but I would like to take a peak. 4.3.1 is definitely extremely outdated, but looking at how this works in the current WordPress version still makes sense.

[sukhendu2002]

I reviewed this against current trunk. The enhancement is still relevant for the classic Customizer menu interface. Menu locations still store only descriptions, available item types are global, and the browse/search AJAX handlers receive no menu-location context. The Customizer JavaScript tracks each menu's assigned locations, but does not use them to adjust the available-items panel.

An implementation should preserve the existing get_registered_nav_menus() location-to-description return shape, since it has many existing consumers. Location rules would need separate metadata, passed to the Customizer and applied consistently to item-type sections, search results, Custom Links, and live location-assignment changes. Existing incompatible menu items should be warned about rather than removed.

The main blockers are design decisions: how restrictions combine when a menu has multiple locations, what happens for unassigned menus, whether rules are advisory or enforced, and whether the API uses an allowlist, denylist, or prioritization. I did not prepare a patch because these semantics need agreement first; needs-design would be appropriate before implementation.