Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#18642 closed defect (bug) (fixed)

_edit_lock timestamp does not update on autosave() of non-changed, non-draft posts

Reported by: benbalter's profile benbalter Owned by: nacin's profile nacin
Milestone: 3.3 Priority: normal
Severity: minor Version: 3.3
Component: Autosave Keywords: 2nd-opinion has-patch
Focuses: Cc:

Description (last modified by duck_)

Admin_ajax does not properly update the _edit_lock timestamp in posts when:

  1. The post->post_status != draft, and
  2. The content of the post has not changed since the last autosave ping


  1. Open up a post, page, or CPT that's either private or published
  2. (wait 2 minutes or 2x your autosave ping, don't make any changes to the content)
  3. Log in as another user and navigate to the post
  4. User # 2 now has the file lock because User # 1's timestamp has expired

The Problem:

Lines 282 - 283 of (trunk) only POSTs auto_draft if it is "1".

Lines 985 - 992 expect non-auto_draft autosaves to post auto_draft as != 1.

Possibly Helpful for Background: r12991

So three possible scenarios:

  1. Initial autodraft, auto_draft is posted as 1, line 992 updates _edit_post
  2. Post content has changed, it's a true autosave, so _edit_lock gets update through edit_post()
  3. Post content has not changed, it's not an autodraft, so auto_draft is not POSTed, and the lock is never updated.

Auto_draft will always either be 1 (and thus ID ='s 0) or not POST'd at all. Admin Ajax erroneously assumes it will be posted as != 1 when not an autodraft.

Proposed Fix:

If auto_draft is not set, update post lock. (patch attached).

Alternatively, could patch autosave.js to pass auto_draft of 0 on every non-auto_draft call.

(tested against trunk)

Attachments (1)

autosave_ping.diff (558 bytes) - added by benbalter 13 years ago.
proposed non-autosave edit_lock patch

Download all attachments as: .zip

Change History (7)

13 years ago

proposed non-autosave edit_lock patch

#1 @nacin
13 years ago

  • Milestone changed from Awaiting Review to 3.3

#2 @duck_
13 years ago

  • Description modified (diff)

Typo fix on behalf of Ben.

#3 @nacin
13 years ago

This would greatly increase the number of times a post is found that is locked. (And rightfully so.) But therefore needs to be considered with #18515.

Last edited 13 years ago by nacin (previous) (diff)

#4 @duck_
13 years ago

I believe this occurs even when post content is changed (and it's not a draft) as edit_post() only occurs on autosave for changed (auto-)drafts, see admin-ajax.php line 972 - 984. The content changing only affects whether or not a revision gets written to the DB.

So I think the situations are:

  1. It's a changed (auto-)draft and is overwritten by edit_post() which updates the post lock
  2. Otherwise, the post lock isn't updated as isset( $_POST['auto_draft'] ) && ( $_POST['auto_draft'] != '1' is never true.

i.e. _edit_lock is not updated when not draft or not changed.

Verified by editing a post, adding to the content, waiting for the autosave to occur and then checking that the value in the database hasn't changed.

Anyway it's the same fix. Good catch.

#5 @benbalter
13 years ago

That makes more sense.

It appears the bigger problem, then, is that all non-draft posts only remain locked for the first 2 minutes by default (2x Autosave + filters).

#6 @nacin
13 years ago

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

In [18709]:

Fix issue where post locks were not updating on autosaves. props benbalter, fixes #18642. see #18515 for more on locking. broken in [12991], see #11889.

Note: See TracTickets for help on using tickets.