Nav Menu Edit Walker per menu item type, not menu?

[GaryJ]

The assignment of a walker to show the menu items on the right side of the Menus screen is set per menu in wp_get_nav_menu_to_edit().

Ideally, it could be overridden per menu item type. That is, posttype, custom and taxonomy menu items can be handled by Walker_Nav_Menu_Edit, while a menu item (in the same menu) or 'foobar' can be handled by the start_el() from a different walker.

As things stand, I'd have to extend Walker_Nav_Menu_Edit, copy start_el(), and place the conditional code for what to output in there (in my case, strip out fields that aren't ever going to be used in my 'foobar' menu item type).

[GaryJ]

Alternatively, Walker_Nav_Menu_Edit::start_el() needs to have a filter before or around the existing markup, which passes through the $item including menu item type, so it can be replaced with something custom.

[SergeyBiryukov]

Related: #23805

[bendoh]

Patch to add (pre_)nav_menu_edit_item filters

[bendoh]

Bumping this.

Currently there's no great way to add or remove fields from custom nav item types other than by (as the ticket says) copying / extending Walker_Nav_Menu_Edit, and adding logic there to add / remove the fields. But to do this, you must filter on wp_edit_nav_menu_walker and provide your own custom walker (wp-admin/includes/ajax-actions.php:960 w/ WP 3.7.1), but this isn't really stackable in any custom way, since another plugin or theme might offer a different class name for this class and thus bypass any custom functionality offered by the custom Walker_Nav_Menu_Edit.

It'd be nice to be able to filter the markup before it's output, instead, since then multiple plugins could process this.

I've attached a patch against WP 3.7.1 (trac.23806.diff) that creates two new filters: 'pre_nav_menu_edit_item', which allows for plugins to provide a completely custom chunk of markup to use for the menu item editing; and 'nav_menu_edit_item', which allows for manipulation of the generated HTML that is about to be used.

[bgentry]

bendoh, I came across this post as I was thinking about the need to have some filters for adding fields to the nav menu item editing screens for the same reason you pointed out: when the only way to add fields is to make your own Walker_Nave_Menu_Edit, it is impossible for two plugins to add different fields to the screen.

In the approach you take in your trac ticket, developers need to write their own functions to save the fields they add, correct?

[bendoh]

Replying to bgentry:

bendoh, I came across this post as I was thinking about the need to have some filters for adding fields to the nav menu item editing screens for the same reason you pointed out: when the only way to add fields is to make your own Walker_Nave_Menu_Edit, it is impossible for two plugins to add different fields to the screen.

In the approach you take in your trac ticket, developers need to write their own functions to save the fields they add, correct?

Yes, this only allows for injection custom markup / form fields, but there are a variety of ways to save the values of the form fields that may be injected here and this patch does not attempt to address that in any automated way.

[chriscct7]

Closing as maybelater. Complete lack of interest on the feature on the ticket over the last 2 years. Feel free to reopen when more interest re-emerges (particularly if there's a patch)