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

WordPress Trac noreply at wordpress.org
Mon Aug 3 17:38:45 UTC 2015

#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                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:  administration
Changes (by daxelrod):

 * keywords:  has-patch needs-testing => has-patch dev-feedback


 > The removal of locks (AJAX on unload) doesn't work well in all browsers
 and in all circumstances. Sometimes the AJAX request doesn't fire,
 sometimes the browser aborts it. We need to look at improving it/making it
 more reliable.

 It seems quite reliable in modern browsers, and in extreme cases such as
 force quit, in my opinion the lock timeout provides an adequate fallback.

 > To be able to do "take over", we may need to save the current user's
 changes somehow. Not all settings screens will need this but there are
 several where we wouldn't want to discard unsaved changes/loose the
 current user's data.

 I agree the edit lock API should provide functions for this. Local storage
 seems like a logical choice to implement, but what/how data is saved and
 how the user would go about restoring it are UX questions.

 > One way this may work is by storing all form fields in session storage
 and restore on page reload. Another option is to show an "attempted take
 over" dialog with a cancel button instead of locking the screen.

 I'm not sure I would want to go down this route of enabling ping-ponging
 back and forth.

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

More information about the wp-trac mailing list