Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#11889 closed task (blessed) (fixed)

Create post with special post_status when viewing Add New screen

Reported by: markjaquith's profile markjaquith Owned by: markjaquith's profile markjaquith
Milestone: 3.0 Priority: high
Severity: normal Version: 3.0
Component: Autosave Keywords: has-patch featured
Focuses: Cc:

Description

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.

Attachments (4)

auto-draft.diff (31.6 KB) - added by markjaquith 14 years ago.
Create auto drafts with post_status = 'auto-draft'. Clean up old ones when creating.
auto-draft.002.diff (34.5 KB) - added by markjaquith 14 years ago.
second try
11889-3.diff (1.6 KB) - added by azaozz 14 years ago.
Perhaps something like this
11889.4.diff (524 bytes) - added by rovo89 14 years ago.

Download all attachments as: .zip

Change History (27)

#1 @markjaquith
14 years ago

  • Status changed from new to accepted

I'll take this one.

#2 @Denis-de-Bernardy
14 years ago

@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:

#3 follow-up: @westi
14 years ago

  • Cc westi added

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.

#4 @scribu
14 years ago

  • Cc scribu@… added

#5 in reply to: ↑ 3 @Denis-de-Bernardy
14 years ago

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

#6 @Denis-de-Bernardy
14 years ago

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.

#7 @Denis-de-Bernardy
14 years ago

  • Keywords bug-hunt added

#8 @Denis-de-Bernardy
14 years ago

  • Keywords featured added; bug-hunt removed

#9 @scribu
14 years ago

Related: #11990

@markjaquith
14 years ago

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

@markjaquith
14 years ago

second try

#10 @markjaquith
14 years ago

(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

#11 follow-up: @markjaquith
14 years ago

  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.

#12 @ryan
14 years ago

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

#13 follow-up: @azaozz
14 years ago

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
14 years ago

Perhaps something like this

#14 in reply to: ↑ 11 @azaozz
14 years ago

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.

#15 @miqrogroove
14 years ago

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.

#16 in reply to: ↑ 13 @scribu
14 years ago

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

#17 @scribu
14 years ago

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

#18 @rovo89
14 years ago

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.

@rovo89
14 years ago

#19 @scribu
14 years ago

  • Keywords has-patch added

#20 @ryan
14 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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

#21 @rovo89
14 years ago

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

#22 @nacin
13 years ago

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

#23 @nacin
13 years ago

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.

Note: See TracTickets for help on using tickets.