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

WordPress Trac wp-trac at lists.automattic.com
Tue Oct 12 05:48:04 UTC 2010


#12706: Custom post status bugs in the admin
----------------------------+-----------------------------------------------
 Reporter:  ptahdunbar      |       Owner:  ptahdunbar 
     Type:  task (blessed)  |      Status:  new        
 Priority:  normal          |   Milestone:  3.1        
Component:  Post Types      |     Version:             
 Severity:  normal          |    Keywords:  needs-patch
----------------------------+-----------------------------------------------

Comment(by kevinB):

 Replying to [comment:26 ptahdunbar]:
 >
 > I'm not exactly 100% sure on how public, private, and protected work in
 terms of what functionality they add outside of what's in the
 post_submit_meta_box() metabox.
 >  * public
 >  * private
 >  * protected
 >  * internal
 >
 '''public''' stati are published and readable by default to all logged and
 anonyomous users (an abstraction of the "publish" status).

 '''private''' stati are published but readable based on possession of the
 appropriate capability (an abstraction of the "private" status).

 '''protected''' means a status is not currently readable to any user on
 the front end, except for previews.

 '''internal''' means never readable on the front end, post are not set to
 it by "normal" wp-admin UI, and is not included in wp-admin post filtering
 unless specified (show_in_admin_status_list)

 My patch includes another proposed status type:
 '''moderation''' means a status is part of an editorial moderation
 process.  Not readable on the front end, except for previews (an
 abstraction of the "pending" status).

 ----

 >
 > And finally post status capability. Can anyone elaborate how this should
 work?
 >

 If the existing pattern is followed, capabilities for custom stati would
 be specified by setting
 {{{
 $type_object->cap->edit_{$status}_posts = ...
 $type_object->cap->delete_{$status}_posts = ...
 }}}

 ... and if the status is of private type:
 {{{
 $type_object->cap->read_{$status}_posts = ...
 }}}

 In addition, there is a need for a "publish" capability specific to custom
 public, private and moderation stati:
 {{{
 $type_object->cap->set_{$status}_posts = ...
 }}}

 If there is sentiment for a different model such that
 $type_obj->status_cap is a status-keyed array property, now is the time.
 Thoughts?

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


More information about the wp-trac mailing list