Handle conflicts in concurrent Customizer sessions
|Reported by:||westonruter||Owned by:||lgedeon|
Description (last modified by westonruter)
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.
For the previously-reported issue specific for handling conflicts between editing widgets on the widget admin page, see #12722.
For the introduction of concurrency locking for options pages (settings API), see #32202.
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 User Session Control plugin; or the Customizer UI could provide a way to boot a user from the Customizer.
For use of Heartbeat to keep nonces fresh, see #31897.
Change History (19)
- Milestone changed from 4.3 to Future Release
- Type changed from defect (bug) to enhancement
6 months ago
- Owner changed from westonruter to lgedeon
- Status changed from accepted to assigned