[wp-hackers] wp_query gets poisoned by new WP_Query objects

Chris Jean gaarai at gaarai.com
Thu Oct 8 22:34:13 UTC 2009


Yup. query_posts() is much simpler and bypasses the problems you didn't
want to deal with. You can always run wp_reset_query() after you are
done with your custom loop to set $wp_query and all the associated data
back.

Chris Jean
http://gaarai.com/
http://wp-roadmap.com/
http://dnsyogi.com/



Luke Gallagher wrote:
> Thanks for the feedback guys.
>
> The reason I was cloning $wp_query was for connivence so I didn't have
> to do $new_query->have_posts() etc. query_posts will give me the
> connivence benefit anyway.
>
> After reading the advice from both of you it seems that I should just
> be using query_posts.
>
> Thanks for your help.
>
>
>
> 2009/10/9 Chris Jean <gaarai at gaarai.com>:
>   
>> There's nothing wrong with the code. The problem is your logic.
>>
>> In short, you are latching state tracking code in the wrong place. I did
>> the following, and both methods matched:
>>
>>    // page.php
>>    ...
>>    $wp_query = new WP_Query('cat=1&showposts=' . get_option('posts_per_page') . '&paged=' . $paged);
>>    apply_filters( 'show_data', '' );
>>    ...
>>
>>    // functions.php
>>    ...
>>    add_filter('show_data', 'default_join');
>>    ...
>>
>> The problem is that the is_404(), etc functions are using the $wp_query
>> variable to do their thing. The first set of code runs these checks
>> before the constructor finishes. This means that your new $wp_query
>> variable has not been initiated yet, thus the old $wp_query variable is
>> being checked, not your new one. The second one works because you first
>> update the $wp_query variable with the new instance and then run the
>> code that launches the checks.
>>
>> The way the code worked was the same in all of your code examples. The
>> only thing that differed was how you viewed the data.
>>
>> My changes viewed the data after the constructor had finished and the
>> variable had been updated with the new instance. Thus, all query methods
>> worked as expected.
>>
>> As Otto said, just use the query method. It's easier, quicker, and makes
>> the way the code operates easier to understand (case in point).
>>
>> Chris Jean
>> http://gaarai.com/
>> http://wp-roadmap.com/
>> http://dnsyogi.com/
>>
>>
>>
>> Luke Gallagher wrote:
>>     
>>> While working with Wordpress I found some odd behaviour, and before I
>>> continue to get this patched I am wondering if anyone can verify that
>>> this is actually bug or if it is the intended behaviour of Wordpress.
>>>
>>> Here is a previous bug that may be related:
>>> http://core.trac.wordpress.org/ticket/9854
>>>
>>> I have verified that the following is the case for the current
>>> checkout of the Wordpress core.
>>>
>>> If I create a custom wp_query object in the default theme's page.php
>>> file, right after get_header() like so:
>>> http://gist.github.com/204994
>>>
>>> and I have a posts_join filter in
>>> /wp-content/themes/default/functions.php that prints out to the
>>> error_log what type of request this is. ( I also tried this out with
>>> posts_where and pre_get_posts with the same results )
>>>
>>> Loading the about page in the web browser I get the following in error
>>> log:
>>>
>>> is_page
>>> is_singular
>>> -------
>>> is_page
>>> is_singular
>>> -------
>>>
>>>
>>> But if I do it this way I get:
>>> http://gist.github.com/204996
>>>
>>> is_page
>>> is_singular
>>> -------
>>> is_archive
>>> is_category
>>> -------
>>>
>>>
>>> I would think that the latter result is the correct behaviour, should
>>> be so in the first instance.
>>>
>>> Using query_posts instead in the same situation works:
>>> http://gist.github.com/205004
>>>
>>> is_page
>>> is_singular
>>> -------
>>> is_archive
>>> is_category
>>> -------
>>>
>>> So should I just be using query_posts in this context?
>>> Is there something that I'm missing here?
>>>
>>> thanks,
>>>
>>> Luke
>>>
>>>
>>>
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>       
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>     
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>   


More information about the wp-hackers mailing list