#39103 closed defect (bug) (fixed)
Customize: menus aren't deleted
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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
@
9 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.
9 years ago
#5
@
9 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
@
9 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
previewfilters are being added for the nav menu settings even during acustomize_saverequest. 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_objectfilter, 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_saveajax 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_Managerwithout callingpreviewon all of the settings.Aside: We'll need to refactor these to not use thecustomize_saveAdmin ajax as the signal but rather to check ifdoing_action( 'publish_customize_changeset' )