[wp-trac] [WordPress Trac] #31436: Handle conflicts in concurrent Customizer sessions

[WordPress Trac]

#31436: Handle conflicts in concurrent Customizer sessions
--------------------------+--------------------------
 Reporter:  westonruter   |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  accepted
 Priority:  normal        |   Milestone:  4.3
Component:  Customize     |     Version:  3.4
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  javascript
--------------------------+--------------------------
Description changed by westonruter:

Old description:

> If two users open the Customizer at the same time and modify the same
> settings, the user who saves their changes last will win out, and the
> person who saves first will have their changes lost. (The frequency of
> the problem was reduced in #29983 since now only dirty settings now get
> POSTed.) The Customizer needs Heartbeat integration to add the “Post
> Locking” functionality. We don't need to lock the entire Customizer,
> however, from concurrent users: we need to add locking for individual
> settings in the Customizer. When a setting becomes dirty, we need to
> broadcast via Heartbeat to other users that the setting has been changed
> and thus any controls for this setting should be marked as "locked", with
> any changes prevented. This will become increasingly important as more
> and more settings are added to the Customizer and users go there more
> often to make changes.
>
> The locking UI could provide a button to copy the other user's change
> into the other Customizer session, and this could result in the control
> being editable again, with subsequent changes pushed out to other users
> as well, who would then also get the corresponding setting automatically
> updated if it was dirty, but if it was not dirty then it would remain in
> its clean state but with a locking notification added.
>
> This also should apply when a setting is modified by some means other
> than the Customizer: if someone is in the Customizer and another user
> changes a setting via an admin page or via XML-RPC or REST API, then this
> setting update should also be illustrated in the Customizer to note that
> the settings are stale and should be refreshed. This refresh could be
> done inline, without having to reload the entire page.
>
> Another special consideration needs to be made for Widgets in the
> Customizer. Each WP_Widget 2.0 “multi-widget” gets an index number
> associated with each instance of a give type. When you add a widget, this
> number gets incremented (`widget.set( 'multi_number', widget.get(
> 'multi_number' ) + 1 );`). The initial multi-number is calculated from
> the `next_widget_id_number()` function which takes the max number
> currently used, and increments it by one.
>
> For frequently-used widgets, the above problem will happen frequently
> where two users will try to add the same widget at the same time, and
> thus they will start out with the same initial `multi_number`, resulting
> in the same widget ID. When they both save their changes, one user's
> widget will override the other user's widget: whoever saves last.
> Likewise, it is possible for multiple widgets to be deleted in one
> session (from the widgets admin page, since Customizer only removes
> widgets by moving them to the Inactive Widgets sidebar) then new ones
> added back in other sessions and the initial `multi_number` will not be
> consistent. In other words, the `multi_number` for each widget type needs
> to be synced across each Customizer session along with the actual setting
> values.
>
> Some enhancements for a feature plugin: The Customizer UI would benefit
> from having a list of users currently in the Customizer appearing
> somewhere, with a list of the changes each user has made. If someone left
> their Customizer session open, this list would also allow an
> administrator to sign the user out, using something like the
> [https://wordpress.org/plugins/user-session-control/ User Session
> Control] plugin; or the Customizer UI could provide a way to boot a user
> from the Customizer.

New description:

 If two users open the Customizer at the same time and modify the same
 settings, the user who saves their changes last will win out, and the
 person who saves first will have their changes lost. (The frequency of the
 problem was reduced in #29983 since now only dirty settings now get
 POSTed.) The Customizer needs Heartbeat integration to add the “Post
 Locking” functionality. We don't need to lock the entire Customizer,
 however, from concurrent users: we need to add locking for individual
 settings in the Customizer. When a setting becomes dirty, we need to
 broadcast via Heartbeat to other users that the setting has been changed
 and thus any controls for this setting should be marked as "locked", with
 any changes prevented. This will become increasingly important as more and
 more settings are added to the Customizer and users go there more often to
 make changes.

 The locking UI could provide a button to copy the other user's change into
 the other Customizer session, and this could result in the control being
 editable again, with subsequent changes pushed out to other users as well,
 who would then also get the corresponding setting automatically updated if
 it was dirty, but if it was not dirty then it would remain in its clean
 state but with a locking notification added.

 This also should apply when a setting is modified by some means other than
 the Customizer: if someone is in the Customizer and another user changes a
 setting via an admin page or via XML-RPC or REST API, then this setting
 update should also be illustrated in the Customizer to note that the
 settings are stale and should be refreshed. This refresh could be done
 inline, without having to reload the entire page.

 For the issue of conflicting auto-incremented widget IDs across user
 sessions, see #32183.

 Some enhancements for a feature plugin: The Customizer UI would benefit
 from having a list of users currently in the Customizer appearing
 somewhere, with a list of the changes each user has made. If someone left
 their Customizer session open, this list would also allow an administrator
 to sign the user out, using something like the
 [https://wordpress.org/plugins/user-session-control/ User Session Control]
 plugin; or the Customizer UI could provide a way to boot a user from the
 Customizer.

--

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