Make WordPress Core

Opened 12 years ago

Closed 12 years ago

#22687 closed defect (bug) (fixed)

auto-drafts are improperly stored as the first revision

Reported by: nacin's profile nacin Owned by: nacin's profile nacin
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.5
Component: Posts, Post Types Keywords: has-patch commit dev-reviewed
Focuses: Cc:


This came out of #22686 from maxcutler.

Steps to reproduce this bug:

  • Create a post.
  • Inspect its revisions. It should have two: [Current Revision] and one more. The earlier one is what would be listed in the meta box, so click it to see both.
  • Compare [Current Revision] with the original revision. This "original revision" is actually timestamped with the moment the post screen was entered and the auto-draft was created.

In 3.4, the comparisons are identical. In 3.5, the original revision has a post title of "Auto Draft". This was likely the result of WP_Post (#21309).

Note if you entered content before autosaved fired, it does not appear in the original revision either way. Only the title.

In 3.5, we should try to replicate 3.4's behavior and copy the title over.

In 3.6, we should try to avoid the initial auto-draft-base revision from being stored. It is misleading, especially since an auto-draft may stick around for a few days before being used (either via an open tab or an ID held by QuickPress). A revision can only happen to a post once it is saved, and auto-drafts don't count.

Attachments (1)

22687.diff (395 bytes) - added by nacin 12 years ago.
This is probably sufficient to block storing the initial auto-draft as a revision.

Download all attachments as: .zip

Change History (9)

#1 @nacin
12 years ago

#22686 was marked as a duplicate.

12 years ago

This is probably sufficient to block storing the initial auto-draft as a revision.

#2 @nacin
12 years ago

  • Keywords has-patch added

I added maxcutler's unit test in [UT1162]. 22687.diff blocks the initial revision from generating a revision (and passes the test). It was easier to do this than even start to investigate how WP_Post broke this.

I was curious what would happen to the Revisions meta box with 22687.diff. Simple: It doesn't appear. You need to save the post again to cause a revision and to get the meta box to show. This is the behavior prior to the introduction of auto-drafts, as I confirmed also in 2.9.

I thought that this bug didn't exist in 3.4, but it did. I've now been able to reproduce it in both 3.4 and 3.0. It seems autosave will fire given a few seconds (despite nothing hitting the editor), thus updating post_title.

So, this is definitely not a regression, and doesn't seem like WP_Post has any factor here at all. I suggest 3.6-early for 22687.diff.

#3 @nacin
12 years ago

  • Milestone changed from 3.5 to Awaiting Review

#4 @nacin
12 years ago

The only reason why this could be a 3.5 thing is XML-RPC now has new revision-fetching methods, and XML-RPC also uses auto-drafts (so it has a post ID to do operations). So, fixing this now could be nice for making that not lame.

#5 @markjaquith
12 years ago

  • Keywords commit added

Tested 22687.diff. Looks good.

#7 @nacin
12 years ago

  • Milestone changed from Awaiting Review to 3.5

#8 @nacin
12 years ago

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

In 22989:

Do not save an initial revision for a post created through the auto-draft mechanism. Prevents a bogus revision, often with the title 'Auto Draft'. Restores pre-auto-draft behavior made obvious by XML-RPC's implementation of both auto-drafts and the subsequent wp.getRevisions method. fixes #22687. see #22686.

Note: See TracTickets for help on using tickets.