WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In an attempt to speed up my query, I'm using the following arguments:

$args = array(
    'post_type' => 'product',
    'fields' => 'ids',

$query = new WP_Query($args);

While this does return an array of IDs as expected, I keep getting multiple Trying to get property of non-object in /wp-includes/query.php notices. This happens even when I have nothing inside my while other than the_post():

if ($query->have_posts()) : while ($query->have_posts()) : $query->the_post();

Is the_post() causing this? Any idea why I'm getting these notices?

share|improve this question
What's the fields entry? Never heard of that before. Does it work when you remove that? – geomagas Mar 10 '14 at 19:21
The fields => ids option returns an array of post ids rather than post objects, which (apparently) makes the query faster. – Dre Mar 10 '14 at 19:28
I see. That explains Milo's answer then (apparently)... – geomagas Mar 10 '14 at 19:30
up vote 4 down vote accepted

the_post places the next post object from $query->posts in the global $post and calls setup_postdata, which assumes $post is a post object, as it tries to access member vars of that object, which is where the errors come from.

In this case $posts is just an array of IDs instead of post objects. If you want to iterate over the results, you can do a foreach on $posts:

$args = array(
    'post_type' => 'product',
    'fields' => 'ids',
$query = new WP_Query($args);

if ($query->have_posts()):
    foreach( $query->posts as $id ):
        echo 'ID: ' . $id;
share|improve this answer
Spot on. The documentation for the_post() that I found didn't cover what it actually did in great detail, so I didn't realise it was attempting to access other vars. – Dre Mar 10 '14 at 19:37
While using 'fields' => 'ids' may be faster on the query, it still has to go and fetch each post individually one at a time, which ends up adding a 2+ queries per post instead of just 1 (to get meta when you need it). – Scott Kingsley Clark Jan 10 '15 at 2:20
I did however submit a ticket to Trac which could alleviate the object errors, but I wouldn't recommend it unless you have a huge object cache with each post already stored in it, but even then it's really not optimal. My ticket involves allowing setup_postdata ($wp_query->setup_postdata) to accept a Post ID, which would be handy if you only had IDs to work with. Still, getting IDs from a WP_Query 'fields' => 'ids' should be avoided at all costs if you intend to use WP template tags and/or get post data for all posts returned by WP_Query. core.trac.wordpress.org/ticket/30970 – Scott Kingsley Clark Jan 10 '15 at 2:26
If you did intentionally set posts_per_page to 1, I could see the ticket I've submitted could actually help you, because 'fields' => 'ids' would be quite quick, and the overhead is small if you have object caching enabled as the post may likely already be cached so get_post may actually be faster versus getting the full objects from the DB without 'fields' => 'ids' – Scott Kingsley Clark Jan 10 '15 at 2:28
@ScottKingsleyClark indeed, if you intend to use WP template tags and/or get post data for all posts returned by WP_Query then you're doing it wrong by using the fields argument. I assumed that OP just needed IDs and not full post objects. I thought that was reflected in the example code I provided, but perhaps I should have been more explicit. – Milo Jan 10 '15 at 2:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.