Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

A related WPSE question asks how to get the term by specifying ID only, without specifying taxonomy. My question is more philosophical. Generally, stuff in WP core is there for a reason. I'm trying to understand why term_id can't be the primary key for the term - why do we need the taxonomy as well? Can a single term record be a member of multiple taxonomies? That's certainly not currently supported in the API. Is there a use case where this might be desirable?

Or is the required $taxonomy parameter in get_term() a vestigial tail from an earlier incarnation of the database structure?

share|improve this question
3  
I'm not entirely sure but i think is more of a performance issue since the taxonomy field of the wp_term_taxonomy table is used as index for that table, which make the query faster (even if its just a term). –  Bainternet Nov 15 '11 at 19:57
    
@Bainternet Please take a look at the end of my A. EXPLAIN says term_id. –  kaiser Dec 18 '11 at 15:09
1  
I think it's a vestigial tail. Logging a ticket with Trac: core.trac.wordpress.org/ticket/20536 –  Tom Auger Apr 24 '12 at 17:58

2 Answers 2

up vote 2 down vote accepted

I've logged a ticket against this with trac: http://core.trac.wordpress.org/ticket/20536

However, it turns out that for the time being it IS necessary, as WordPress currently (since 2.x) has a bug that DOES associate two terms with the same name to the same term_id! So it IS possible (though incorrect) for a single term to be associated with more than one taxonomy. See this bug: http://core.trac.wordpress.org/ticket/5809

It's pretty wide-reaching so implementing the fix will need to be unit-tested very thoroughly. I'll try to remember to update this question if there are any developments.

share|improve this answer
    
This is DEFINITELY the case! This bug bit me on a large (several hundred) multisite installation... Very weird. AND notice that the bug is 5 years old... However, the patch is scheduled for inclusion in the 3.6 release, so this may actually get fixed! (Finally! :) ) –  rinogo Mar 23 '13 at 0:26
    
Thanks for updating this question to choose the correct answer, Tom! Hopefully this will help those who land on this question in the future. And thanks for the answer/links. Very helpful. –  rinogo Mar 23 '13 at 0:41
1  
Reminder to update this question - btw, wasn't there something with term alias ? –  kaiser Jul 2 '13 at 14:26
    
Hi @kaiser, update it with what? I'm not sure that there has been any further positive movement toward a resolution of the Trac issues mentioned. –  Tom Auger Jul 2 '13 at 19:16
    
Currently it's target is set to 3.7-early. Let's see what happens. What is missing? Couldn't quite follow at the end as there have been unit test from what I read. –  kaiser Jul 2 '13 at 19:36

why do we need the taxonomy as well? Can a single term record be a member of multiple taxonomies?

No. Terms have slugs to support term archives. And having the slugs two times brings up a lot of minetraps or "wontfix"es in some permalink scenarios.

Is there a use case where this might be desirable?

Yes: Imagine that you have terms for e.g. size and have three taxonomies named length, width and height (you could also think about colors). But that's not supported for the reasons written above.

Generally, stuff in WP core is there for a reason. I'm trying to understand why term_id can't be the primary key for the term - why do we need the taxonomy as well?

From looking at the table and running an EXPLAIN, term_id is the primary key. I guess on larger systems it might be faster to only query taxonomy specific terms using a (slow) join than querying all, sorting them and filtering what you need.

share|improve this answer
    
From the sounds of things then, it's either there in error (perhaps left over from the previous schema) or it is there for some future case where you may be allowed to have duplicate slugs (unlikely). In any event, I'm not sure you answered my question. –  Tom Auger Dec 20 '11 at 14:27
    
@TomAuger "Is there a use case where this might be desirable": Yes. But the contra weights more. A term in tax A can have the same name as one in tax B, but a different meaning for example. So, if you're querying "weight" in taxonomies "importance" and "shipping costs", what would "really heavy" then bring up? –  kaiser Dec 20 '11 at 14:38
    
Yes, but here we're talking about term ID, not term NAME. The ID already completely disambiguates the term from any other term (in whatever taxonomy) that might have the same name. Note that this is less of a Database question and more about why it was left in the core code. –  Tom Auger Apr 24 '12 at 17:44
    
@TomAuger It would've been easier if you followed this Q at the end of Dec. I now would've work again into this :/ –  kaiser Apr 24 '12 at 18:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.