larryaronson.com

  • Home
  • Contact
  • Articles
  • Technology
  • Portfolio
  • Bio
  • Home
  • Blog
  • Services
  • Contact

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.)

/** 
 * debugging tool - display the main sql statement at page bottom
 **/

// comment out the next 2 lines to disable this tool 
add_filter( 'posts_request', 'my_posts_request_filter', 9999 );
add_action( 'wp_footer', 'print_my_sql_statement', 9999 );

// filter function to save the SQL request in a global variable
function my_posts_request_filter( $input ) {
     global $my_sql_statement;
     $my_sql_statement = $input;
     return $input;
}

// action function to print out the global variable
// works only on a SRP but you can change the conditional
function print_my_sql_statement() { 
     global $my_sql_statement; 
     if (is_search()) print_r($my_sql_statement); 
}

Close

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/

Tags: Custom Post Type, functions.php, posts_request, SQL, Theme functions, WordPress Hooks

Posted in Functions, Themes    

« WordPress 3.3 — A Major Update
Happy Birthday WordPress »

Comments are closed.

  • Contact Info

    larry@LarryAronson.com

    Leave me a message

    Follow Larry Aronson on TwitterCheck out Larry Aronson on FacebookView Larry Aronson's LinkedIn Profile
    New post notices:
     
  • Topics

  • Services

    • Web Design & Development
    • WordPress Customization
    • Search Engine Optimization
    • Social Media Integration
    • Web Design & Development

    Larry Aronson
    larry@LarryAronson.com
    212-807-8561

  • Tags

    amazon apple Automattic blog Blogging Chrome client code cPanel CSS David Schiffer design Firefox flash Flock Google Howard Greenstein HTML HTML5 Internet JavaScript jQuery law lawyer Matt Mullenweg minimal php Popular Posts Safari Search SEO shortcode sidebar widget Social Media twentyten Twitter video Web 2.0 web hosting web service websites WIFI wordpress wordpress shortcodes YouTube
  • Kudos

    Much thanks to Michael Pinto of Very Memorable for "upscaling" my header image.

  • Freelancers Union Keystone Member

© 2023 Larry Aronson