[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:
     Type:  enhancement         |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Options, Meta APIs  |    Version:  3.6
 Severity:  normal              |   Keywords:  needs-patch
  Focuses:  administration      |
--------------------------------+-----------------------------
 If two users access an options page at the same time, the user who saves
 last will have their settings stick, while the user who saves first will
 have their settings lost. This is because options pages lack any access
 concurrency checking.

 In #31436 we propose to handle conflicts in concurrent Customizer sessions
 by adding locking to individual controls so that users can't override each
 others' values. The same functionality is needed for options pages
 generated generated via the Settings API. At the most basic level, locking
 could be implemented to block a user from accessing an options page if
 someone else is already there, presenting the user with the same takeover
 screen as shown for post locking.

 A more sophisticated approach would be to allow multiple users to edit an
 options page at once, either by syncing values across the sessions via
 Heartbeat, or by disabling a field entirely for other users when one user
 starts editing it. In this way, the disabled field would not be included
 when the other users submit the form. This may not work in all cases,
 however.

 Another approach, less sophisticated and not using Heartbeat at all, would
 be to introduce a persistent counter for saves to a given admin page. This
 would serve as a revision number, and the revision could be included with
 each settings form. If the submitted form has a setting number that is not
 the same as what is currently stored, then this would indicate there is a
 potential conflict and the user could be presented with a screen to
 resolve any differences.

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