[wp-trac] [WordPress Trac] #39103: Customize: menus aren't deleted
WordPress Trac
noreply at wordpress.org
Tue Dec 6 06:25:56 UTC 2016
#39103: Customize: menus aren't deleted
------------------------------+--------------------
Reporter: celloexpressions | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 4.7.1
Component: Customize | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
------------------------------+--------------------
Changes (by westonruter):
* keywords: needs-patch => has-patch
Comment:
The reason for the failure to delete a menu is that the `preview` filters
are being added for the nav menu settings even during a `customize_save`
request. The result is that when attempting to call `wp_delete_nav_menu()`
for the deleted nav menu ID, it will in turn call
`wp_get_nav_menu_object()` which has its return value modified by the
`wp_get_nav_menu_object` filter, which the setting's preview uses to
supply `false`. When this function returns false, then the
`wp_delete_nav_menu()` logic is short-circuited.
This was accounted for in widgets in the
`\WP_Customize_Widgets::customize_register()` be checking to see if the
`customize_save` ajax request is being made.
But, this is short sighted nevertheless. It will fail to work when
implementing the changesets REST API endpoint. There should be a way to
initialize `WP_Customize_Manager` without calling `preview` on all of the
settings.
Aside: We'll need to refactor these to not use the `customize_save` Admin
ajax as the signal but rather to check if `doing_action(
'publish_customize_changeset' )`
--
Ticket URL: <https://core.trac.wordpress.org/ticket/39103#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list