[wp-hackers] meta_key and meta_value query variables don't work in the backend?

[Matthew Gerring]

OK, that makes sense.

This is the code I'm using: http://wordpress.pastebin.com/m3ebb37f9. From the source, it looks like I only have one filter available in edit-pages.php. I'm not sure how I would go about using WP_Query in that context. What would be the right filter/action to use?

Also, in this case allowing people to browse by post meta wouldn't be the worst thing, since this site makes heavy use of post meta to organize pages. But the other way would be preferable.

-Matthew

On Jan 15, 2010, at 12:42 PM, Otto wrote:

> On Fri, Jan 15, 2010 at 1:24 PM, Matthew Gerring <mgerring at emrl.com> wrote:
>> What I mean is, I'm writing a plugin to allow a client to sort pages on the edit pages screen. I have it set up to sort by author, title, and date, and filter by a custom taxonomy. I want to be able to sort by custom field as well- all of the pages in this site have a custom field called "Country" with a set drop-down list of countries.
>> 
>> To do all the sorting and filtering so far, I used the manage_pages_query hook to add query variables to the request, and it has worked perfectly. All it does is put all the query variables in an array and pass it to the wp() function. But if I try to use the meta_key and meta_value variables, which are available if I use them in a theme (i.e. in the front end), nothing happens. So it appears that while you can pull out posts according to custom fields in a theme, you can't do the same thing on the manage pages/posts screens in the back end, and I'm wondering why.
>> 
>> I hope that clears it up.
>> 
>> -Matthew
> 
> 
> Ahh. Okay, your use of front/back confused me, as that's backwards
> from the way I'd normally think of them.
> 
> I'm still not entirely clear on how you're passing this data into the
> system, but if it's through the front door (the wp() function), then
> that's different than passing it directly to a wp_query.
> 
> Passing something into wp() means that it gets parsed as if it came
> directly from the untrusted browser, like a URL would. This goes
> through all the rewrite rules and that sort of jibber jabber. This
> also means that in order for something to make it from the query_vars
> there into the wp_query object, then it has to exist in the
> public_query_vars.
> 
> This is a bit complicated, but basically for some query variables, you
> can pass them in on the URL line. Like http://example.com/?p=123 or
> http://example.com/?cat=456. That p and cat get converted into
> variables inside the wp_query object. Like $wp_query->query_vars['p']
> or $wp_query->query_vars['cat']. The wp_query then examines what it
> gets and builds the query accordingly.
> 
> The meta_key and meta_value are values that the wp_query is capable of
> using. But they're not values that the parser is capable of parsing,
> by default. So passing them into wp() makes them get filtered out, as
> any other unknown values would be. If they weren't then anybody could
> look through your posts via meta with a simple
> http://example.com/?meta_key=aaa&meta_value=bbb.
> 
> If you actually want that for some reason, then you'd use the
> add_query_var() function to add those two names to the
> public_query_vars, allowing both that and a call to wp() to use those
> variables.
> 
> You probably don't want that, in which case you should be creating a
> new WP_Query, or calling wp_query() to change the query.
> 
> -Otto
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers