[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
Comment:
> 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