[wp-trac] [WordPress Trac] #18950: get_post_types() does not return post-types registered with verbose alternatives of the $public argument

[WordPress Trac]

#18950: get_post_types() does not return post-types registered with verbose
alternatives of the $public argument
----------------------------+------------------------------
 Reporter:  fireproofsocks  |       Owner:
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Post Types      |     Version:  3.2.1
 Severity:  major           |  Resolution:
 Keywords:                  |
----------------------------+------------------------------
Changes (by Big Bagel):

 * cc: bigbagel@… (added)


Comment:

 This really isn't a defect since everything is working as it should.

 `$publicly_queriable`, `$show_ui`, `$show_in_nav_menus`, and
 `$exclude_from_search`, if not explicitly set, have their default values
 based on `$public`. This doesn't mean `$public` is simply a shortcut for
 the others. There isn't and there shouldn't be any "equivalence" between
 setting `$public` and the other four. If there were, what would happen if
 someone wanted to do this:

 {{{
 $args => array(
     'public' => false,
     'publicly_queriable' => true,
     'show_ui' => true,
     'show_in_nav_menus' => true,
     'exclude_from_search => false
  );
  register_post_type( 'my_custom_post_type', $args );
 }}}

 For example, I currently use a plugin that registers a new post type with
 these arguments:

 {{{
 $args => array(
     'public' => true,
     'show_ui' => false,
     'show_in_nav_menus' => false
  );
 }}}

 `$public` defaults to '''false''' and leaving it out will obviously result
 in the newly registered post type being excluded from the returned array
 when `get_post_types()` is explicitly told to return only those with
 `$public` set to '''true'''. If you want your post type to be returned
 when someone uses:

 {{{
 get_post_types( array( 'public' => true, '_builtin' => false ) );
 }}}

 Just make sure to set `$public` to '''true''':

 {{{
 $args => array(
     'public' => true,
     'publicly_queriable' => true,
     'show_ui' => true,
     'show_in_nav_menus' => true,
     'exclude_from_search => false
  );
  register_post_type( 'my_custom_post_type', $args );
 }}}

 Now, in respect to this as an enhancement/feature request, altering
 `register_post_type()` or `get_post_types()` to use `$public` as only a
 shortcut for the other four arguments would mean breaking or causing
 unexpected results for any code that already makes use of these functions
 while restricting the possibility of certain configurations (such as in my
 first two examples). Since I don't see any valid reason to break code
 simply because the purpose and proper use of the `$public` argument was
 misunderstood, I would suggest resolving this as wontfix or invalid.

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