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

WordPress Trac wp-trac at lists.automattic.com
Sat Apr 14 20:06:42 UTC 2012


#12706: Custom post status bugs in the admin
-------------------------------------------------+-------------------------
 Reporter:  ptahdunbar                           |       Owner:  ptahdunbar
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Post Types                           |  Release
 Severity:  normal                               |     Version:
 Keywords:  has-patch westi-likes needs-testing  |  Resolution:
-------------------------------------------------+-------------------------

Comment (by benbalter):

 Replying to [comment:81 kevinB]:
 > Although custom moderation and private stati are clearly useful and mesh
 well with the existing post_status implementation, custom public stati
 seem questionable. Can anyone think of a scenario in which they would be
 beneficial?

 Anything that's not a blog post; that you don't "publish." If the final
 step of my workflow is "submitted" (think malange with applications) or
 "final" (think alfresco with press releases). If I'm a news organization
 and want to have a "breaking" post status at an intermediate step in my
 editorial process to display a teaser on the front-end. If I'm a car
 dealership (think autorader) and use my cars custom post type as either
 "available" (listed) or "sold" (not listed).  If I have a coupon site
 (think retailmenot) in which everything is either valid or expired.
 Anytime a post isn't a blog post. (not to mention it's kinda silly to
 abstract 2/3s and hard code 1/3 which makes building queries, etc. a bit
 less intuitive).

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


More information about the wp-trac mailing list