WordPress.org

Make WordPress Core

#22687 closed defect (bug) (fixed)

auto-drafts are improperly stored as the first revision

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

Description

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 17 months ago.
This is probably sufficient to block storing the initial auto-draft as a revision.

Download all attachments as: .zip

Change History (9)

comment:1 nacin17 months ago

#22686 was marked as a duplicate.

nacin17 months ago

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

comment:2 nacin17 months 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.

comment:3 nacin17 months ago

  • Milestone changed from 3.5 to Awaiting Review

comment:4 nacin17 months 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.

comment:5 markjaquith17 months ago

  • Keywords commit added

Tested 22687.diff. Looks good.

comment:7 nacin17 months ago

  • Milestone changed from Awaiting Review to 3.5

comment:8 nacin17 months 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.