[wp-hackers] parse_query filter

Ryan Boren ryan at boren.nu
Wed Oct 5 23:54:29 GMT 2005


On Wed, 2005-10-05 at 17:26 -0400, Owen Winkler wrote:
> Mike Little wrote:
> > On 05/10/05, Owen Winkler <ringmaster at midnightcircus.com> wrote:
> > 
> >>I was looking for a plugin hook that would allow me to inject the
> >>query_vars with a value or two before the default posts array is
> >>generated.  That's when I came upon this:
> >>
> >>if ( !empty($query) ) {
> >>        do_action('parse_query', array(&$this));
> >>}
> >>
> >>Why does $query have to be empty to fire this hook?  There seems to be
> >>no other way to modify the query_vars on the home page from a plugin.
> >>
> >>Owen
> >>
> > 
> > 
> > Surely that says *not* empty. I.e only call the hook if there is a
> > query to process.
> 
> Er...  Let's try that again...
> 
> Why does $query have to be NON-empty to fire this hook?  There seems to 
> be no other way to modify the query_vars on the home page from a plugin.
> 
> Put a different way:  If the request is for the home page ($query == '') 
> then the hook isn't fired.

Well, giving an empty query is a way of saying, "Don't reset the
internal query, just do a run through of what's already set in case
something changed behind the scenes."  We don't do the action if this is
the case because we're trying to be sneaky.  Plus, we want to avoid
recursion in the case where some calls parse_query() from the
parse_query action. is_home is a corner case, alas.  Maybe we could test
if ($query === false).  I don't know if any plugins are actually using
this behavior, so we might be able to change or drop it.

You can use the query_vars filter, but anything stuck in there will affect the is_* states.
That's probably not what you want.

> Attached is my proposed, possibly easier-to-manage solution.

Sounds good.  Write a bug, please, and I will commit.

Ryan



More information about the wp-hackers mailing list