Opened 5 years ago
Closed 5 years ago
#50501 closed defect (bug) (fixed)
Customize: Do not allow changesets to be deleted when someone is editing them
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.5 | Priority: | normal |
Severity: | normal | Version: | 4.9 |
Component: | Customize | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Description
The Customizer's locking mechanism to prevent two users from editing the same changeset simultaneously does not prevent one user from deleting a changeset while another user is editing it.
(Note that this is not an issue of missing capability checks. The user doing the deleting still must have the capabilities to do so.)
This behavior is inconsistent with the behavior of locked posts, which can't be deleted via the list tables when another user is editing them: https://github.com/WordPress/wordpress-develop/blob/2efbc51712a184c5e5bce7f9049eceb8f89d1614/src/wp-admin/post.php#L253-L258
To replicate, an installation with two administrator accounts is needed:
- Open the Customizer while logged in as the first administrator. Make a change and save a draft of the changeset. Leave this window open.
- In an incognito window, log in as the second administrator and open the Customizer.
An overlay should appear notifying the second administrator that another user is customizing the site, but it does not -- see #50500. Opening the publish panel will reveal the "Discard changes" button. Clicking it will trash the first user's changeset and begin a new changeset controlled by the second administrator.
Even when the overlay works as expected, the second administrator can execute wp.customize.previewer.trash()
from the JavaScript console to trash the changeset.
The attached patch proposes a check for the post lock in \WP_Customize_Manager::handle_changeset_trash_request()
.
In 48211: