Opened 18 years ago
Closed 18 years ago
#6043 closed enhancement (fixed)
Post Edit Collision Detection
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | 2.5 | Priority: | normal |
| Severity: | normal | Version: | 2.5 |
| Component: | Administration | Keywords: | has-patch needs-testing |
| Focuses: | Cc: |
Description
When multiple people edit the same post, the last person to save overwrites everyone else's work. It's worse if the post is a draft; autosave stomps all over everyone's work.
This happens with surprising frequency on high traffic, multi author blogs.
Proposal:
Store in postmeta who last edited a post, and when that person edited it. Use that information as a "post lock". Keep the post lock fresh by updating it during autosave. If another person tries to edit a post while the post is locked, display a warning.
Attached Implementation:
- Autosave currently fires every 60 seconds but only if there's some new change in the post to save. Change autosave to fire every 60 seconds no matter what (but only actually write to the DB if there are changes to the post).
- Define that 60 seconds in a new option:
get_option( 'autosave_interval' );. - New function:
wp_check_post_lock()checks to see if a post is locked and by whom. A post lock is considered fresh (and the post locked) if the lock is no older thanautosave_interval * 2seconds old. - New function:
wp_set_post_lock()locks or refreshes lock. - Whenever a person starts editing a post, set lock with
wp_set_post_lock(). - During each autosave, refresh lock with
wp_set_post_lock(). - When someone else goes to edit that post, if
wp_check_post_lock(), display warning withadmin_noticesand disable autosave. - When someone else tries to autosave, if
wp_check_post_lock(), display warning via ajax and disable autosave. - Client side of Ajax handled by beefed up wp-ajax-response JS (move to its own file from wp-list.js).
After patching
svn add wp-includes/js/wp-ajax-response.js
Notes:
- Locks can only be kept fresh via the periodic ajax call (autosave). Locks cannot be kept fresh if you don't have JS.
- If the user doesn't have JS, the lock is still set when the post edit page is loaded. Since we know when the post was last modified (
post_modified), we could show some kind of message if there's an old (non-fresh) lock that is newer than thepost_modifiedand "somewhat recent". Like 5 or 10 minutes or something. That logic and UI gets complicated and confusing, though.
Attachments (3)
Change History (8)
#2
@
18 years ago
Any thoughts on how this locking mechanism could be used by XMLRPC clients? And how that might work between wp-admin edits and XMLRPC client edits?
#3
@
18 years ago
Some ideas josephscott and I brainstormed in no particular order.
XMLRPC ideas:
Make available a new XMLRPC method that reports the lock status for a post.
Return an error when an XMLRPC client tries to edit a post that is locked.
Web ideas:
If you leave your browser open overnight, autosave will keep the lock fresh indefinitely. Maybe add logic to expire locks that have been refreshed so many times without any actual changes to the content of the post. We could then send a message back to the overnight computer via AJAX saying that someone else has edited the post and disable autosave on that post.
If you're editing a post and have been warned that someone else is already editing it, maybe to a JS AYS if you click save/publish/whatever as a final warning.
General ideas:
Currently, locks are only tied to a user. We could tie the lock to a "session" by storing some random string (found as a hidden field on the post edit page or created and remembered by the XMLRPC client) so that the same user can't stomp his/her post with multiple browsers and/or XMLRPC clients.
These are just some random ideas. We haven't actually identified any specific problems yet or decided if they need solutions :)
first pass