[wp-trac] [WordPress Trac] #32814: Custom Menu Widget should show newly added menus in Customizer

[WordPress Trac]

#32814: Custom Menu Widget should show newly added menus in Customizer
--------------------------------------+-------------------------
 Reporter:  adamsilverstein           |       Owner:
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  4.3
Component:  Customize                 |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  needs-patch dev-feedback  |     Focuses:  javascript
--------------------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:8 adamsilverstein]:
 > Still working on this item.
 >
 > Looks like the best/most straightforward approach will be to save the
 new unpublished menu items to the server via ajax so that rendering can
 happen correctly for the custom menu widget (and any other customizer
 element referencing menus).
 >
 > Since we previously had code that was saving the menus via ajax, I
 should be able to leverage this old code - working on that now. We will
 need to fire events to add, update or delete menus, using the temporary
 menu id. Once this is in place the existing widget rendering functionality
 should work as expected. Once the menu is 'saved and published' we will
 need to remove the temporary php side data and update any widgets to use
 the new ID (partially in place already), while also maintaining the
 correctly selected (potentially new) menus.

 I really do not think that persisting nav menu items via Ajax is the way
 to go here, as it's the whole point of the refactor work to ensure the
 Customizer state is fully captured in the settings currently in memory on
 the client.

 When a new menu is created added, this menu should be added to the nav
 menu widgets with the placeholder ID supplied as the value. I think the
 part that is missing is that we need to take the currently-dirty settings
 as exposed in `wp.customize.previewer.query().customized` and pass this
 along with the `update-widget` Ajax request. This will ensure that all of
 the menus are available to the widget when it tries to call the update
 callback.

 When the Customizer session is saved, then any widgets that reference the
 placeholder ID will need to have that menu `option` value updated to use
 the new permanent ID, and a `change` event triggered on the `select` to
 cause the `update-widget` call to happen again with the updated menu item.
 This is similar to what is being done now when the menus get updated after
 a save happens (their settings get updated and then their dirty states are
 reset). Now, the thing that is then missing here is that the nav menu
 widgets need to get updated to replace any reference in a widget instance
 to a placeholder ID to one that uses the permanent ID. This could either
 be done in a secondary re-save step at `customize_save_after`, or it could
 be done as part of the nav menu widget itself, to force the saving of any
 placeholder nav menus first so that it can then use the permanent ID when
 the widget is saved. This would be similar to how the logic for saving a
 nav menu item settings ensures that its parent nav menu setting is saved
 first.

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