[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 nacin):

 I think there are two very different ways to approach this. I don't think
 they are mutually exclusive, but they are different worlds in complexity
 and approach.

 1. A custom post status is nothing more than an alias/rename/copy of an
 existing status.

 A status like "Sent to Editor" is really just "pending" under the hood. Or
 a status like "Active" is really just "publish". There is no "expired"
 post status in WordPress, so "Inactive" doesn't translate directly to any
 existing status, but it's more or less "trash".

 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?

 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?

 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.

  2. A custom post status API requires us to tackle the world of
 transitions. It's not just that a post can be one of X statuses, it's that
 based on the current status, and the current ''user'', it can be
 promoted/demoted to one of X statuses.

 Does that mean `current_user_can( 'transition_post', $post_id, $new_status
 )`? Probably. And you'll note that if $new_status = 'publish', then this
 is basically just `current_user_can( 'publish_post', $post_id )` — see, we
 already have a publish_posts capability to extrapolate from. Now someone
 could implement fine-grained control, without us getting into the workflow
 business. Maybe.

 While a concept like transition_post can handle authorization, it doesn't
 necessarily handle UI options. Given status A, what statuses can you go
 to? How does that change affect its spot in a pending moderation queue? Or
 is it considered "draft"? Or is it considered published? Do we have to
 implement something like Trac's ticket status workflow? (It's kind of
 insane, but [http://trac.edgewall.org/wiki/TracWorkflow here's a primer].)

 What does a custom post status actually mean? I don't know -- I've been
 thinking about this for four years and still don't have an answer.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/12706#comment:183>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress blogging software