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

 I'm intrigued by @johnjamesjacoby suggestion for more complicated post
 statuses, but I worry about whether that's feasible without a substantial
 rewrite of the query structure. Currently, `post_status` is a simple query
 parameter: find posts with X status. I have no idea how to construct a
 query for "open message boards" that dynamically close 90 days after
 inactivity without having to do a lot of ugly query modifications on the
 fly.

 In my mind, post status is about visibility: who can see the post, and in
 what contexts (admin, frontend, REST, in a custom query for a frontend
 element, etc.) As far as I can tell, that framework meets the needs of
 almost every use case proposed in this thread, from releases to coupon
 codes to breaking news to moderation. The one case I don't know if it
 covers sufficiently is handling revisions to an already-published content
 that are saved in progress but don't update the original yet (see comment
 115 above).

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