WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#11889 closed task (blessed) (fixed)

Create post with special post_status when viewing Add New screen

Reported by: markjaquith Owned by: 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 4 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 4 years ago.
second try
11889-3.diff (1.6 KB) - added by azaozz 4 years ago.
Perhaps something like this
11889.4.diff (524 bytes) - added by rovo89 4 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 markjaquith4 years ago

  • Status changed from new to accepted

I'll take this one.

comment:2 Denis-de-Bernardy4 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:

comment:3 follow-up: westi4 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.

comment:4 scribu4 years ago

  • Cc scribu@… added

comment:5 in reply to: ↑ 3 Denis-de-Bernardy4 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?)

comment:6 Denis-de-Bernardy4 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.

comment:7 Denis-de-Bernardy4 years ago

  • Keywords bug-hunt added

comment:8 Denis-de-Bernardy4 years ago

  • Keywords featured added; bug-hunt removed

comment:9 scribu4 years ago

Related: #11990

markjaquith4 years ago

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

markjaquith4 years ago

second try

comment:10 markjaquith4 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

comment:11 follow-up: markjaquith4 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.

comment:12 ryan4 years ago

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

comment:13 follow-up: azaozz4 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.

azaozz4 years ago

Perhaps something like this

comment:14 in reply to: ↑ 11 azaozz4 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.

comment:15 miqrogroove4 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.

comment:16 in reply to: ↑ 13 scribu4 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.)

comment:17 scribu4 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).

comment:18 rovo894 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.

rovo894 years ago

comment:19 scribu4 years ago

  • Keywords has-patch added

comment:20 ryan4 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.

comment:21 rovo894 years ago

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

comment:22 nacin3 years ago

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

comment:23 nacin3 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.