[wp-trac] [WordPress Trac] #42658: Customize: Heartbeat doesn't refresh changeset lock when branching is enabled

[WordPress Trac]

#42658: Customize: Heartbeat doesn't refresh changeset lock when branching is
enabled
--------------------------+------------------------
 Reporter:  dlh           |       Owner:  dlh
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  high          |   Milestone:  4.9.3
Component:  Customize     |     Version:  4.9
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------
Changes (by dlh):

 * keywords:  needs-patch => has-patch


Comment:

 [attachment:42658.2.diff] makes the `current_user_can()` check more
 specific as suggested in comment:8.

 > The only way to get around that would be to opt to inject the
 customize_changeset_uuid param by some other means...I don't know if
 that's better than just improving the cap checking for locking as it
 exists in core today.

 I'm not sure I entirely follow. I agree that it would be nice if the
 Customizer automatically initialized with the UUID from the heartbeat
 request. But, as far as I can tell, that wouldn't cause the Customizer to
 start running any new checks for `current_user_can( get_post_type_object(
 'customize_changeset' )->cap->edit_post, $changeset_post_id )`. So, adding
 that check in `check_changeset_lock_with_heartbeat()` seems useful either
 way.

 > the change in #42975 will mean the lock will get lost when a user is
 sitting in the Customizer but doesn't make any changes. If they make a
 change, the autosave will cause the lock to be regained, but heartbeat
 won't be maintaining their lock otherwise. Right?

 It's true that `\WP_Customize_Manager::establish_loaded_changeset()` will
 no longer call `set_changeset_lock()` during heartbeat requests because
 `$pagenow` is `admin-ajax.php`: https://github.com/WordPress/wordpress-
 develop/blob/026cd70e25b90f04c27a21eaf634048945848398/src/wp-includes
 /class-wp-customize-manager.php#L643.

 However, for users in "linear" changeset mode,
 `establish_loaded_changeset()` should still be able to find the current
 changeset post ID, and
 `\WP_Customize_Manager::check_changeset_lock_with_heartbeat()` can use
 that post ID to proceed with its logic. Users with changeset branching
 enabled are still in the same boat they're in now. So I'm not sure #42975
 changes the situation in this ticket.

 Of course, let me know if I've misunderstood what you meant on either
 point.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42658#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform