Create post with special post_status when viewing Add New screen

[markjaquith]

So many things would be easier if we had a post ID in hand when generating the Add New X screens. The previous concern has been ID inflation, but post revisions have already crossed that bridge.

The plan:

1. Auto-create a draft with a special status when entering Add New screen
2. Update status to regular draft upon autosave or manual save
3. Garbage collect old auto-drafts after x days
4. Use XHR "ping" to prevent auto-draft from being deleted out from under an edit window that has been sitting around for a long time (icing)

#11145 would be fixed by this, as would several other bugs. In addition, we could remove all the JS code that updates all the post IDs on the first autosave, etc.

[markjaquith]

I'll take this one.

[Denis-de-Bernardy]

@Mark: there is a much better solution for this one. It is to use a proper UUID in the post_guid field. I'll write a post about it in WP devel next week.

Related: #11145, #9471, #6492

And see:

• ​http://core.trac.wordpress.org/ticket/9471#comment:19
• ​http://core.trac.wordpress.org/ticket/9471#comment:23

[westi]

I like Marks idea.

Creating the post in the db in get_default_post_to_edit() as a auto-draft of whatever $post_type which will then get an ID

We can then clear up old ones using cron like we do to empty trash.

I'm not sure how using s UUID in the post_guid field affects this solution and how it improves on using the post_id.

[Denis-de-Bernardy]

Replying to westi:

I'm not sure how using s UUID in the post_guid field affects this solution and how it improves on using the post_id.

It improves over a post_id in that a universally unique ID is designed for this kind of stuff. It allows you to dynamically create a number that is essentially guaranteed to be unique. You can then do things such as:

• change a post's permalink, and re-use its old permalink, without confusing feed readers and the like
• assign a UUID to a draft, knowing that it's guaranteed to be unique -- you can then query the posts table on the fly to know if it has been created by a separate process or not.
• have two completely separate databases whose data you can merge later on, without any risk of conflict (I can't possibly be the only one who gave thoughts to creating an offline editor for WP, can I?)

[Denis-de-Bernardy]

rephrasing the draft part above, this means that you can simply run wpdb->query(SELECT UUID();) when you start writing a draft, and voila, you've something that you can toss around in windows and thickboxes and who knows what. As long as it's passed, you know it's all about the same post. no need for a special status, no need for a cron to clean up garbage. it just works.

[scribu]

Related: #11990

[markjaquith]

Create auto drafts with post_status = 'auto-draft'. Clean up old ones when creating.

[markjaquith]

second try

[markjaquith]

(In [12987]) Create post_status=auto-draft when creating a new post item. status changes to draft on first auto-save. now we always have a real post ID to work with. see #11889. fixes #11145. fixes #11990

[markjaquith]

1. creates a post with post_status=auto-draft
2. First auto- or manual save turns it into a real draft
3. when auto-drafts are created, it deletes ones older than one week
4. you now always have a post ID on the post edit screen, which fixes all those attachment- and meta-related bugs. No more fetching new nonces. No more negative post IDs.

There are two areas I was confused about, which could use another look. The auto-save collision code in wp_write_post(). I left it how it was... keying off of $temp_ID. Not sure how to update this.

[ryan]

(In [12992]) Register the auto-draft post status. see #11889

[azaozz]

We need this on the dashboard for QuickPress and in PressThis (to fix the weird workaround there).

With this patch we are creating new 'Auto Draft' every time a user visits the Add New post screen and cleaning the old after a week. When we add it to QuickPress and PressThis, on blogs with many users that can amount to several thousands "started" posts easily.

In #9471 I was thinking we can have a permanent auto-draft for each user that will be opened when loading either Add New, the dashboard or QuickPress and created if it doesn't exist (i.e. was published). This would also resolve some of the collision problems. We can auto-delete these drafts after a week or a month too.

[azaozz]

Perhaps something like this

[azaozz]

Replying to markjaquith:

There are two areas I was confused about, which could use another look. The auto-save collision code in wp_write_post()...

The whole system with $temp_ID should be redundant now, any 'relocate_children' code too as we have a "real post ID" from the very beginning and all attachments have the correct parent.

[miqrogroove]

Post counting needs to be updated. On Edit Posts I'm seeing "All (4) | Published (2)". On #11914 I'm just fumbling around with what to put in the WHEREs.

[scribu]

Replying to azaozz:

In #9471 I was thinking we can have a permanent auto-draft for each user that will be opened when loading either Add New, the dashboard or QuickPress and created if it doesn't exist (i.e. was published). This would also resolve some of the collision problems. We can auto-delete these drafts after a week or a month too.

I was thinking of something similar: Always have an auto-draft for each user. Create a new one only when the author has "used" the current one (saved, published etc.)

[scribu]

If we go with permanent auto-drafts, a user should be notified if he was trying to create a new post using an old auto-draft (although this would rarely happen).

[rovo89]

Updating the status to "draft" seems to work fine for autosave, where it is set explicitly. It works fine as well for manual "Save Draft", but only if the user has publishing capabilities. Otherwise, the combobox for changing the post_status (which defaults to "draft") is not included in the HTML and thus missing in the POST data.

So if e.g. a Contributor creates a new post, types some words into the editor, clicks "Save Draft" and navigates to the list of posts, this post will be missing as it still has post_status "auto-draft". This does not happen if the user fills in the title, as the post will be autosaved upon leaving the title input field. Considering that custom post types might hide the title input field and users might disable Javascript, I think this should be fixed.

I'm attaching a patch which adds a hidden post_status field with the value "draft" for non-publishers. Another option might be to explicitly set the post_status to "draft" if it was "auto-draft" before and no post_status was passed in the POST data.

[ryan]

The issue noted by rovo89 should be fixed now. Closing. Open new tickets for further issues.

[rovo89]

I can confirm that the problem I described above no longer occurs.

[nacin]

[12991] had a logic issue that went unnoticed for quite a while. Resulted in #18642.

[nacin]

In [18709]:

Fix issue where post locks were not updating on autosaves. props benbalter, fixes #18642. see #18515 for more on locking. broken in [12991], see #11889.