Navigation: consider honoring customize_nav_menu_available_items and customize_nav_menu_available_item_types filters

[Aljullu]

Some plugins use the customize_nav_menu_available_items and customize_nav_menu_available_item_types filters, to allow users to add custom navigation items which are not associated to any post type or taxonomy.

Usecase

For example, WooCommerce uses those filters to include links to endpoints which are not posts or taxonomies, like the logout page or specific sections inside the My Account page.

This is how it works in WooCommerce, but via GitHub search I found other plugins that use these filters in the same way.

About the filters

Documentation can be found in these two pages:

• customize_nav_menu_available_items
• customize_nav_menu_available_item_types

There was an initial audit of several filters and how they are supported in the navigation screen in #23739, but I think these two were excluded because they are currently only used in the customizer.

Implementation idea

While these filters allow completely modifying all available menu items, a pattern I found in several plugins is to use them to add new menu item types (see Usecase section above). The idea is that these filters would no longer be used to modify/remove menu items, but they could still be used to add new menu item types.

An example implementation could work as follows:

• Run the customize_nav_menu_available_item_types filter with an empty array as the initial value. This way plugins can add new item types but not modify existing ones given that this is not supported.
• Create a new Navigation Link block variation for each type returned by that filter.
• Once one of those Navigation Link block variations is inserted, run the customize_nav_menu_available_items filter to know the items which are available for that specific type.

Alternatives

If we decide not to go forward with this idea, there are two other alternatives that plugins that used those filters to add menu item types can pursue:

• Create a Navigation Link block variation specific to the endpoints the plugin is adding. This is the most straight-forward idea and the only one that is currently possible but it means each plugin that uses those filters will need to do the same to keep feature-parity between the legacy navigation screen and the new one.
• Another alternative would be to allow plugins to filter the result lists which appear in the Page Link link control. Following the WC example, instead of having a specific WooCommerce endpoints block variation, all those endpoints would be listed as if they were pages when inserting the Page Link. That's something I experimented a bit with, but it requires hooking into the Rest API responses, which make it a bit brittle because it's difficult to only target Page Link API requests.

[Thelmachido]

This was labeled as the Navigation Screen however one of the solutions was to create Navigation Link Block. We currently have the navigation block, maybe the work can be continued there.

The Navigation Screen project is being moved to an inactive status on the feature projects page in coordination with the project leads. I will close this issue for now, if this needs to be kept open please feel free to do so.