Add object_type column to term_relationships table

[johnjamesjacoby]

Prologue

Today in WordPress core, taxonomy terms are only ever registered to post objects. This makes it easy to discern that in the wp_term_relationships database table, every object_id points to a post ID from the wp_posts database table.

---

Problem

When using taxonomies for things other than posts, it's impossible to discern the type of object that a taxonomy term is related to.

---

Example

The WP User Groups plugin registers taxonomies for users, and uses the object_id column for user IDs from the wp_users database table (instead of post IDs.)

This means that a taxonomy term ID cannot be used for both post ID's and user ID's, as there is no way to know if an object_id is for a post ID or a user ID.

---

Solution

Introduce an additional column in the wp_term_relationships table for an object_type. Core object types would be registered according to their primary function: post, comment, user, and heck... even term, option, site, or network could make for interesting taxonomy term relationships.

This change also -- relatively easily -- allows for many-to-many object-to-object relationships, where posts, comments, and users can share a common tag or category, without being required to.

[johnjamesjacoby]

First pass at adding the object_type column with a compound index to include it along with object_id and term_taxonomy_id

[pento]

I am ambivalent towards this change.

On the one hand, there are many potential use cases for allowing taxonomies against all objects.

On the other hand, this has significant backwards compatibility issues, particularly for any code that does custom queries against wp_term_relationships - suddenly, an object_id doesn't necessarily correlate with a post_id.

...site, or network could make for interesting taxonomy term relationships.

Thank you for volunteering to maintain global terms! ;-)

[dd32]

This means that a taxonomy term ID cannot be used for both post ID's and user ID's, as there is no way to know if an object_id is for a post ID or a user ID.

Just to clarify on this, currently we tie taxonomies to an $object_type which although is normally thought of as post_type nothing prevents you from using 'user' as the object type. What you cannot do however, is have $object_type be an array of multiple differently indexed types (so no [ 'user', 'post' ], or [ 'user', 'option' ]).

This means that a taxonomy term ID cannot be used for both post ID's and user ID's, as there is no way to know if an object_id is for a post ID or a user ID.

This isn't an issue going forward, as now that we have split terms, each taxonomy (which still, IMHO, should only be added to a single collection of uniquely id'd terms) will get it's own term_taxonomy_id. It shouldn't really be possible to have the ID of TermA in a posts taxonomy also assigned to a user in another taxonomy, nor should they be sharing the same taxonomy name IMHO..

---

This sort of functionality has been on the radar, and has always been, as part of the ​Taxonomy Roadmap work (Scroll down to the final references to wp_term_relationships) but was never fully ironed out as what to do there, as we've had a long amount of simplifying to do to get to where we are today.

I'm not 100% sold that the solution here should be to switch from a single unique ID (object_id) => term_id to a tuple of (object_type, object_id) => term_id though. As outlined in the above link, a more powerful useful implementation may be to convert to a object linking table of (object_type, object_id) => (object_type, object_id) which would allow far more flexibility in how it's used, and also prevent hacky solutions like using a taxonomy as a middleman to link two pieces of content together.
At first, it seems that implementing just (object_type, object_id) => term_id is a step in the right direction, and that it could then be upgraded/iterated on later to add the object_type to the right side of the equation, however I feel that it would needlessly complicate matters and muddy the upgrade paths going forward.

[helen]

Related: #14513

Object-to-object relationships sound real nice now that the taxonomy roadmap has shown very good results (with thanks to @boonebgorges Tha God and everybody who's worked on it). In this instance, use cases/scenarios and idealized solutions need to be identified and documented before wandering into real solutions. The real solution might end up something like what's being proposed here, there's just not enough information to actually decide on it just yet. As far as I'm aware, nobody has picked that train of thought back up in the recent past, but there could be Trac tickets or who knows what else that haven't been collated.

There's also still the consolidating tables part of the roadmap that hasn't been tackled yet, curious if that should happen before proceeding to the relationships-for-everybody part, as was originally indicated in the timeline.

[MikeSchinkel]

Thoughts on this.

It really feels unnecessary to add a field to the wp_term_relationships table. Instead I would propose that we add an 'object_type' element to the $args array passed to register_taxonomy() and handle in that manner. Worst case we could add the value to wp_term_taxonomy if we need it in the database.

Adding to thewp_term_relationships table will end up bloating an efficient table relationship that is only 51 bytes per row to become much larger.

Or are there use-cases that I am missing that one of these proposed alternatives will not accommodate?

---

And for those who care, think about how much effort it will be to update the tables on WordPress.com... #justsaying

[theMikeD]

Replying to helen:

In this instance, use cases/scenarios and idealized solutions need to be identified and documented before wandering into real solutions. The real solution might end up something like what's being proposed here, there's just not enough information to actually decide on it just yet.

This.

[johnjamesjacoby]

OK to close this, since it's a bit in conflict with other future taxonomy efforts.

I may be able to pull this off in a plugin to get a PoC, and depending on how viable a true relationships table ends up being, I'll try to remember to circle back and update here or there.

Edit: thanks everyone for your feedback <3