WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#21858 closed defect (bug) (fixed)

Autosave does not work when a draft post has a time in the future

Reported by: miqrogroove Owned by: nacin
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)

miqro-21858-autosave.patch (730 bytes) - added by miqrogroove 8 years ago.
Autosave bug located and fixed.
miqro-21858-autosave.2.patch (1.6 KB) - added by miqrogroove 8 years ago.
Finished patch after clarifying the errant code will be fixed in PHP rather than moving it to JS.

Download all attachments as: .zip

Change History (18)

#1 @miqrogroove
8 years ago

  • Keywords needs-patch needs-testing added

Tested several times. Even disabled all plugins and switched to the 2011 theme. It remains broken.

Steps to reproduce:

  1. Add New Post
  2. Enter any title and body.
  3. Click the Edit link next to "Publish immediately".
  4. Set a future date such as Oct 1.
  5. Click OK.
  6. Click Save Draft.
  7. Modify the post body in some obvious manner.
  8. Wait for the status to indicate "Draft saved at ..."
  9. Exit the post editor without clicking the Save Draft button.
  10. Go back to All Posts and click Edit for the same post.
  11. Observe that the post body has not been auto saved.
  12. Walk away from computer in disgust.

#2 @miqrogroove
8 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 @miqrogroove
8 years ago

Same bug reproduced in version 2.9.2. Has this been broken for that long? More testing is needed on recent branches.

@miqrogroove
8 years ago

Autosave bug located and fixed.

#5 @miqrogroove
8 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 @markoheijnen
8 years ago

That doesn't seems as a good way to solve the issue. The code is there for a reason.

#7 @miqrogroove
8 years ago

It is a stop gap patch at this point and it is being discussed in IRC.

#8 @miqrogroove
8 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.

@miqrogroove
8 years ago

Finished patch after clarifying the errant code will be fixed in PHP rather than moving it to JS.

#9 @nacin
8 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

#10 @miqrogroove
8 years ago

Hi nacin, thanks for the milestone!

#11 @nacin
8 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.

#12 @nacin
8 years ago

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

In [21949]:

Remove old autosave collision code from edit_post(). props miqrogroove.

This code, which could block autosaves when drafts had future timestamps,
dates to before autosaves were saved as revisions and is no longer necessary.

fixes #21858.

#13 @nacin
8 years ago

I also chatted with mdawaffe before [21949]. We both agreed it could go.

#15 @miqrogroove
8 years ago

nacin: This should be a 3.4.3 item as well.

#16 @SergeyBiryukov
8 years ago

Minor releases are for security and regression fixes only. According to comment:3, this is not a regression in 3.4.

Note: See TracTickets for help on using tickets.