Opened 8 years ago
Last modified 7 months ago
#18584 new enhancement
Nav menu UI needs more hooks — at Version 47
Reported by: |
|
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 )
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)
#4
@
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/
#7
@
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.
#9
@
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.
#10
@
7 years ago
Nacin noted that issues like #14134 stand in the way of making adding more fields a really good idea.
#11
@
7 years ago
The menu item link attributes filter proposed in the first patch was added in [23565].
#14
@
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);
#17
@
7 years ago
@Chouby's proposed hooks for back-compat-ish with the locations settings from #23741: ticket:23741:23741.diff
#26
@
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
@
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
@
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
#31
in reply to:
↑ 30
@
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
@
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
@
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
@
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:
↓ 36
@
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
@
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:
↓ 44
@
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.
#42
follow-up:
↓ 43
@
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
@
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:
#44
in reply to:
↑ 37
@
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:
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
@
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 thelink
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 returnedWP_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.
Related: #18527, #16738, #14414, #16691