#37686 closed enhancement (wontfix)
Add object_type column to term_relationships table
Reported by: | johnjamesjacoby | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Taxonomy | Keywords: | |
Focuses: | Cc: |
Description
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.
Attachments (1)
Change History (7)
#1
@
8 years ago
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
, ornetwork
could make for interesting taxonomy term relationships.
Thank you for volunteering to maintain global terms! ;-)
#2
@
8 years ago
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.
#3
follow-up:
↓ 5
@
8 years ago
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.
#4
@
8 years ago
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
#5
in reply to:
↑ 3
@
8 years ago
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.
#6
@
8 years ago
- Keywords 2nd-opinion removed
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
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
First pass at adding the
object_type
column with a compound index to include it along withobject_id
andterm_taxonomy_id