[wp-trac] [WordPress Trac] #19471: Automatically support custom post types in category and tag archives
noreply at wordpress.org
Wed Jan 14 14:04:03 UTC 2015
#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 =>
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!
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
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.
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
does mention the use of categories and tags.
Some concerns were raised earlier by WPCOM about a different but related
fix (see comment:15), as follows:
>  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
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
More information about the wp-trac