#39103 closed defect (bug) (fixed)
Customize: menus aren't deleted
Reported by: | celloexpressions | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.7.1 | Priority: | normal |
Severity: | normal | Version: | 4.7 |
Component: | Customize | Keywords: | has-patch commit fixed-major |
Focuses: | Cc: |
Description
In trunk, deleting a menu in the customizer appears to be successful. However, the next time you open or reload the customizer, any deleted menus reappear. This may cause larger issues with conflicting menu names, for example, because the menu seems to be deleted but actually isn't.
Attachments (2)
Change History (12)
#2
@
8 years ago
39103.1.dff introduces a new saving
property on WP_Customize_Manager
and when it is set then the manager and any components should not call preview
on the settings.
The JS change fixes a related issue where emptying a nav menu location was assigning it to NaN
as opposed to an empty value.
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
8 years ago
#5
@
8 years ago
- Keywords commit added; needs-testing removed
Confirmed that 39103.0.dff works. Let's commit that to trunk and the 4.7 branch, then continue working on 39103.1.dff for a broader approach in a future release.
#6
@
8 years ago
- Owner set to westonruter
- Resolution set to fixed
- Status changed from new to closed
In 39558:
The reason for the failure to delete a menu is that the
preview
filters are being added for the nav menu settings even during acustomize_save
request. The result is that when attempting to callwp_delete_nav_menu()
for the deleted nav menu ID, it will in turn callwp_get_nav_menu_object()
which has its return value modified by thewp_get_nav_menu_object
filter, which the setting's preview uses to supplyfalse
. When this function returns false, then thewp_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 thecustomize_save
ajax request is being made.But, this is short sighted nevertheless. It will fail to work when implementing the changesets REST API endpoint (#38900). There should be a way to initialize
WP_Customize_Manager
without callingpreview
on all of the settings.Aside: We'll need to refactor these to not use thecustomize_save
Admin ajax as the signal but rather to check ifdoing_action( 'publish_customize_changeset' )