#21858 closed defect (bug) (fixed)
Autosave does not work when a draft post has a time in the future
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 3.5 | Priority: | normal |
| Severity: | critical | Version: | 3.4.2 |
| Component: | Autosave | Keywords: | has-patch needs-testing |
| Focuses: | Cc: |
Description
Something has gone horribly wrong since I upgraded to 3.4.2 (from 3.1.4). I just lost a very long post because the editor said it was saved. It lied to me! I returned a few hours later to discover that there was nothing new in the database since the last time I clicked the Save Draft button.
I figured it was just me, so I went back into the post, added the word "testing" at the end, waited a few seconds for the auto save, then exited the editor. I returned again to find that, in fact, auto save has completely failed. :~(
I will follow up with any particular test cases I can find.
Attachments (2)
Change History (18)
#2
@
13 years ago
I'm finding extreme inconsistency between other cases.
If I set a post status to Pending Review, abandon changes, and return, WordPress tells me "There is an autosave of this post that is more recent than the version below."
If I set a post visibility to Private, abandon changes, and return, WordPress has discarded the previous draft, overwritten it with the auto save draft, and reset the visibility to Public.
Password-protected posts similarly revert to Public if the Save Draft button was never clicked by the user.
If I create a public draft, click Save Draft, make changes and abandon them, WordPress discards the saved draft, and overwrites it with the auto save. (This is a known bug, I've reported it before.)
So far the only blocker is with scheduled post drafts not saving at all.
#3
@
13 years ago
Same bug reproduced in version 2.9.2. Has this been broken for that long? More testing is needed on recent branches.
#5
@
13 years ago
Patch attached. It fixes the bug. There is some needed jQuery stuff that will be out of my hands. I just don't know that language.
#6
@
13 years ago
That doesn't seems as a good way to solve the issue. The code is there for a reason.
#8
@
13 years ago
- Keywords needs-patch removed
Debug Findings
Algorithmic Faults:
wp-admin/includes/post.php @ 161
post_date_gmt is the wrong field for checking when the last save occurred.
($now - $then) is missing a call to abs(). $then may be larger than $now, causing the return condition to be true.
Flow of Control Faults:
wp-admin/includes/post.php @ 168
The function edit_post() fails at this point for all scheduled posts and returns to function wp_ajax_autosave().
wp-admin/includes/ajax-actions.php @ 1091
Function wp_ajax_autosave() assigns the return value to $id on the assumption that the post was already saved, and performs no relevant checks for success or failure before sending the "Draft saved at" ajax response to the client.
Code History
The ($now - $then) phrase exists in post.php as far back as version 2.3.
I was able to reproduce the autosave failure in version 2.5.
@
13 years ago
Finished patch after clarifying the errant code will be fixed in PHP rather than moving it to JS.
#9
@
13 years ago
- Keywords has-patch added
- Milestone changed from Awaiting Review to 3.5
- Severity changed from blocker to critical
- Summary changed from Auto Save Does Not Work to Autosave does not work when a draft post has a time in the future
#11
@
13 years ago
Looks like the whole thing was to prevent collisions from the days of negative draft IDs. See #3601. This should be able to completely disappear, as in miqro-21858-autosave.patch.
Tested several times. Even disabled all plugins and switched to the 2011 theme. It remains broken.
Steps to reproduce: