Where’s My Query?
May 24th, 2012
Working With WordPress Hooks
When you’re dealing with custom post types you eventually come to the question of what should show up on an archive or search results page (SRP). Say the custom post types are created by a plugin or are built into a special-purpose theme like property listing posts in a real estate theme. How do you know whether or not they’ll show up on an SRP?
The answer is found in the question.
Specifically, the SQL select statement – the request that WordPress sends to the blog’s database. Unfortunately, that statement isn’t readily available to the code in the theme’s template files. The main database query for a WordPress page happens before any of the code in the theme folder is run.
We need to use a WordPress hook to capture the SQL statement before it’s sent to the database. Then we can display it later anywhere we want to; like at the bottom of a Search Results Page. (OK, I’ve read enough; just give me the code.)
The WordPress hook to use is called, posts_request. WordPress passes the main SQL select statement to any filter function registered at that hook. That function can modify the query but, for now, we can just store a copy of it in a global variable. This hack requires editing your theme’s functions file, so make sure you take a backup copy first.
Add the following code to the theme’s functions.php file.
function my_posts_request_filter( $input ) {
global $my_sql_statement;
$my_sql_statement = $input;
return $input;
}You can rename the variables and the function itself, if you want; just be consistent when you use the global variable later in your template files.
The function has to be registered to run at the post_request hook. Add the following line to the functions.php file. It can go either before or after the function definition you just entered.
add_filter( 'posts_request', 'my_posts_request_filter', 9999 );The first argument of the add_filter function is the name of the hook and the second is the name of your function. The third argument is the priority. This we set to a large value because we want our function to run after all other functions registered at that same hook, in case any of them modify the SQL statement.
Save functions.php and load a page from the site just to make sure you’ve not made any stupid syntax errors. Your site should be unchanged by the new filter function; all it’s doing is saving one more global variable in the WordPress sea of data objects available to the theme.
Now we do the same to instruct WordPress to display the SQL statement at the bottom of a SRP page. Add the following function to the functions.php file:
function print_my_sql_statement() {
global $my_sql_statement;
if (is_search()) print_r($my_sql_statement);
}The first line makes the global variable, $my_sql_statement available to the function. The second prints the value of the global on the condition that the current page is the result of a search.
To get this code to execute at the end of a page, you add it to the wp_footer hook:
add_action( 'wp_footer', 'print_my_sql_statement', 9999 );I found this technique very helpful in learning how the WordPress functions, wp_query() and get_posts(), process their arguments, which can get rather complex when trying to include/exclude posts based on the values of custom fields. Understanding that process made it possible to use another WordPress hook, pre_get_posts, to exclude some custom post types from site searches based on their custom field settings. I hope you find this helpful as well.
Happy Hacking,
Larry Aronson
Photo Credit: http://www.flickr.com/photos/widnr/6544914763/
