[wp-trac] [WordPress Trac] #32814: Custom Menu Widget should show newly added menus in Customizer
WordPress Trac
noreply at wordpress.org
Mon Jul 6 22:45:23 UTC 2015
#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: dev-feedback has-patch | Focuses: javascript
------------------------------------+-------------------------
Comment (by westonruter):
@adamsilverstein I've done a review of the changes:
I think the addition of `_resetCustomMenuWidgets` will no longer be needed
with the pending patch made to #32841. The menus rendered in Custom Menu
widgets weren't getting properly refreshed, and this I believe I've
resolved in the patch on that ticket. Merely changing a menu or menu item
should be all that is needed to trigger a menu to refresh. Please try
merging that patch into yours, and see if it works as expected without
`_resetCustomMenuWidgets` being active.
I commented this on the [https://github.com/xwp/wordpress-
develop/pull/98/files PR], but when a Custom Menu widget is saved which
had selected a new menu… I don't think this is currently persisting the
newly-inserted menu ID in the widget settings. In other words, if you
create a menu (without saving), assign it to a Custom Menu widget, and
then Save… you have it update the UI to select the proper nav menu ID, but
if you then reload the Customizer and re-examine the widget, it seems like
it would still be trying to reference the placeholder nav menu?
I think the widget update needs to be handled on the server instead: when
inserting a new nav menu, I think during the `customize_save` action we
need to check if any Custom Menu widgets are referencing the placeholder
ID, and then at that time make sure that all of these widgets get updated
to reference the newly inserted term ID. And then the JS-value settings
can be sent back in the `customize_save_response` filter: there can be a
`data.custom_menu_widget_updates` just like we're including
`data.nav_menu_updates`, and then for each
`data.custom_menu_widget_updates` it can update the settings with those
values, and then clear out the dirty state.
Lastly, I think that `WP_Customize_Nav_Menus::filter_nav_menu_object()` is
duplicating the functionality of
`WP_Customize_Nav_Menu_Setting::preview()`. I'm not clear why this is
needed. Could you clarify?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/32814#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list