[wp-trac] [WordPress Trac] #18584: Nav menu UI needs more hooks

[WordPress Trac]

#18584: Nav menu UI needs more hooks
--------------------------+-------------------------
 Reporter:  Viper007Bond  |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  4.4
Component:  Customize     |     Version:  3.3
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  javascript
--------------------------+-------------------------
Changes (by westonruter):

 * focuses:   => javascript
 * component:  Menus => Customize
 * priority:  low => normal
 * milestone:  Future Release => 4.4
 * keywords:  has-patch needs-testing 3.9-early => needs-patch
 * severity:  minor => normal


Old description:

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

New description:

 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.

--

Comment:

 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 [https://core.trac.wordpress.org/ticket/32832#comment:16 #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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/18584#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform