[wp-trac] [WordPress Trac] #19471: Automatically support custom post types in category and tag archives
WordPress Trac
wp-trac at lists.automattic.com
Wed Dec 7 20:56:03 UTC 2011
#19471: Automatically support custom post types in category and tag archives
--------------------------+-----------------------------
Reporter: chrisbliss18 | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Query | Version: 3.3
Severity: normal | Keywords: has-patch
--------------------------+-----------------------------
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.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/19471>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list