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

[Luke Gallagher]

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
>