[wp-trac] [WordPress Trac] #24415: The 'show_in_admin_all_list' argument for the 'register_post_status' function is ignored when the argument 'public' is set to 'false'

[WordPress Trac]

#24415: The 'show_in_admin_all_list' argument for the 'register_post_status'
function is ignored when the argument 'public' is set to 'false'
-------------------------------+------------------------------
 Reporter:  XyntaMan           |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  3.5.1
 Severity:  normal             |  Resolution:
 Keywords:  needs-patch        |     Focuses:  administration
-------------------------------+------------------------------

Comment (by landakram):

 Thanks XyntaMan!

 Replying to [comment:2 jessepollak]:

 It looks like the difference between `protected` and `private` is that
 post statuses with `protected => true` require `edit_post` capabilities to
 display, while post statuses with `private => true` require only
 `view_post` capabilities (from
 [https://core.trac.wordpress.org/browser/tags/3.8.1/src/wp-
 includes/query.php#L2982 query.php]).

 Looking at [https://core.trac.wordpress.org/browser/tags/3.8.1/src/wp-
 includes/post.php#L916 post.php], it also seems that `public`,
 `protected`, and `private`, are ''not'' mutually exclusive, at least in
 the code. In other words, it's possible to specify

 {{{
 register_post_status( 'test_status', array(
     'label'                     => _x( 'Test Status', 'post' ),
     'public'                    => true,
     'private'                   => true,
     'protected'                 => true,
     'exclude_from_search'       => false,
     'show_in_admin_all_list'    => true,
     'show_in_admin_status_list' => true,
     'label_count'               => _n_noop( 'Unread <span
 class="count">(%s)</span>', 'Unread <span class="count">(%s)</span>' ),
 ));
 }}}

 and the custom post status will be saved just fine. When a post is queried
 for, `public` is checked for first, then `protected`, then `private`, so
 if `public => true`, then the other fields are irrelevant (and if
 `protected => true`, then `private` is irrelevant).

 It seems to me that if `public` is `null` or `false`, then at the very
 least `private` should be set to `true` by default. This way,  If someone
 wants to require `edit_post` capabilities to display a post, then they can
 explicitly specify `protected => true`. I also think `protected` and
 `private` should be added to the codex :)

 This would also allow the posts to be shown in the default post listing,
 due to the third block of code in jessepollak's comment above (from
 [https://core.trac.wordpress.org/browser/tags/3.8.1/src/wp-
 includes/query.php#L2778 query.php]).

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