WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 7 months ago

#18584 new enhancement

Nav menu UI needs more hooks — at Version 47

Reported by: Viper007Bond Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.3
Component: Customize Keywords: has-patch
Focuses: javascript Cc:
PR Number:

Description (last modified by westonruter)

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.

Change History (49)

#2 @markoheijnen
8 years ago

  • Cc marko@… added

@ddean
8 years ago

nav menu hooks proposal

#3 @sirzooro
8 years ago

  • Cc sirzooro added

#4 @Viper007Bond
8 years ago

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

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

Last edited 8 years ago by Viper007Bond (previous) (diff)

#5 @ddean
8 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

#6 @toscho
8 years ago

  • Cc info@… added

#7 @helgatheviking
7 years ago

  • Cc helgatheviking@… added

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.

#8 @DrewAPicture
7 years ago

  • Cc xoodrew@… added

@DrewAPicture
7 years ago

#9 @DrewAPicture
7 years ago

  • Keywords 3.6-menus added
  • Milestone changed from Awaiting Review to 3.6

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.

Last edited 7 years ago by DrewAPicture (previous) (diff)

#10 @helen
7 years ago

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

#11 @DrewAPicture
7 years ago

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

#12 @SergeyBiryukov
7 years ago

#21898 was marked as a duplicate.

#13 @Chouby
7 years ago

  • Cc frederic.demarle@… added

#14 @Chouby
7 years ago

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);

#15 @DrewAPicture
7 years ago

  • Keywords 3.6-menus removed

#16 @DrewAPicture
7 years ago

#23741 was marked as a duplicate.

#17 @DrewAPicture
7 years ago

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

#18 @mordauk
7 years ago

  • Cc pippin@… added

#19 @helgatheviking
7 years ago

Is this going to make it into 3.6?

#20 @greenshady
7 years ago

  • Cc justin@… added

#21 @ocean90
7 years ago

  • Milestone changed from 3.6 to Future Release

#22 @SergeyBiryukov
6 years ago

#24652 was marked as a duplicate.

#23 @shrkey
6 years ago

  • Cc shrkey added

#24 @stephenharris
6 years ago

  • Cc contact@… added

#25 @helgatheviking
6 years ago

any chance for 3.8?

#26 @markoheijnen
6 years ago

  • Keywords 3.9-early added

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

#28 @Faison
6 years ago

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

#29 @enollo
6 years ago

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

#30 follow-ups: @helgatheviking
6 years ago

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?

#31 in reply to: ↑ 30 @Faison
6 years ago

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!

#32 in reply to: ↑ 30 @enollo
6 years ago

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.

#33 @Viper007Bond
6 years ago

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.

#34 @helgatheviking
6 years ago

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.

#35 follow-up: @dnavarrojr
6 years ago

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

#36 in reply to: ↑ 35 @helen
6 years ago

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.

#37 follow-up: @helgatheviking
5 years ago

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.

#38 @DrewAPicture
5 years ago

#28771 was marked as a duplicate.

#39 @DrewAPicture
5 years ago

#29854 was marked as a duplicate.

#40 @DrewAPicture
5 years ago

#18527 was marked as a duplicate.

#41 @helen
5 years ago

#14414 was marked as a duplicate.

#42 follow-up: @zedd45
5 years ago

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.

#43 in reply to: ↑ 42 @rtpHarry
5 years ago

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/

#44 in reply to: ↑ 37 @rtpHarry
5 years ago

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/

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


4 years ago

This ticket was mentioned in Slack in #core-customize by sheri. View the logs.


4 years ago

#47 @westonruter
4 years ago

  • Component changed from Menus to Customize
  • Description modified (diff)
  • Focuses javascript added
  • Keywords needs-patch added; has-patch needs-testing 3.9-early removed
  • Milestone changed from Future Release to 4.4
  • Priority changed from low to normal
  • Severity changed from minor to normal

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.

Note: See TracTickets for help on using tickets.