Nav menu UI needs more hooks

[Viper007Bond]

I'm trying to add some additional fields to the nav menu blocks but sadly there are no hooks for doing so. Zero.

We should add some and get in a better habit of just doing so when the code is written.

My specific suggestions are before the Remove/Cancel links (i.e. for adding standard stuff), one above the "original" field, and one after those action links (to add more actions).

We need to account for both extending the menus admin page and menus in the customizer.

[ocean90]

Related: #18527, #16738, #14414, #16691

[ddean]

nav menu hooks proposal

[Viper007Bond]

This is the plugin I was working on and my use case:

​http://wordpress.org/extend/plugins/add-descendants-as-submenu-items/

[helgatheviking]

I need this hook for my plugin as well:
​http://wordpress.org/extend/plugins/nav-menu-roles/

Right now a user cannot use my plugin in conjunction with @Viper007Bond's because we're both required to use a custom walker instead of simply adding our fields to a hook.

[DrewAPicture]

18584.diff​ removes the filter (handled in ticket:16738:16738.3.diff​) and also adds a couple of actions to the overall menu editor.

Lets see if we can't get some of these in, especially in light of the 3.6-menus refresh.

[helen]

Nacin noted that issues like #14134 stand in the way of making adding more fields a really good idea.

[DrewAPicture]

The menu item link attributes filter proposed in the first patch was added in [23565].

[SergeyBiryukov]

#21898 was marked as a duplicate.

[Chouby]

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:

$output .= ob_get_clean();
$output = apply_filters('walker_nav_menu_edit', $output, $item, $depth, $args);

[DrewAPicture]

#23741 was marked as a duplicate.

[DrewAPicture]

@Chouby's proposed hooks for back-compat-ish with the locations settings from #23741: ticket:23741:23741.diff​

[helgatheviking]

Is this going to make it into 3.6?

[SergeyBiryukov]

#24652 was marked as a duplicate.

[helgatheviking]

any chance for 3.8?

[markoheijnen]

That a bit to late since 3.8 will be released this week. Let's see what we can do for 3.9

[SergeyBiryukov]

Related: #27066

[Faison]

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.

Thanks,
Faison

[enollo]

It doesn't look like this is making it into 3.9
Any chance we can mark this for 4.0?

There are some really great menu plugins out there and it would be great if users can use them together :)
Not to mention the possibilities for devs

[helgatheviking]

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?

[Faison]

Replying to helgatheviking:

... can we get menus to the forefront for 4.0?

I would definitely be willing to spend much of my free time helping that cause!

[enollo]

Replying to helgatheviking:

#14134 is possibly holding this up

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.

[Viper007Bond]

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.

[helgatheviking]

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.

[dnavarrojr]

Any chance this will be addressed in 4.0? Or is the can being kicked down the road again?

[helen]

Replying to dnavarrojr:

Any chance this will be addressed in 4.0? Or is the can being kicked down the road again?

Nothing's really changed since I noted limitation concerns in 10. That said, it's possible celloexpressions might come up with a way that gets us past the $_POST problem in his GSOC project.

[helgatheviking]

In the meantime, per @Shazdeh's very neat suggestion at:
​http://shazdeh.me/2014/06/25/custom-fields-nav-menu-items/

I am modifying the Walker in my plugin to only add the following action hook right after the description input:

<?php 
// This is the added section
do_action( 'wp_nav_menu_item_custom_fields', $item_id, $item, $depth, $args );
// end added section 
?>

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.

[DrewAPicture]

#28771 was marked as a duplicate.

[DrewAPicture]

#29854 was marked as a duplicate.

[DrewAPicture]

#18527 was marked as a duplicate.

[helen]

#14414 was marked as a duplicate.

[zedd45]

I'm taking @helgatheviking's suggestion. Thanks for the idea! (The link to @Shazdeh's article is currently broken (404) btw.)

I can't believe something this fundamental is such a low priority, especially considering the number of duplicate tickets that have been opened, or the fact this is still outstanding for three years.

[rtpHarry]

Replying to zedd45:

I'm taking @helgatheviking's suggestion. Thanks for the idea! (The link to @Shazdeh's article is currently broken (404) btw.)

I can't believe something this fundamental is such a low priority, especially considering the number of duplicate tickets that have been opened, or the fact this is still outstanding for three years.

FYI: you can get to that article still through the wayback machine:

​https://web.archive.org/web/20140714053731/http://shazdeh.me/2014/06/25/custom-fields-nav-menu-items/

[rtpHarry]

Replying to helgatheviking:

In the meantime, per @Shazdeh's very neat suggestion at:
​http://shazdeh.me/2014/06/25/custom-fields-nav-menu-items/

I am modifying the Walker in my plugin to only add the following action hook right after the description input:

<?php 
// This is the added section
do_action( 'wp_nav_menu_item_custom_fields', $item_id, $item, $depth, $args );
// end added section 
?>

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:

​https://web.archive.org/web/20140714053731/http://shazdeh.me/2014/06/25/custom-fields-nav-menu-items/

[westonruter]

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.