WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 12 years ago

#6043 closed enhancement (fixed)

Post Edit Collision Detection

Reported by: mdawaffe Owned by:
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.5
Component: Administration Keywords: has-patch needs-testing
Focuses: Cc:
PR Number:

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:

  1. 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).
  2. Define that 60 seconds in a new option: get_option( 'autosave_interval' );.
  3. 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 than autosave_interval * 2 seconds old.
  4. New function: wp_set_post_lock() locks or refreshes lock.
  5. Whenever a person starts editing a post, set lock with wp_set_post_lock().
  6. During each autosave, refresh lock with wp_set_post_lock().
  7. When someone else goes to edit that post, if wp_check_post_lock(), display warning with admin_notices and disable autosave.
  8. When someone else tries to autosave, if wp_check_post_lock(), display warning via ajax and disable autosave.
  9. 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:

  1. Locks can only be kept fresh via the periodic ajax call (autosave). Locks cannot be kept fresh if you don't have JS.
  2. 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 the post_modified and "somewhat recent". Like 5 or 10 minutes or something. That logic and UI gets complicated and confusing, though.

Attachments (3)

6043.diff (30.3 KB) - added by mdawaffe 12 years ago.
first pass
6043.2.diff (30.2 KB) - added by mdawaffe 12 years ago.
first pass
6043.3.diff (5.3 KB) - added by mdawaffe 12 years ago.

Download all attachments as: .zip

Change History (8)

@mdawaffe
12 years ago

first pass

@mdawaffe
12 years ago

first pass

#1 @ryan
12 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [7103]) Post Edit Collision Detection from mdawaffe. fixes #6043

#2 @josephscott
12 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 @mdawaffe
12 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 :)

#4 @mdawaffe
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

6043.3.diff

  1. Fixes some error styling: #6054
  2. Fixes some locking issues: #6043
  3. Fixes some autosave message issues: #6053

@mdawaffe
12 years ago

#5 @ryan
12 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [7146]) Post edit collision detection fixes from mdawaffe. fixes #6043

Note: See TracTickets for help on using tickets.