[wp-trac] [WordPress Trac] #32202: Add support for options page locking (settings API concurrency)

[WordPress Trac]

#32202: Add support for options page locking (settings API concurrency)
------------------------------------+-----------------------------
 Reporter:  westonruter             |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Future Release
Component:  Options, Meta APIs      |     Version:  3.6
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:  administration
------------------------------------+-----------------------------
Changes (by westonruter):

 * milestone:   => Future Release


Comment:

 @callumbw95 Thanks for reminding me of this decade-old ticket! It
 definitely seems relevant for Phase 3 (Collaboration).

 I think the open question I have for this ticket is how often it is an
 issue. In practice, most setting screens (in core) are likely updated
 rarely. I'd love to hear anecdotes from users who have actually had the
 problem of two users overwriting their pending changes. Granted, plugins
 may have settings screens which are updated much more commonly, even on a
 daily basis, having some locking mechanism may make sense.

 At the very least, for collaborative editing I should think that there
 should be a way to have a presence indicator shown on the various admin
 screens. In this way, if I land on the Reading screen and yet I see that
 Callum Bridgford-Whittick is shown as also being there, then I should
 probably ping you to collaborate and not make any change. So I think the
 awareness of presence is the first problem to solve.

 Going beyond this, maybe an active presence from another user could cause
 a screen to be locked with an overlay. But I can imagine this being
 problematic for screens like those with list tables on which users could
 make discrete changes to individual items without there being a conflict.
 Granted these are not "options" screens, but consider the case of two
 users both being on the Comments screen to moderate pending comments. It
 could be that the two users are collaborating so that one starts
 moderating comments list from the top and the other from the bottom to
 then meet in the middle. This issue could also manifest on non-core
 options screens that have option toggles that apply their updates live
 without having to submit the form.

 Then again, if two users are allowed on the same screen at the same time,
 there's then the issue of the state of the pages diverging, so the two
 users aren't sure what has been touched by the other user or not. To
 address this, the ideal would be for the page states to sync across the
 user sessions, but this quickly adds to the complexity (and may not even
 be possible for custom options screens using their own ad hoc JS).

 I think I've argued myself back in favor of having a screen locking
 overlay when there is another user present, for options screens
 specifically. For other screens, like those using data views, more
 sophisticated collaboration could be used such as synchronizing state
 across user sessions.

 I don't think it makes sense to try to implement any kind of
 synchronization of form fields on an options screen for concurrent users.
 This will be unreliable. A simple lock screen overlay should be quite
 sufficient. Anything beyond this should be plugin territory.

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