Getting Down and Dirty with WP_Query->set()

I was so stoked when I was reading a blog post on Justin Tadlock’s site about custom post types. He introduced me to a new way of hooking into the WP_Query class and I was so excited that I had to leave a comment. I’ve been writing custom functionality into themes using this method ever since and it has really saved me some time.

…until today that is!

There is a small quirk with this method that I discovered the hard way. Here’s a bit of information about the problem I encountered with WP_Query->set() and what I did to fix it.

I needed to set the posts_per_page argument of The Loop to 1 for a specific taxonomy called “collection”. The following code accomplished this quite well.

add_filter( 'pre_get_posts', 'mfields_one_post_per_collection_view' );
function mfields_one_post_per_collection_view( $query ) {
	if ( is_tax( 'collection' ) )
		$query->set( 'posts_per_page', 1 );
	return $query;
}

In plain English this code tells WordPress that if we are viewing a term of the ‘collection’ taxonomy, it should only retrieve one post for each paged view. And quite honestly, it worked perfectly! I was stoked! Such a simple solution.

The Problem

For the project I was working on, I needed to add another query to retrieve multiple post objects. This is when things got a bit sticky. My query looked like this:

$args = array(
	'post_type' => 'piece',
	'number_posts' => 10
	);
$pieces = get_posts( $args );

I was hoping that this query would return the last 10 pieces in descending order but, no matter what modification I made to the $args array, it always returned only one result.

Why? you ask. What I came to realize is that while the call to WP_Query->set() affects The Loop – it is not the only thing that it will modify. Basically, if you use this method, you are not only hooking into the Main Loop but every other object of the WP_Query class. Using get_posts() creates a new WP_Query object so it too is affected by calls to WP_Query->set().

My Solution

I was digging around in WordPress core when I noticed that there is an argument that get_posts() always passes to the constructor of WP_Query. This argument is ‘suppress_filters’ and is used to bypass filtering of the WP_Query class. It is possible to use this arg as a condition in our logic to ensure the custom queries created from the get_posts() function will not be affected by our pre_get_posts handler.

Here is the finished code that worked well for me:

add_filter( 'pre_get_posts', 'mfields_one_post_per_collection_view' );
function mfields_one_post_per_collection_view( $query ) {
	if ( is_tax( 'collection' ) && false == $query->query_vars['suppress_filters'] ) {
		$query->set( 'posts_per_page', 1 );
	}
	return $query;
}

Hope that someone finds the useful.