Extra revision created every time a new post is inserted

[wpdavis]

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.

[nacin]

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.

[SergeyBiryukov]

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

[aaroncampbell]

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).

[wpdavis]

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)

[markjaquith]

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

[nacin]

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.

[nacin]

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.

[nacin]

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.