[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