WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#32832 closed enhancement (fixed)

Menu Customizer: Hook tracking

Reported by: celloexpressions Owned by: celloexpressions
Milestone: 4.3 Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords:
Focuses: docs Cc:
PR Number:

Description (last modified by westonruter)

This ticket is to track remaining hook needs within Menus in the Customizer, to alleviate confusion, and a slew of duplicate tickets being opened to address various issues that sound different but are actually the same.

Here is a summary of all places in the menus UI that should be hook-able, and the suggested approach to allowing devs to leverage these:

  • Menus Panel view - menu list, add new menu -> Customizer API (add_section)
  • Pre/post-menu name -> Customizer API (add_control)
  • Pre/post menu control/theme locations -> Customizer API (add_control)
  • Pre/post auto_add control -> Customizer API (needs to be re-split into a separate control) (add_control)
  • Screen Options -> existing filter manage_nav-menus_columns, should scope to Customizer when using, likely also requires some css when adding options
  • Menus help text -> Customizer API (get_panel, can also add to sections or elsewhere as needed)
  • Menu Locations section -> Customizer API (add_control)
  • Available items panel -> use show_in_nav_menus to show/hide post types/taxonomies, hooks to add custom sections (after Links or at bottom) handled in #32708
  • Menu item forms -> API or action to add custom options between description and original links (also needs support for saving the data as post meta), use CSS & screen options to hide core UI (to do). See #18584 (and at least 5 duplicate tickets linked there). This is the primary thing that this ticket needs to address, and @westonruter has started thinking about implementation approaches.

Current tasks remaining for implementing the above plan:

  • Separate the auto-add checkbox out from the menu control so that it can be removed or things added before/after it (this ticket) (#32820)
  • Hooks for extending the available menu items panel (#32708)
  • Hooks/API for extending menu item controls/forms (this ticket)

Change History (22)

#1 @westonruter
4 years ago

  • Description modified (diff)

#2 @obenland
4 years ago

  • Owner set to celloexpressions
  • Status changed from new to assigned

#3 @valendesigns
4 years ago

Are we creating tickets for all these hooks or adding diffs here?

Last edited 4 years ago by valendesigns (previous) (diff)

#4 @obenland
4 years ago

Feel free to add them here.

#5 @codezag
4 years ago

  • Focuses docs added

Make it easy to add options to menu items guys,
Thank you

#6 @celloexpressions
4 years ago

@westonruter or @valendesigns if either of you are able to tackle a proposed API or hook system for menu item fields that would be awesome. If not, I'll take a look (will probably be targeting beta 4 for this). This is really important functionality for developers that has been lacking for years. Not that we can finally do it, I'd like to do everything we can to make it happen.

Other two hooks are tracking - @westonruter is reviewing the auto_add change and I'll review the available menu items panel hook proposal.

#7 @valendesigns
4 years ago

@celloexpressions I can look into menu items on Tuesday. Have many/any hooks for Customizer Menus landed in Core yet?

#8 @celloexpressions
4 years ago

None yet I believe. Obviously the goal is to leverage the Customizer API as much as possible, but this is a place where we need to use more traditional actions/filters.

#9 @celloexpressions
4 years ago

@valendesigns (or @westonruter) did you get a chance to look at menu item hooks yet? If not by the end of this week I can try this. We need:

  • A way to add arbitrary UI within a menu item control
  • Account for any non-core fields when handling menu item setting data (previewing and saving)
  • Look at how this works with regards to partial refresh
  • A way to specify the sanitization callback for custom fiels
  • Make sure that custom fields can be retreived reasonably easily when working with menu output on the front-end

#10 @westonruter
4 years ago

I have not had any time to look at extensible menus in the Customizer, other than to review the work that @valendesigns has done so far.

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


4 years ago

#12 @westonruter
4 years ago

In 33366:

Customizer: Introduce customize_nav_menu_available_item_types and customize_nav_menu_available_items filters.

Allows for new available menu item types/objects to be registered in addition to filtering the available items that are returned for each menu item type/object.

Props valendesigns, imath, westonruter.
See #32832.
Fixes #32708.

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


4 years ago

#14 follow-up: @celloexpressions
4 years ago

This still needs to be evaluated, along with a make/core post. I'm going to have to make time to do that tomorrow night, I guess, assuming that this needs to be done before RC. At this point any additional changes in core will be necessarily limited, but we're probably going to need to add some JS event triggers even if we end up punting custom fields in menu item controls.

If anyone can jump in here in the next 24 hours that would be greatly appreciated. Especially authors of plugins that want to do things to the menus UI, like add custom fields to menu items.

#15 in reply to: ↑ 14 @obenland
4 years ago

Replying to celloexpressions:

This still needs to be evaluated, along with a make/core post. I'm going to have to make time to do that tomorrow night, I guess, assuming that this needs to be done before RC.

You assume correctly. Preferably by tomorrow.

#16 follow-up: @westonruter
4 years ago

@valendesigns In your work on #32708, do you have a good sample plugin with use cases for how a menu item's controls would be extended? @imath Do you?

Quickly thinking about what needs to be done here, I think there are two things needed at a bare minimum to allow for extensibility:

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

There's a big assumption/question here: can we assume that a nav_menu_item setting's properties will all be sourced from postmeta, or will they ever be drawn from elsewhere?

#17 @celloexpressions
4 years ago

Let's assume it's all in postmeta. Menu items are post objects, so custom fields within them should be stored that way just like core ones are. If you need to do something more complicated than that, you're probably going to need to make some more fundamental changes.

The plugins linked on #18584 are:

The primary thing I'd want to use it for would be to add an option to set an image or icon for a menu item. I believe there are several plugins that do that. If we have a do_action within the control template, that would allow for pretty much anything they may need, then if we have support for registering extra fields to be saved in the setting that would be the next step for support, as outlined above.

#18 in reply to: ↑ 16 @imath
4 years ago

Hi @westonruter

There's a big assumption/question here: can we assume that a nav_menu_item setting's properties will all be sourced from postmeta, or will they ever be drawn from elsewhere?

The origin of #32708 was a BuddyPress need to also be able to build dynamic user navigation from the customizer.
See BP6509

BuddyPress user navigations are not using postmeta but are built at run time.

#19 @samuelsidler
4 years ago

  • Milestone changed from 4.3 to Future Release
  • Type changed from task (blessed) to enhancement

RC is ~18 hours away. We don't have time to complete this before 4.3. If it's still wanted, it will need to wait until 4.4.

#20 @celloexpressions
4 years ago

  • Keywords needs-patch removed
  • Milestone changed from Future Release to 4.3
  • Resolution set to fixed
  • Status changed from assigned to closed

Most of the items in this tracking ticket are fixed or for record only, so marking as complete on 4.3. Only remaining item is menu item fields. We need either a new ticket or the green light to re-scope #18584 to menus in the Customizer for addition of API for adding things to menu item controls. We really need plugin developers who are looking for this functionality to help figure out how best to approach these hooks in core.

I'll link the 4.3 menu customizer hook explanation post from make/core here once it's written.

#21 @helgatheviking
4 years ago

As the author of Nav Menu Roles, what kind of help are you looking for? I've only dabbled with the Customizer, but for NMR, I need to add some fields, load a small script, and save the data from those fields (as post meta for each menu "post" item).

#22 @westonruter
4 years ago

I've re-scoped #18584 for 4.4 to flesh out the hooks for menus to allow for full extensibility both in the admin page and the customizer. Let's continue the discussion there.

Note: See TracTickets for help on using tickets.