Recycle auto-draft post entries

[MattyRob]

Currently in WordPress (3.2.1) it seems that visiting a post authoring page creates a row in the wp_posts table with a status of 'auto-draft'.

If an author then creates some content another row is added containing this content.

Periodically, WordPress then checks for these redundant auto-draft entries and after 7 days they are erased.

I presume that the auto-draft posts are in there for a good reason but why, when a user clicks on "save" or "publish" is the auto-draft row not recycled and the content added to the existing row with the auto-draft status being updated to draft.

[duck_]

Replying to MattyRob:

I presume that the auto-draft posts are in there for a good reason but why, when a user clicks on "save" or "publish" is the auto-draft row not recycled and the content added to the existing row with the auto-draft status being updated to draft.

The auto-draft row is "recycled". You may be seeing older auto-drafts which were not overwritten because you visited the post edit screen without saving or publishing anything.

QuickPress will always reuse auto-draft entries (only those created when visiting the dashboard) when possible.

[MattyRob]

@duck,

I was just digging deeper when you posted and confirmed what I had found. As you say if you visit the page and then leave an auto-draft is created. Do this repeatedly and you get repeated auto-draft creation. Personally, I think that is poor. It's not too hard to check for the presence of an auto-draft and use that rather than keep creating new ones.

A patch is on the way.

[nacin]

The issue is that there may be multiple users, or even multiple tabs open by the same user.

It's better to just generate a new ID every time we need it, and clean them up later, rather than deal with any side effects.

[MattyRob]

If there are multiple tabs or users is that not what the edit locks are for?

It may currently be better to create a new ID each time and clear up afterwards but it's not really a good solution. It's a workable solution that creates a problem that then needs tidied up.Surely there is a better way again.

[nacin]

I'm referring to multiple tabs for the same user, working on two different posts.

And then two different users writing at the same time.

Current patch will try to give all three the same auto-draft to use. That's not good.

I don't see a problem here, to be honest. We're just adding a few more rows to the DB that eventually get cleaned up. What's the bug?

[MattyRob]

Replying to nacin:

I'm referring to multiple tabs for the same user, working on two different posts.

Open one tab - hit Save Draft, open second tab. How many times has / does this scenario happen?

And then two different users writing at the same time.

As I said - what are the edit locks all about then if not for stopping 2 users editing at the same time - that's a really bad idea.

Current patch will try to give all three the same auto-draft to use. That's not good.

I don't see a problem here, to be honest. We're just adding a few more rows to the DB that eventually get cleaned up. What's the bug?

I haven't filed this as a bug but an enhancement - I'm saying it's sub-optimal adding multiple duplicate rows to a database table purely based on visiting the admin writing page for a split second and then moving on to then not re-use these table rows.

My proposal is simply this - it could be better (by reusing the table rows).

[nacin]

Replying to MattyRob:

Replying to nacin:
Open one tab - hit Save Draft, open second tab. How many times has / does this scenario happen?

More than never.

And then two different users writing at the same time.

As I said - what are the edit locks all about then if not for stopping 2 users editing at the same time - that's a really bad idea.

They're writing two different posts, I mean. Your patch doesn't restrict to the current author - author 2 would end up with author 1's auto draft. Even if we did restrict it by author, it's not *that* uncommon for someone to start on two posts at once. They can't be given the same auto-draft.

The original problem that auto-drafts solved were image attachments. So if someone attaches an image, then leaves, we can't recycle that auto-draft -- the image shouldn't just show up on the new, unrelated post.

It's not sub-optimal, it's the best possible implementation. No DB admin is going to be annoyed about a few extra rows.

[MattyRob]

Having been looking on the WordPress forum regarding how to disable auto-draft (not taking into account the auto-save and revision stuff) it does seem that your best possible solution is not entirely popular.

My proposal still stands that there must be a better way.

If some tags an image to an auto draft then let's expand the patch to check for that eventuality. Let's expand the patch to check for the author and if different create a new auto-draft.

I administer my own WP DB and I'm annoyed by the creation of redundant rows - maybe I have OCD but your assertion that is isn't annoying anyone is incorrect - firstly on my count and also based on other posters to your forum looking for ways to switch this 'feature' off.

I still suggest that the best possible implementation could be made better.

[MattyRob]

Attached patch is untested in the situations you describe about but should handle attachments and different authors.

[markjaquith]

MattyRob — the issue you originally reported is invalid — it's not true. Auto-drafts are used if you then go on to populate that post item. The only ones that are "wasted" are the ones that, after 7 days, have not been populated with data.

The issue with any sort of recycling is that you can't guarantee a lock. Who gets to recycle it? What if two requests try to recycle the same item? We have enough race conditions in WordPress. I'm not eager to introduce another.

Your objection seems to be an aesthetic objection to something that is fairly well abstracted. The rows are cleaned up, on a rolling basis. This is invisible to the user. Our audience is users, not people who peer at the database directly. The only lasting remnant is the incrementing of the post ID. We're still a ways off from risking hitting that limit of 2,147,483,647. I still haven't even hit 6 digits on my blog. Barely have hit 5.

Switching to this system solved a bunch of bugs, simplified our code, and has guaranteed that we'll never see a post-creation race condition. That's a real savings in terms of effort and frustration reduction. It'd take more than an aesthetic objection for us to consider compromising those gains.