Make WordPress Core

Opened 6 years ago

Last modified 5 years ago

#45107 new enhancement

Taxonomies should only be allowed to support one object type

Reported by: desrosj's profile desrosj Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords: 2nd-opinion needs-patch needs-unit-tests
Focuses: Cc:


Currently, taxonomies can be registered to any object type (posts, comments, users, etc.). But core does not enforce a one to one limit for object types to taxonomies, which can be problematic.

For example, if a taxonomy is registered to both users and posts, there can be unintended consequences. Adding a term to a post with an ID of 3 would also cause a user with an ID of 3 to have that term. Removing that term from the user would also affect the post. Unique IDs are only enforced on a per object type basis, not accross all types.

The approach here would be to introduce a _doing_it_wrong() notice (and possibly even return a WP_Error) when a taxonomy is registered to multiple object types.

Good: register_taxonomy( 'custom_tax_name', array( 'post', 'page', 'cpt' ) );

Bad: register_taxonomy( 'custom_tax_name', array( 'post', 'user' ) );


Adding this to Core would open the door for the following potential features:

  • WP_Tax_Query support could be added to users (see #31383), comments, etc.
  • Built-in fields for taxonomy could be added to the REST API for users, comments, etc.
  • UIs could be added for users (also see #31383), comments, etc.

Backward Compatibility

To continue supporting backward compatibility for sites that are registering a taxonomy for multiple object types, register_taxonomy() could continue working as is. The only change would be to return a WP_Error and a _doing_it_wrong() notice.

In the future, register_taxonomy() could be changed to only register objects with the same type as the first specified object type.

Example: register_taxonomy( 'custom_tax_name', array( 'post', 'user', 'page' ) ); would only register the taxonomy for posts and pages (same object type).

Change History (2)

#1 @flixos90
6 years ago

Thanks for opening this! I had just thought about something along these lines a few days ago.

Something that I strongly think we should do is separate concerns with object types and post types. While the function uses the name “object type”, most of core is only made to support and assume that parameter to be a post type.

I’m thinking we should either:

  • Clarify that you should only provide a post type here and, if we actually want object type support for something else than “post”, handle that in a new function.
  • Or find a way to declare both the object type and the object subtype (this is what the post type actually is in relation to the object type “post”) in the function, but it needs to be through separate parameters. Allowing to either specify an object type OR a subtype in the same parameter just screams for future issues (such as “Do you mean the object type ‘post’ or the post type ‘post’?).

This ticket was mentioned in Slack in #core-multisite by desrosj. View the logs.

5 years ago

Note: See TracTickets for help on using tickets.