Make WordPress Core

Opened 4 years ago

Last modified 2 months ago

#18584 new enhancement

Nav menu UI needs more hooks

Reported by: Viper007Bond Owned by:
Milestone: Future Release Priority: low
Severity: minor Version: 3.3
Component: Menus Keywords: has-patch needs-testing 3.9-early
Focuses: Cc:


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

Attachments (2)

nav_menu.diff (2.2 KB) - added by ddean 4 years ago.
nav menu hooks proposal
18584.diff (2.0 KB) - added by DrewAPicture 2 years ago.

Download all attachments as: .zip

Change History (44)

comment:2 @markoheijnen4 years ago

  • Cc marko@… added

@ddean4 years ago

nav menu hooks proposal

comment:3 @sirzooro4 years ago

  • Cc sirzooro added

comment:4 @Viper007Bond3 years ago

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


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

comment:5 @ddean3 years ago

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

comment:6 @toscho3 years ago

  • Cc info@… added

comment:7 @helgatheviking2 years ago

  • Cc helgatheviking@… added

I need this hook for my plugin as well:

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.

comment:8 @DrewAPicture2 years ago

  • Cc xoodrew@… added

@DrewAPicture2 years ago

comment:9 @DrewAPicture2 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 2 years ago by DrewAPicture (previous) (diff)

comment:10 @helen2 years ago

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

comment:11 @DrewAPicture2 years ago

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

comment:12 @SergeyBiryukov2 years ago

#21898 was marked as a duplicate.

comment:13 @Chouby2 years ago

  • Cc frederic.demarle@… added

comment:14 @Chouby2 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);

comment:15 @DrewAPicture2 years ago

  • Keywords 3.6-menus removed

comment:16 @DrewAPicture2 years ago

#23741 was marked as a duplicate.

comment:17 @DrewAPicture2 years ago

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

comment:18 @mordauk2 years ago

  • Cc pippin@… added

comment:19 @helgatheviking2 years ago

Is this going to make it into 3.6?

comment:20 @greenshady2 years ago

  • Cc justin@… added

comment:21 @ocean9022 months ago

  • Milestone changed from 3.6 to Future Release

comment:22 @SergeyBiryukov21 months ago

#24652 was marked as a duplicate.

comment:23 @shrkey18 months ago

  • Cc shrkey added

comment:24 @stephenharris18 months ago

  • Cc contact@… added

comment:25 @helgatheviking16 months ago

any chance for 3.8?

comment:26 @markoheijnen16 months 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

comment:28 @Faison14 months 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.


comment:29 @enollo12 months 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

comment:30 follow-ups: @helgatheviking12 months 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?

comment:31 in reply to: ↑ 30 @Faison12 months 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!

comment:32 in reply to: ↑ 30 @enollo12 months 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.

comment:33 @Viper007Bond12 months 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.

comment:34 @helgatheviking12 months 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.

comment:35 follow-up: @dnavarrojr11 months ago

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

comment:36 in reply to: ↑ 35 @helen11 months 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.

comment:37 @helgatheviking9 months ago

In the meantime, per @Shazdeh's very neat suggestion at:

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

// 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.

comment:38 @DrewAPicture9 months ago

#28771 was marked as a duplicate.

comment:39 @DrewAPicture6 months ago

#29854 was marked as a duplicate.

comment:40 @DrewAPicture6 months ago

#18527 was marked as a duplicate.

comment:41 @helen5 months ago

#14414 was marked as a duplicate.

comment:42 @zedd452 months 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.

Note: See TracTickets for help on using tickets.