[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