id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,focuses 18950,get_post_types() does not return post-types registered with verbose alternatives of the $public argument,fireproofsocks,,"The $public argument for the '''register_post_type()''' function is supposedly an alternative for setting the arguments for publicly_queriable, show_ui, show_in_nav_menus, and exclude_from_search; It's true that setting the public argument does cause these other values to be set, but if you then use '''get_post_types()''' to query for public post-types, WP does not recognize the equivalence between setting the public option or verbosely setting the others. == To Reproduce: == Enter the following code into a plugin: {{{ function testing() { $args => array( 'publicly_queriable' => true, 'show_ui' => true, 'show_in_nav_menus' => true, 'exclude_from_search => false ); register_post_type('my_custom_post_type', $args); } add_action('init', 'testing'); }}} In a theme file (or somewhere after the init event): {{{ $pts = get_post_types( array('public'=>true, '_builtin'=>false) ); print_r($pts); // <-- empty! }}} == Expected Result == I would expect the get_post_types() function to return the '''my_custom_post_type''' post-type because it is using the equivalent of the $public argument. == Actual Result == No post-types are returned. This represents a problem: other plugins that interact with post-types often rely on the $public argument when using the '''get_post_types()''' function, so any plugin that attempts to verbosely set component attributes will not be recognized. This effectively breaks the API and trainwrecks the interconnectedness of the post-types. == See Also == See forum post: http://wordpress.org/support/topic/public-attribute-for-register_post_type?replies=5#post-2391689 WordPress 3.2.1 PHP 5.3.2",defect (bug),closed,normal,,"Posts, Post Types",3.2.1,normal,invalid,,,