WordPress.org

Make WordPress Core

Opened 12 months ago

Closed 12 months ago

Last modified 12 months ago

#24708 closed defect (bug) (fixed)

Extra revision created every time a new post is inserted

Reported by: wpdavis Owned by: nacin
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.6
Component: Revisions Keywords:
Focuses: Cc:

Description

In WordPress trunk, wp_insert_post creates an extra revision entry in the db. In addition to the actual row in the db for the post, there is a corresponding revision that seems unnecessary.

Change History (8)

comment:1 nacin12 months ago

  • Cc westi ethitter added
  • Milestone changed from Awaiting Review to 3.6

Someone else pointed this out to me too. This seems like it is proper behavior. In 3.6, we create a revision on edit, rather than on subsequent edit. This was in part to solve an off-by-one issue, and in part to make it more obvious what was going on with revisions.

That said, I'm not positive whether "create a revision on edit" should also occur for freshly created posts using wp_insert_post(). All UI-created posts are actually an edit, thanks to auto-drafts.

comment:2 SergeyBiryukov12 months ago

Introduced in [23842] for #16215 (see ticket:16215:76).

Last edited 12 months ago by SergeyBiryukov (previous) (diff)

comment:3 aaroncampbell12 months ago

  • Keywords close added

Seems like this is expected behavior and was necessary to completely fix our off by one issue (see Sergey's link to the appropriate comment on the other ticket).

comment:4 wpdavis12 months ago

  • Keywords close removed

Definitely understand the reasoning, but it seems kind of excessive to create an extra database entry for every post, especially since many posts are probably never edited in the future and then never needs a revision. It wreaks havoc on the WordPress import process (revisions are created for posts that didn't previously have revisions, screwing up the IDs and thus breaking the thumbnails).

What if the revision for the initial post is created under the following two scenarios:

  • The person posting the article != the person listed as the author of the article
  • When someone is editing an article after post, if a revision for the initial article does not exist.

(Putting in a separate ticket/patch for the importer bug)

comment:5 markjaquith12 months ago

I'm okay with reverting this and then recommending that automated processes work differently if they actually DO want that initial revision.

comment:6 nacin12 months ago

Based on a long IRC conversation, this should indeed be adjusted.

[23842] should be reverted. It restores current API behavior. While it will no longer create a revision for initial wp_insert_post() calls, the proper way to "prime" a post is with get_default_post_to_edit(), which is what core does in both UI and XML-RPC anyway.

Also, yes, wpdavis is right that this causes major importer headaches, as the import_ids don't align. We should have a unit test for that.

I'm working on updating unit tests and such to handle such a revert.

comment:7 nacin12 months ago

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

In 24650:

Don't store a revision for the initial call to wp_insert_post(), only on saves.

In core UI (and XML-RPC), we first create an auto-draft via get_default_post_to_edit(), which means the first "save" is in practice the first revision.

This reverts [23842].

fixes #24708.

comment:8 nacin12 months ago

In 1309/tests:

Rewrite revisions unit tests to account for [23842].

wp_insert_post() (and thus the factory) does *not* create a revision by default. When it is desired for the first "save" to be a revision, an auto-draft should be used.

The various cap-checking tests still use wp_insert_post() to test that route as well, hence the decrementing of revision counts.

see #24708.

Note: See TracTickets for help on using tickets.