[wp-hackers] pre_get_posts problem

[Andrew Nacin]

On Sat, Jul 24, 2010 at 5:22 AM, Michael D Adams <mda at blogwaffe.com> wrote:
>
> That should work for this scenario, but the hooks in the WP class
> (parse_request, request, etc.) only affect the main loop (mostly).  If
> you want your plugin to be more invasive than that (widgets,
> sub-loops, additional loops, etc.), pre_get_posts is the way to go.
>
> If you want to use pre_get_posts in this case, you have to check two
> things:
> 1. is_author() -- are we on an author archive page?
> 2. $query->is_author -- is this query an author query, or some other
> query on that page?
>
> In conclusion, don't knock pre_get_posts :)  It's a perfectly cromulent
> hook.
>

Mike,

Excellent points. The background here is that more than a few custom post
type tutorials out there seem to reference pre_get_posts when they're not
looking for the side effects and only want to modify the main query. Some
even suggest additionally checking for suppress_filters == false, to make
sure it isn't interfering with get_posts(). Obviously, that's not the right
way to do it either, since A) get_posts() can be called with
suppress_filters = true, B) it still interferes with new WP_Query
instantiations, and C) it's generally going to be the wrong hook for what
they're trying to do anyway.

I'm not knocking the hook -- there are great use cases for it, and there's a
way to leverage it here as well (as you illustrate). But the tutorials,
based on their use cases, really should be using request/parse_request. (As
I haven't seen a tutorial cover them, I'm writing one in the next browser
tab over.)

Nacin