[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:
     Type:  task (blessed)                       |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
Component:  Posts, Post Types                    |  Release
 Severity:  normal                               |     Version:  3.0
 Keywords:  has-patch westi-likes needs-testing  |  Resolution:
  needs-unit-tests editorial-flow                |     Focuses:
-------------------------------------------------+-------------------------

Comment (by MikeSchinkel):

 Replying to [comment:215 johnjamesjacoby]:
 > bbPress has a few custom statuses:
 > ...
 > These are basically `states` that a forum/topic/reply will find
 themselves in based on different criteria, and a moderator can force a
 state if they wish.
 >
 > A state is really a collection of properties, not dissimilar to how
 roles have capabilities, and these properties need an easy way to build
 database queries and limit their visibility.

 Agreed.

 Several solutions come to mind:

 1. Implement like Roles & Capabilities via the `wp_options` table -- Doing
 it this way will force rigid states to roles -- not a good thin IMO -- and
 requires writing to the DB so should be done on a plugin activation, which
 does not work well for Git-based auto-deployments.
 2. Implement them using a `register_post_state()` function that
 streamlines and simplifies add custom states since they would not need to
 be stored in the database, but this is also rigid.
 3. Add  a built-in `'post_states'` taxonomy listing statuses and their
 respective states as child terms. This would allow users to be able to
 select a status for a post, or alternatively drill down and select just
 specific states for a post. The downside is that this is harder to specify
 in code because we need to make sure the statues and states are written to
 the taxonomy  so should be done on a plugin activation, which does not
 work well for Git-based auto-deployments.
 4. Do #2 but store the states in postmeta fields with a key format maybe
 like `'_states:publish:is_public'` and a value of 1, and allowing the
 users to specify individual states per post as in #3.

 Seems like what is needed for this would be a good list of use-cases in a
 central place (Google Sheet?) and both their statuses and respective
 states?

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