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

[Chris Jean]

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