id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
19471	Automatically support custom post types in category and tag archives	chrisbliss18		"I dealt with a plugin recently that had the following code in it:

{{{
#!php
<?php
add_filter('pre_get_posts', 'query_post_type');
function query_post_type($query) {
    if(is_category() || is_tag()) {
        $post_type = get_query_var('post_type');
        if($post_type)
            $post_type = $post_type;
        else
            $post_type = array('post','external-videos');
        $query->set('post_type',$post_type);
        return $query;
    }
}
?>
}}}

The goal was simply to allow their custom post type that was connected to category and tag taxonomies to have its entries rendered on category and tag archive pages. Digging around, it seems that [http://wordpress.org/support/topic/custom-post-type-tagscategories-archive-page/ many people] are using a solution like this.

Of course, the code has problems in that it misses home pages and will mess with all other queries on the affected page (such as menus). Looking further in the thread, it seems people tried fixing up these limitations with code such as the following:

{{{
#!php
<?php
add_filter('pre_get_posts', 'query_post_type');
function query_post_type($query) {
  if(is_category() || is_tag() || is_home() && empty( $query->query_vars['suppress_filters'] ) ) {
    $post_type = get_query_var('post_type');
	if($post_type)
	    $post_type = $post_type;
	else
	    $post_type = array('post','articles','nav_menu_item');
    $query->set('post_type',$post_type);
	return $query;
    }
}
?>
}}}

While this may address the known issues, I don't see it as a solid solution in any way. Here are just couple of the primary issues I see with such a solution:

 * Things are very likely to change in the future (such as the possibility of adding additional core taxonomies or query modifications), causing the ever-increasing number of plugins that use custom post types to constantly have bugs.
 * Since the WP_Query->set function replaces values rather than merging them, even the ""fixed"" version of the code will cause plugin conflicts as multiple instances of this solution will systematically undo the modification done by each previous instance. Sure, the code could be improved to cover this, but the odds of getting everyone to fix their code are not good.

To me, this is something that was an oversight in the development of custom post types. I can think of no reason why this should not be automatically handled. The dashboard properly shows post counts for categories and tags that include the custom post types, but the query simply fails to handle this. It needs to be fixed.

Testing things out, I noticed that custom taxonomies did not have this problem at all. Looking at wp-includes/query.php, I saw the following:

{{{
#!php
<?php
if ( $this->is_tax ) { 
    if ( empty($post_type) ) { 
        $post_type = 'any';
        $post_status_join = true;
    } elseif ( in_array('attachment', (array) $post_type) ) { 
        $post_status_join = true;
    }   
}   
?>
}}}

This is what allows custom taxonomy archives to work properly without having to filter the query. I've always felt that is_tax should cover categories and tags as well, but what is done is done. So, I propose that this section is modified to include a check for is_category and is_tag. Example:

{{{
#!php
<?php
if ( $this->is_tax || $this->is_category || $this->is_tag ) { 
    if ( empty($post_type) ) { 
        $post_type = 'any';
        $post_status_join = true;
    } elseif ( in_array('attachment', (array) $post_type) ) { 
        $post_status_join = true;
    }   
}   
?>
}}}

This allows for things to ""just work"" as people would expect. Of course, plugins would have to remove their filter in order to avoid plugin conflicts as the post_type query arg would still be set and will not be changed automatically to ""any"". This is as it should be though, so people will just have to be convinced over time to remove the modification from their plugins.

Attached is the proposed patch."	defect (bug)	new	normal	Awaiting Review	Query	3.0	normal		reporter-feedback	wycks sirzooro knut@…