WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 3 months ago

#18584 new enhancement

Nav menus need more hooks for extensibility (on admin page & in customizer)

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

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.

Attachments (4)

nav_menu.diff (2.2 KB) - added by ddean 5 years ago.
nav menu hooks proposal
18584.diff (2.0 KB) - added by DrewAPicture 3 years ago.
nav-menu.patch (628 bytes) - added by sebastian.pisula 6 months ago.
My patch from ticket #33861
18584.2.diff (13.5 KB) - added by westonruter 6 months ago.
https://github.com/xwp/wordpress-develop/pull/140

Download all attachments as: .zip

Change History (83)

#2 @markoheijnen
5 years ago

  • Cc marko@… added

@ddean
5 years ago

nav menu hooks proposal

#3 @sirzooro
5 years ago

  • Cc sirzooro added

#4 @Viper007Bond
5 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 5 years ago by Viper007Bond (previous) (diff)

#5 @ddean
5 years ago

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

#6 @toscho
4 years ago

  • Cc info@… added

#7 @helgatheviking
3 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
3 years ago

  • Cc xoodrew@… added

@DrewAPicture
3 years ago

#9 @DrewAPicture
3 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 3 years ago by DrewAPicture (previous) (diff)

#10 @helen
3 years ago

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

#11 @DrewAPicture
3 years ago

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

#12 @SergeyBiryukov
3 years ago

#21898 was marked as a duplicate.

#13 @Chouby
3 years ago

  • Cc frederic.demarle@… added

#14 @Chouby
3 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
3 years ago

  • Keywords 3.6-menus removed

#16 @DrewAPicture
3 years ago

#23741 was marked as a duplicate.

#17 @DrewAPicture
3 years ago

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

#18 @mordauk
3 years ago

  • Cc pippin@… added

#19 @helgatheviking
3 years ago

Is this going to make it into 3.6?

#20 @greenshady
3 years ago

  • Cc justin@… added

#21 @ocean90
3 years ago

  • Milestone changed from 3.6 to Future Release

#22 @SergeyBiryukov
3 years ago

#24652 was marked as a duplicate.

#23 @shrkey
3 years ago

  • Cc shrkey added

#24 @stephenharris
3 years ago

  • Cc contact@… added

#25 @helgatheviking
3 years ago

any chance for 3.8?

#26 @markoheijnen
3 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
2 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
2 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
2 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
2 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
2 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
2 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
2 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
2 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
2 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
2 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
2 years ago

#28771 was marked as a duplicate.

#39 @DrewAPicture
22 months ago

#29854 was marked as a duplicate.

#40 @DrewAPicture
22 months ago

#18527 was marked as a duplicate.

#41 @helen
21 months ago

#14414 was marked as a duplicate.

#42 follow-up: @zedd45
19 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.

#43 in reply to: ↑ 42 @rtpHarry
16 months 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
16 months 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.


13 months ago

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


13 months ago

#47 @westonruter
12 months 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.

#48 @westonruter
12 months ago

  • Summary changed from Nav menu UI needs more hooks to Nav menus need more hooks for extensibility (on admin page & in customizer)

This ticket was mentioned in Slack in #core by westonruter. View the logs.


11 months ago

#50 @DrewAPicture
11 months ago

#16691 was marked as a duplicate.

#51 @SergeyBiryukov
11 months ago

#33861 was marked as a duplicate.

#52 @celloexpressions
10 months ago

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.

#53 @DrewAPicture
10 months ago

#27066 was marked as a duplicate.

#54 @DrewAPicture
10 months ago

  • Milestone changed from 4.4 to Future Release

Based on comment:52, seems the approach is still being determined. Moving off the 4.4 milestone.

#55 follow-up: @helgatheviking
7 months ago

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:

http://imagizer.imageshack.com/img910/6105/dSZwk2.jpg

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.

#56 in reply to: ↑ 55 @westonruter
7 months ago

Replying to helgatheviking:

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.

#57 @helgatheviking
7 months ago

Nav Menu Roles is available on github and in the repo too.

Specifically, I am filtering the admin menu Walker and then providing a duplicate of the default Walker with only a do_action hook added. Finally, I am adding the fields to that hook with this callback and saving the meta on wp_update_nav_menu_item hook with the following callback

Let me know if I can clarify anything.

@sebastian.pisula
6 months ago

My patch from ticket #33861

#58 @sebastian.pisula
6 months ago

Meybe in WordPress 4.5 ? :)

#59 @sebastian.pisula
6 months ago

  • Keywords has-patch added; needs-patch removed

This ticket was mentioned in Slack in #core by sebastian.pisula. View the logs.


6 months ago

#61 @celloexpressions
6 months ago

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.

#62 follow-up: @helgatheviking
6 months ago

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.

Adding an action hook is the *only* thing that I am doing when I serve up my modified menu Walker. See [here](https://github.com/helgatheviking/Nav-Menu-Roles/blob/master/inc/class.Walker_Nav_Menu_Edit_Roles.php#L198).... served up by filtering wp_edit_nav_menu_walker.

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.

#63 in reply to: ↑ 62 @woodent
6 months ago

Right on, @helgatheviking. I'm one of the ones who has a plugin using the agreed upon action hook. I would love to see this in core. All the other hooks I need are already present.

Last edited 6 months ago by woodent (previous) (diff)

#64 follow-up: @westonruter
6 months ago

  • Keywords needs-patch added; has-patch removed

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.

#65 follow-up: @helgatheviking
6 months ago

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.

#66 in reply to: ↑ 65 @westonruter
6 months ago

Replying to helgatheviking:

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 thought here is to make the API as complete as possible.

#67 @helgatheviking
6 months ago

Thanks! I was just wondering if there was a need for existing fields to be removed and if that could potentially cause problems.

#68 @helgatheviking
5 months ago

Just revisiting this.

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

#69 in reply to: ↑ 64 @Chouby
5 months ago

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

Replying to helgatheviking:

Is it really a good idea to let someone remove the core fields like menu title?

This is what I already do. Well, in fact, I replace the title and url fields by hidden fields.

#70 @helgatheviking
5 months ago

Do you mean https://github.com/xwp/wordpress-develop/tree/trac-18584 ? Since it is on git it will be 100x easier for me to take a look at and I will try to test it out with my Nav Menu Roles plugin.

#71 @Chouby
5 months ago

Yes. It's what I used.

#72 @keraweb
5 months ago

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.

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


3 months ago

#74 @celloexpressions
3 months ago

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.

#75 @grapplerulrich
3 months ago

#27280 was marked as a duplicate.

#76 @grapplerulrich
3 months ago

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.

#77 @sebastian.pisula
3 months ago

  • Keywords has-patch added; needs-patch removed

#78 @grapplerulrich
3 months ago

Could we also a specific class for the "Navigation Label"? All of the other sections have something like "field-url". Perhaps we could use <p class="field-title description description-wide">

I built a plugin for a client's website and used the version of the class that @westonruter created.

One other problem that I came across was that I when I created a new field the data was not transferred with the ajax request that WP made when adding a new menu. The reason is that WP has a list of fields that it fetches the data from. https://github.com/WordPress/WordPress/blob/4.5-branch/wp-admin/js/nav-menu.js#L208-L222

I could continue the work that @westonruter started but need a bit of guidance and help with the JS and customizer problems.

This ticket was mentioned in Slack in #core by iamntz. View the logs.


3 months ago

Note: See TracTickets for help on using tickets.