[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