[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:  chrisjean          |       Owner:
     Type:  defect (bug)       |      Status:  reopened
 Priority:  normal             |   Milestone:
Component:  Query              |     Version:  3.0
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+-----------------------
Changes (by mdgl):

 * status:  closed => reopened
 * resolution:  maybelater =>


Comment:

 I think this is worth another look. There have been many changes here in
 the past couple of years, in particular by Andrew Nacin in response to
 #21290 and released in WordPress 3.5, which takes the fix approach
 suggested by Silviu-Cristian Burcă (see comment:7).

 Accordingly, I have updated Chris Jean's patch and done a fair amount of
 testing and code review. Function `get_posts()` is critical and consists
 of 1263 lines of code, so we need to be careful!

 '''Patch Details'''

 With this patch, category and tag queries are treated in the same way as
 other taxonomies. If a post type is not specified explicitly, we default
 to a list of all of the searchable post types registered against the
 taxonomy.

 As far as I can see, the only behaviour change is that for category and
 tag queries that have no post type specified, the post type is now set to
 the default explicitly in the block dealing with taxonomies at around line
 2705 instead of within the block dealing with the corresponding SQL
 "where" clause at around line 2933. Apart from the conversion of a
 singular array to a string at line 2900, there are no other uses of the
 post type variables between these two locations. The generated SQL both
 before and after the patch appears to be identical.

 '''Benefits'''

 This patch means that custom post types can now make use of the standard
 category and tag taxonomies if they wish, including appearing in the
 corresponding archives. I suspect this is quite a common use case where
 custom post types are used to handle different kinds of content but
 taxonomies such as category and tag are used to organise all site content.

 Note that the developer/user must explicitly declare that the custom post
 type make use of the `category` or `post_tag` taxonomies, either through
 the `taxonomies` parameter to `register_post_type()` or through
 `register_taxonomy_for_object_type()`. Furthermore, the developer/user
 must also declare that the custom post type is searchable by setting the
 `exclude_from_search` flag to `false` on registration (see below for
 concerns about the overloading of this flag).

 If the developer/user does not explicitly take these actions, their custom
 post types will not be included within category or tag archives. The use
 of other taxonomies is not affected. The behaviour of custom post types
 within search queries is also not affected.

 The behaviour of custom post types is now consistent with that specified
 in the Codex
 (http://codex.wordpress.org/Function_Reference/register_post_type) which
 does mention the use of categories and tags.

 '''Concerns/Issues'''

 Some concerns were raised earlier by WPCOM about a different but related
 fix (see comment:15), as follows:

 > [15649] breaks existing behavior by setting post_type to 'any' instead
 of defaulting to 'post' when a taxonomy is specified but post_type is not.
 We're already being bitten by this on VIP sites on .com.

 This is now no longer the case. If taxonomy is specified but post type is
 not, we default to whatever searchable post types are registered for that
 taxonomy. In the case of categories and tags this is (by default) just
 'post'.

 The use case mentioned by Scott Taylor (comment:21) seems best addressed
 by proper use of the `exclude_from_search` flag when registering the
 custom post type.

 The outstanding issue about the multiple different uses of the
 `exclude_from_search` flag and the need for a more granular approach is
 logged in #29418.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/19471#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform