WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 5 months ago

#35848 new defect (bug)

WordPress 4.4 Handling Custom Taxonomies and Tax Queries Correctly

Reported by: vrazer Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: Query Keywords: reporter-feedback
Focuses: Cc:
PR Number:

Description

As of the WordPress 4.4 release, we have seen several sites that are using custom post types and custom taxonomies that no longer respond correctly to taxonomy page requests.

E.g.

Custom Post Type 1
-- Custom Tax 1 (slug = customtax1)
-- Custom Tax 2 (slug = customtax2)

Custom Post Type 2
-- Custom Tax 3 (slug = customtax3)
-- Custom Tax 4 (slug = customtax4)

A query like this ?customtax1=term1&customtax3=term2&customtax2=term4 should result in a taxonomy query where you get posts/post types that have the respective term values associated with the post object for each of those taxonomies. Instead as of WordPress 4.4, these queries are returning the home page of the site with is_home = true (not a taxonomy template) and completely disregarding the taxonomy query.

Important notes:
1) Custom Post Type/Taxonomy plugins have been observed on these sites. It is not limited to any specific custom post type/taxonomy plugin
2) register_post_type and register_taxonomy ARE being called by these plugins via the init hook
3) Reverting to 4.3.x fixes the issue
4) Custom taxonomies in the admin and custom post types everywhere still seem to be working the same as with previous WP versions. The issue seems to be related only to the main query of front end requests.
5) Switching themes does not fix the issue
6) Migrating the register_post_type and register_taxonomy definitions to functions.php in the main theme and verifying they are run in an init hook does not fix the issue.
7) Trying to work around the issue by running pre_get_posts and applying the appropriate tax_query to the main query does not fix the issue.
8) Setting the post_type to the associated custom post type for the custom taxonomy in a "request" hook or "pre_get_posts" hook does not fix the issue, but it does shift the theme template to the custom post type's archive template (which at least rectifies the visual display problem associated with the incorrect query parsing, but it still doesn't appropriately filter the request)
9) Creating a WP_Tax_Query manually does return the desired tax_query, but this does not appear to work with $query->set in pre_get_posts either by assigning the tax_query as an array or WP_Tax_Query object (which was a hail mary test)

Any necessary information needed to debug this can be provided. But it "appears" to be some sort of regression or new bug associated with the new taxonomy features and that is limited to custom post types with custom taxonomies.

Change History (3)

#1 @boonebgorges
4 years ago

  • Keywords reporter-feedback added

Hi @vrazer - Thanks for the ticket, and welcome to WordPress Trac.

At a first pass, I'm unable to reproduce the issue. in both 4.3 and 4.4, The query ?customtax1=term1&customtax3=term2&customtax2=term4 will query for posts that match all of the query params. That is, any post objects with *all* of the queried terms. The query is post-type agnostic; when is_tax, and no post_type is provided, the post_type list will be populated with all post types against which the queried taxonomies are registered.

Can you give more details about your post types, taxonomies, and data? I've been testing with a bunch of CPTs and various ways of registering taxonomies, but it's possible that I'm misunderstanding your report. Specifically, I'm registering CPTs and taxonomies like this:

register_post_type( 'foo', array( 'public' => true ) );
register_post_type( 'bar', array( 'public' => true ) );

register_taxonomy( 'tax1', array( 'foo', 'bar' ) );
register_taxonomy( 'tax2', array( 'foo', 'bar' ) );

and then creating a number of different posts and associating terms with them in various combinations. But maybe there's something specific about the way you're registering the taxonomies (or something else) that's causing this?

If you're able to bisect to find the specific changeset that caused the regression, it would be extremely helpful.

#2 @vrazer
4 years ago

We were able to determine a bit more information on this. All I can say for sure is that the behavior that changed between 4.3 and 4.4 is somehow also tied to the 'public' status of the registered taxonomy. By that, what I mean is that setting the status of the taxonomy to public fixes this problem (which is obviously the intended result of that parameter). At least, that is the case with the Types plugin and how it registers custom taxonomies. We are seeing this same behavior with the More Types and More Taxonomies plugins (completely separate plugins). Oddly, the problem with taxonomies constructed by the More Taxonomies is one where the taxonomy IS set to public but still has this same issue. The issue occurred in both cases at the onset of WordPress 4.4 with prior settings working fine in 4.3. With Types, there was a functional fix by changing settings. With More Taxonomies, there was not.

Additional research into this has us questioning whether the issue is not as much of a new bug in WP 4.4 as perhaps a bug in 4.3 (and prior) that was fixed in 4.4. I wish I could say more specifically what set of symptoms was creating this, but all I know for sure is that the problem involves the use of Custom Types with Custom Taxonomies built by plugins (which do use the register taxonomy function correctly). The settings used in these plugins (which are passed to register_taxonomy) all appear to be correct. If we are able to better track down this issue, we will report back with specifics. In the meantime, I'm going to have to assume that the issue is actually a bug that was fixed in 4.4 that manifested on some sites as if a bug had been introduced (perhaps due to some inadvertent reliance on that bug).

#3 @boonebgorges
4 years ago

Aha. Yes, if you were previously registering taxonomies with 'public' => false, then front-end queries would've stopped working in WP 4.4. See #21949. As you note, this is a case where a longtime bug (or, more appropriately, "unimplemented feature") was fixed, which may cause backward compatibility issues for implementations that use the previously-not-working public in odd ways. See, for example, https://core.trac.wordpress.org/ticket/21949#comment:29 and the follow-up comments.

It may help with your specific implementation to know that WP 4.5 will introduce a publicly_queryable argument for taxonomies, which will allow a taxonomy to be "private" - ie, it'll default to false for show_ui etc - but can still be queryable using the ?taxonomy=term query var. See #34491.

Please do update this ticket if you are able to discern a pattern between the various problems you're having (or if you determine that they're, in fact, separate issues).

Note: See TracTickets for help on using tickets.