[wp-trac] [WordPress Trac] #27507: get_posts() not honoring post_status criteria

WordPress Trac noreply at wordpress.org
Tue Mar 25 05:49:54 UTC 2014


#27507: get_posts() not honoring post_status criteria
-------------------------------+-----------------------------
 Reporter:  Denis-de-Bernardy  |      Owner:
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Query              |    Version:  3.8.1
 Severity:  normal             |   Keywords:
  Focuses:  docs               |
-------------------------------+-----------------------------
 Toss in the following in a mu-plugin file to reproduce:

 {{{
 $posts = get_posts();
 var_dump($posts);
 }}}

 You'll get auto-drafts in the returned result set, instead of the expected
 published posts only (i.e. the default as set by `get_posts()`).

 I've traced the problem to this loop that calls `get_post_stati()` in the
 `WP_Query#get_posts()` method:

 {{{
 foreach ( get_post_stati() as $status ) {
         if ( in_array( $status, $q_status ) ) {
                 if ( 'private' == $status )
                         $p_status[] = "$wpdb->posts.post_status =
 '$status'";
                 else
                         $r_status[] = "$wpdb->posts.post_status =
 '$status'";
         }
 }
 }}}

 `get_post_stati()` latter relies on a global that isn't set yet. I'm
 suspicious that we should be calling it here to begin with. Assuming we
 should, I definitely don't think WP should silently return an empty array.
 It should cough a `_doing_it_wrong()` notice, and quite possibly even a
 warning.

 That being said: why aren't the built-in post statuses registered by the
 time plugins get loaded? Can't we register them earlier? (And: does the
 same apply to custom post types?)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27507>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list