[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