[wp-trac] [WordPress Trac] #12706: Custom post status bugs in the admin

[WordPress Trac]

#12706: Custom post status bugs in the admin
-------------------------------------------------+-------------------------
 Reporter:  ptahdunbar                           |       Owner:  ptahdunbar
     Type:  task (blessed)                       |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Post Types                           |  Release
 Severity:  normal                               |     Version:  3.0
 Keywords:  has-patch westi-likes needs-testing  |  Resolution:
  needs-refresh needs-unit-tests editorial-flow  |
-------------------------------------------------+-------------------------

Comment (by MikeSchinkel):

 Replying to [comment:183 nacin]:
 > So, we should build something that simply allows you to declare a new
 status with a few basic flags that make it mimic the functionality of an
 existing status. If you're building out a proper workflow, is  "For Copy
 Editor Review" really anything different than "Pending" other than the
 name?

 So I assume that an existing status could be aliased multiple times?

 Then, would the aliased status be stored in the `post_status` field
 ''(i.e. `'4ce_review'`)'' or would `'pending'` still be stored and if so
 how would the `"For Copy Editor Review"` be associated?  Also, how would
 developers be able to implement efficient SQL queries to retrieve just the
 posts for a given alias status when there are multiple aliases for the
 same existing status, i.e. as ''"For Tech Review"'' might also be a
 legitimate `'pending'` status?

 As for flags, I scanned through core's source code and it seems that some
 of the use of status is specific to status, i.e. omit `'trash'` posts in a
 list of posts unless displaying the list of items in trash.  But other
 uses of status seem to point to what a given status implies, or more
 importantly what all other statuses imply.  This leads me to think that a
 ''"Post Status Supports"'' concept would make sense, and here are some of
 the one's I quickly identified:
 {{{
 post_status_supports( 'revisions' )
 post_status_supports( 'sample_permalink' )
 post_status_supports( 'last_edited' )
 post_status_supports( 'editing' )
 post_status_supports( 'editing_attachment' )
 post_status_supports( 'commenting' )
 }}}

 With a `post_status_supports()` function it would seem we could evolve a
 lot of the code in core and in plugins that operate on happenstance
 related to statues and actually focus on the thing matters.  With this
 approach and a relate filter hook plugin and themes could add their own
 statuses ''(or status aliases, however it plays out)'' and if they want
 their status to support editing but not revisions, then so be it.

 > And at that point, I begin to wonder if an actual "aliases" API is most
 helpful. And if a post is pending review ("Pending"), who is it pending
 review for? Is it really necessary to have a separate "status" for each
 desk a post needs to reach (I'm thinking newsroom, but you can probably
 extrapolate this for other workflows), or is it just a piece of metadata
 tied to the post that allows us to say "oh yes, it is assigned to Helen
 for review". It's still "Pending", so does it really matter what its
 status is?

 Actually with an addition of `post_status_supports()` I think aliases
 might be of less interest and frankly, aliases are less WordPress-ish. It
 would be similar to how post types can be extended with
 `post_type_supports()` and how we don't really depend on custom post types
 to be aliases of `'post'` or `'page'`.  So instead of trying to shoehorn
 new potential use-cases into our existing known use-cases we can instead
 focus not on the status itself but the individual behaviors that each
 existing status implies and this support emergent use-cases we'd not
 previously realized.

 > So, very simply, I've yet to see some solid use cases of custom post
 statuses that aren't just renames/aliases of existing functionality.

 I'm not sure lack of evidence is sufficient to prove lack of existence.
 Even so, by writing code to test ''"if a post status supports revisions"''
 rather than ''"if it's neither `'auto-draft'` and `'draft'`"'' should
 allow for us to write more robust plugins and themes that are more
 resilient to change ''and'' the bonus is they would support valid custom
 post status use-cases if and when those use-cases emerge.

 All that said, it's already possible to add new custom post status and
 because of that more than a few people have been using
 `ob_start()`/`ob_end_clean()` to enable them in the admin, or they've
 written custom metaboxes to support it. Thus adding the ability to also
 automatically display these custom post statuses will do no ''"harm"'' as
 there are custom post statuses in the wild within many WordPress
 databases, and they have survived without core's workflow supporting them.
 **Why not at least close the loop on this and let us add in custom post
 statuses into the post add/edit UI** while we wait on a better solution?
 And if not automatically, why not at least give us a filter hook so we can
 accomplish it without writing fragile hacked code?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/12706#comment:186>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform