The proposed filters are great to add some new custom fields but they don't permit to create fully customized menu items.

What I would like to do is to create a group of menu items, more or less the way done by Viper007Bond in his plugin (one "group" item on backend, several items on frontend). In his case keeping the existing navigation label, title attribute and so on makes sense because the plugin has one and only one top level item. But if we want a plugin beeing able to create a group of several top level items, these fields do not make sense anymore.

So we should be able to completely customize the output of the walker (I know it is already possible by deriving a new class, but as mentionned by helgatheviking it leads to plugin conflicts).

So the easiest way I can propose is to filter the whole output at the end of the start_el function with something like:

I would like to add that my plugin would greatly benefit from this: ​Navception

Right now when you expand a Submenu Menu Item, you see the default menu item fields which aren't helpful for a submenu menu item. As I brought up in #12934, related to my plugin as well as for adding submenu items into core, it would be more useful to show a list of the links contained in that submenu rather than the Menu Label and Title Attribute.

So this is my +1 as well as request for full control over the menu item blocks.

I agree! There are at least 3 plugins just in this thread that can't work together without a hook. However, Helen mentioned #14134 is possibly holding this up, because adding a do_action() hook is pretty straight-forward. #14134 is 4 years old though, can we get menus to the forefront for 4.0?

Oddly I have never encountered the issue described in that ticket and I have dealt with some mega large menus.

Has anyone tested the most recent patch with their plugins? I'd be happy to test any plugins that utilize the proposed action hooks. I'm working on a site now that has a menu with 39 items. It would be the perfect test environment :). I can even try it out on a popular shared host to see if any issues pop up with saving the menu items.

The only issue I've run into with large menus is that the POST size gets too large. That's something that was fairly easy to have happen. We often had to do a workaround of disabling JavaScript and using the manual up/down arrows to move around menu items.

I too have run into the $_POST getting huge and failing. I've had menu items completely cut out of the menu as a result. How do we trim/optimize the $_POST size? One of the suggestions was to ajax save every item (à la Widgets) but I'm not sure that is the best approach.

Then I am adding my custom fields to this hook. If we all do this in our plugins (those of us with plugins that rely on replacing the wp_edit_nav_menu_walker) then our plugins can play together. People will just have to run the risk of hitting the $_POST limit... a risk they are already taking now. If this hook is ever added to core, the plugins should seamless be forward-compatible.

Then I am adding my custom fields to this hook. If we all do this in our plugins (those of us with plugins that rely on replacing the wp_edit_nav_menu_walker) then our plugins can play together. People will just have to run the risk of hitting the $_POST limit... a risk they are already taking now. If this hook is ever added to core, the plugins should seamless be forward-compatible.

FYI: Original blog is gone but you can still get a copy of this in the wayback machine:

I'm re-scoping this in terms of Menu Customizer which was added in 4.3 but also without all of the necessary hooks to be extensible for plugins to easily add new controls. The latest work there was done in #32832 and #32708.

In any case, adding new menu item types and adding fields to existing menu item types should ideally have the same interface whether the extensions are targeting the menus in the customizer or menus on the admin page. Maybe this isn't realistic, but at least there should be parity between the two. I know this also gets into Fields API territory.

On #32832 (comment 16), I put down some thoughts on what needed to be done for menus in the Customizer:

Extend WP_Customize_Nav_Menu_Item_Setting::value() to allow plugins to amend the normal value with additional properties, where the filter can draw the properties from postmeta.

Allow for custom fields to be inserted into WP_Customize_Nav_Menu_Item_Control::content_template().

Allow custom fields to be linked to the new properties in the nav_menu_item setting value, using a similar approach to the link method, although again here we're dealing with sub-properties of a setting, not entire setting value itself.

Extend WP_Customize_Nav_Menu_Item_Setting::value_as_wp_post_nav_menu_item() to amend the returned WP_Post object with the additional properties.

Extend WP_Customize_Nav_Menu_Item_Control::sanitize() to allow the amended values to be sanitized.

Extend WP_Customize_Nav_Menu_Item_Setting::update() to allow the amended values to be persisted (in postmeta)

I also put forth an assumption that the data source for any menu item custom fields should be sourced from postmeta.

This remains blocked for the admin page due to fundamental scaling problems there (#14134). It would need a complete refactoring to be able to support this. Therefore, I'd suggest focusing on the Customizer implementation.

At this point, we need help from anyone who is interested in using these hooks to move forward with adding support for custom fields in nav menu item controls. I would second the assumption that postmeta should be used and that custom fields for nav menu items is the use-case supporting hooks in nav menu item controls, but if there are other opinions, I'd be interested in seeing those.

What kind of help do you need to move forward? I know we're supposed to be learning Javascript deeply this year, but I'm not there yet.

Here's a screenshot of what I am doing in the admin:

So in the Customizer I'd like to do a similar thing, adding the first row of radio buttons. And the radio buttons toggling the display of the checkboxes below as they are only needed if the "logged in" radio is selected. The whole thing is saved as 1 post meta field.

What kind of help do you need to move forward? I know we're supposed to be learning Javascript deeply this year, but I'm not there yet.
[…]
So in the Customizer I'd like to do a similar thing, adding the first row of radio buttons. And the radio buttons toggling the display of the checkboxes below as they are only needed if the "logged in" radio is selected. The whole thing is saved as 1 post meta field.

Please share the plugin codebase you're using to extend the nav menu on the admin page. I'll try to prototype what you've implemented there for nav menus in the Customizer.

Is that action hook enough to do something functional, though? That's a start but we also need to make sure that there's a way to save values from any inputs added with that hook. The best option for developers would probably be to automatically save things here based on the input name, but that could make sanitization difficult. May be worth waiting for the Fields API, and trying to integrate that here, not sure.

For me, I can confirm that 1 hook in the Walker would be enough for my plugin. There is *already* the wp_update_nav_menu_item action that is fired when the item is saved, which I am using to sanitize and save my meta.

A handful of plugin authors got tired of waiting for this ticket so we agreed on a hook name, and added our own action hook so that no matter who's Walker gets served our plugins could play together. I don't want to speak for everyone else, but that's what I'm looking for from core.

How about a filter instead of an action? See 18584.2.diff​ which adds a wp_nav_menu_item_fields filter for the fields that are output both in the walker for a specific nav menu item on the nav menus admin page and for the JS template for a nav menu item control in the Customizer. It also introduces a wp_nav_menu_manage_columns filter for manipulating which fields appear in the advanced menu properties in Screen Options. The patch here builds upon #35273. The facility here allows existing fields to be easily removed as well as to allow new ones to be added.

I believe there are still missing pieces here, like hooking up the display to toggle displaying the fields based on whether the column checkbox is checked for any additional fields added. Also, the fields here would be dummy fields without the corresponding PHP logic (for admin menus page) or JS logic (for Customizer) to actually handle the rendering of the values and persisting of the values.

This patch is a WIP. I didn't closely examine the existing patches, but I wanted to see something that would also facilitate extending the Customizer. Please anyone iterate on it.

Hi @westonruter, I don't completely understand the benefit of using a filter here in lieu of an action hook. Could you elaborate a little more on your thinking here?

How important are the screen options and display toggle? If you've added a plugin that is meant to show the meta fields it seems like you'd be unlikely to want to hide them. Just my thought, though if it doesn't hold up getting this resolved I'm certainly not opposed to it.

Hi @westonruter, I don't completely understand the benefit of using a filter here in lieu of an action hook. Could you elaborate a little more on your thinking here?

The benefit of a filter is that existing fields can be removed or modified, in addition to new fields being added. With an action, you can only inject new fields at the end. A filter seems to be more flexible.

How important are the screen options and display toggle? If you've added a plugin that is meant to show the meta fields it seems like you'd be unlikely to want to hide them. Just my thought, though if it doesn't hold up getting this resolved I'm certainly not opposed to it.

The benefit of a filter is that existing fields can be removed or modified, in addition to new fields being added. With an action, you can only inject new fields at the end. A filter seems to be more flexible.

Is it really a good idea to let someone remove the core fields like menu title? Or is this a case of if you remove the title you deserve what you get? :) I should try out your .diff to see if I can't add my fields via the filters, but it'll probably take me a while to get to it (and other while to remember who to apply diffs).

@westonruter
I started testing the trac-18584 branch of your github repository. For me, this makes the admin menu page fully functionnal. I used the new filter 'wp_nav_menu_item_fields' to remove all default WP fields, add my own fields and populate them. This replaces efficiently the js hack that I currently use to obtain the same result. To save the fields, your current patch did not require any change to my 'wp_update_nav_menu_item' filter.

The "dummy" fields correctly appear in the customizer. I am ready for further tests when you'll provide a way to populate the fields and save them.

I would like to see this implemented in the core aswell.
At this point I use the same method as Chouby (js hack).
It would be a huge improvement for consistency and stability if we can use core hooks to alter the menu items.

I think the proposal (#comment:64) of @westonruter for using a filter instead of an action would be a great.
Appart from removing existing fields you can even change the order of fields by using a filter.

Finally getting around to reviewing @westonruter's patch, I think this approach works pretty well (using a filter). As I just noted on github, there will need to be a separate filter for the customizer as the html there is a JS template, which will most likely be different from what you would put for the admin page.

My main concern with completing the patch is that the saving process should be as automatic for developers as possible in both places (and also previewing for the customizer). In addition to the items noted in 64.

Looking at WP_Customize_Nav_Menus::available_items_template() there seems to be no way to create additional menu items. In the admin area I can use add_meta_box() to define a new menu item. I am working to create a new menu item which is line break and a title.

Note that this plugin has two separate plugins embedded within it: “Customize Nav Menu Item Custom Fields” and “Customize Nav Menu Item Custom Field Examples”. The latter includes an example that adds a basic implementation of @helgatheviking's Nav Menu Roles plugin (allowing a nav menu item's display to be conditional based on whether a user is logged-in, logged-out, or if it should be shown for anyone.) You'll note that, being that the customizer is a JavaScript application, the integration here looks very different than how custom fields might currently be integrated with nav menu items in the nav menus admin page. The integration relies primarily on JavaScript events rather than PHP actions and filters. Example: ​https://github.com/xwp/wp-customize-nav-menu-item-custom-fields/tree/master/examples/user-visibility

Note that since custom fields for nav menu items are postmeta, this feature plugin depends on Customize Posts which implements the necessary interface to represent postmeta in the customizer. You'll have to use the current develop branch to test the plugin: ​https://github.com/xwp/wp-customize-posts

There is one key limitation currently with the plugin: it isn't possible to manage custom fields for newly-added nav menu items that haven't been saved yet. This is due to how we're using placeholder IDs as opposed to actual IDs, and postmeta aren't able to work with such placeholder IDs in core currently. For more on this, see #38072.

I was really disappointed to find that 6 years old ticket is still not resolved, with regularly moved milestone. Recently I was in need to create an image based front page menu with manual cropping. I had to base it on my custom post type, prepare the whole customizer structure and finally can use WP_Customize_Cropped_Image_Control to allow users manual cropping to required size. And still, have to prepare management of items hierarchies.

It would be highly appreciated to finally allow customizing nav_menu_items with custom metadata, one of which is definitely managing related thumbnail_id with WP_Customize_Cropped_Image_Control. By the way for consistent user experience cropped image control should be useable also in regural wp-admin pages, not only in customzier.