On one of my projects, I’ve made heavy use of the Custom Post Type of WordPress.  I’ve seen a lot of folks refer to it as good business if you’re into turning the majority of site maintenance/publishing over to the client.  In fact, to be honest, all of my recent projects bar one have been using custom post types in some way, shape, or fashion.

The problem I have with this one project is that the custom post types have to be read inside of the regular “posts loop”.  Most WP sites recommend that you add a filter to the theme functions (or plugin file, if you’re going that route) that makes sure that CPT’s are injected into the loop query.  That looks something like this:

/*
 * Get CPT to show in category listings
 * 
 */

function add_custom_types_to_tax( $query ) {
if( is_category() || is_tag() && is_main_query()  ) {

// Get all your post types
$post_types = get_post_types();

$query->set( 'post_type', $post_types );
return $query;
}
}
add_filter( 'pre_get_posts', 'add_custom_types_to_tax' );

While that’s all fine and good.  I ran into an issue with the Phoenix Site.  I use 3 custom post types (technically two I created and two that are loaded via plugin).  The two that I created are one to control an image slider (as part of the theme, make it easier to swap out images) and a CPT to handle the weekly newsletters and keep them separate from the regular blog/news posts.  The other two are “Fiat Alert” (for flashing a box on the page) and of course, the calendar.

I tried modifying the above function by changing around the “$query->set (‘post_type’, $post_types )” line, but always seemed to create more headaches and not a workable solution.

The issue popped up when trying to view the Category archives for the newsletters.  I didn’t create a custom taxonomy just for the newsletters, instead, letting them pull into the “main” categories.  Silly me, I know.  What happened, is that because Fiat Alert queried the database “the right way” (using new WP_Query), I was getting one of the newsletters popping up in the alert div, then of course, repeating in the regular loop.  Try as I might, I couldn’t get it to work correctly.

But then a funny thing happened.  I noticed that I wasn’t getting the same issue with the query that I used on my slides.  I finally realized that I had written the slider query in the “wrong” way using query_posts.  So, quick re-write of the code, and it’s fixed.

Just an FYI, I didn’t edit the plugin itself, but basically re-created the entire plugin inside of my own custom-post types calls and made the edits there.  Given the simplicity of the Fiat Alert plugin, it wasn’t too bad.

So, here’s the original query from Fiat Alert –

function fiatalert_func( $content ) {
	$args = array( 'post_type' => 'fiat_alert', 'posts_per_page' => 1 );
	$loop = new WP_Query( $args );
	while ( $loop->have_posts() ) : $loop->the_post();
	echo '<div class="fiat-alert">';
	echo '<button type="button" class="close" data-dismiss="alert" style="padding: 20px 15px 0 0;">&times;</button>';
	the_content();
	echo '</div>';
	endwhile;
}

And here’s my “bastardized” or “wrong way” –

if ( ! function_exists('fiatalert_func') ) {
	function fiatalert_func( $content ) {
		query_posts('post_type=fiat_alert&posts_per_page=1');
		if(have_posts()):
			echo '<div class="fiat-alert">';
			echo '<button type="button" class="close" data-dismiss="alert" style="padding: 20px 15px 0 0;">&times;</button>';
		while(have_posts()): the_post();
		the_content();
			echo '</div>';
		endwhile;
		endif;
	}
}

Near as I can tell, the original problem lies in the fact that WP_Query can be “hooked” into (like it was), which is a normally a good thing.  Sometimes, I guess, you just don’t need to be worrying about the hooks so much.