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: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.3 | Priority: | normal |
Severity: | minor | Version: | 3.3 |
Component: | Autosave | Keywords: | 2nd-opinion has-patch |
Focuses: | Cc: |
Description (last modified by )
Admin_ajax does not properly update the _edit_lock timestamp in posts when:
- The post->post_status != draft, and
- The content of the post has not changed since the last autosave ping
STR:
- Open up a post, page, or CPT that's either private or published
- (wait 2 minutes or 2x your autosave ping, don't make any changes to the content)
- Log in as another user and navigate to the post
- User # 2 now has the file lock because User # 1's timestamp has expired
The Problem:
Lines 282 - 283 of autosave.dev.js (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:
- Initial autodraft, auto_draft is posted as 1, line 992 updates _edit_post
- Post content has changed, it's a true autosave, so _edit_lock gets update through edit_post()
- 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)
Change History (7)
#3
@
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.
#4
@
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:
- It's a changed (auto-)draft and is overwritten by edit_post() which updates the post lock
- 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.
proposed non-autosave edit_lock patch