[wp-trac] [WordPress Trac] #19471: Automatically support custom post types in category and tag archives

[WordPress Trac]

#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.0
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |
-------------------------------+------------------------------

Comment (by mdgl):

 Replying to [comment:23 wonderboymusic]:
 > Surprisingly, no, I was not kidding. I think the reason no one has
 looked at this ticket in 11 months may have something to do with the
 premise. To quote from the Bible
 ([http://markjaquith.wordpress.com/2010/11/12/post-formats-vs-custom-post-
 types/ markjaquith.wordpress.com]):
 >
 >     ''If you want it to show up in your site’s main RSS feed, then it’s
 probably not a custom post type.''
 >
 > RSS Feed and archives being interchangeable here.

 Oh, I see! But the key word in Mark's post is *main*, referring to the RSS
 feed commonly available at `example.com/feed/` and
 `example.com/comments/feed`.

 Although these are commonly labelled as the "site feed" and "site comments
 feed", in fact they are really just the "blog feed" and "blog comments
 feed" or more accurately "post_type=post feed" and "post_type=post
 comments feed".

 You can argue that this definition is too narrow in these days of custom
 post types, but the fact is these feeds have always been restricted to
 "post_type=post" as they have never (for example and to my knowledge)
 included pages or attachments. Hence the case can be made to not extend
 these feeds to include other (custom) post types.

 Separately, however we have archives and feeds for all sorts of things:
 date, author, category, tag, taxonomy and custom post type archives as
 well as search results and comments on search results. It is here where
 things get a bit more problematic and inconsistent!

 Search results (and comments on search results) for example seem to
 include all post types, as do taxonomy archives/feeds (I believe - for
 those post types against which they are registered). The archives/feeds
 for date, author, category and tag are different in that they only seem to
 apply to posts of type "post".

 Maybe we can argue that date archives should only apply to the blog
 (post_type=post) because this forms the only explicitly time-ordered
 series of posts. I would suggest, however that the more obvious behaviour
 from the user's perspective would be to included *all* (public) content
 within the specified date range (an exceptional argument could be made in
 the case of pages :-).

 But why should author archives not include custom post types that have
 declared themselves to support "author" (see `add_post_type_support()`)?
 And why should category and tag behave differently to other taxonomies?
 If I explicitly register the taxonomies "category" and "post_tag" against
 a particular post type, why shouldn't my instructions be respected?

 If you are saying that such archives should definitely *not* contain
 custom post types, then at the very least we should remove/disallow the
 "supports => author" attribute for custom post types and return an error
 if anybody tries to register the taxonomies "category" and "post_tag"
 against custom post types.

 Anything else is just adding to the inconsistency and confusion.

 P.S. I don't regard inactivity on a ticket as any sign of lack of
 interest, importance or concern. As you can see from the comments from
 nacin and others, this "feature" was apparently and intentionally made to
 work at one time. It regressed due to some unspecified concerns over at
 WP.com.

 The sad fact is that there are hundreds if not thousands of important
 tickets that are in some way found to be "difficult" (often architectural
 in nature or having potential impact on themes/plugins) and so tend to get
 dropped by developers keen to work on easier items such as the front-end
 tools. Unfortunately, these tickets really *need* to be addressed at some
 point if WP is not to degenerate into a completely unmaintainable mess...

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19471#comment:24>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software