[wp-trac] [WordPress Trac] #50501: Customize: Do not allow changesets to be deleted when someone is editing them

[WordPress Trac]

#50501: Customize: Do not allow changesets to be deleted when someone is editing
them
--------------------------+--------------------------------------
 Reporter:  dlh           |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  5.5
Component:  Customize     |    Version:  4.9
 Severity:  normal        |   Keywords:  has-patch has-unit-tests
  Focuses:                |
--------------------------+--------------------------------------
 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:

 1. Open the Customizer while logged in as the first administrator. Make a
 change and save a draft of the changeset. Leave this window open.

 2. 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()`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50501>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform