8

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?

Improve this question
3
  • 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
    Commented Nov 15, 2011 at 19:57
  • @Bainternet Please take a look at the end of my A. EXPLAIN says term_id.
    – kaiser
    Commented Dec 18, 2011 at 15:09
  • 1
    I think it's a vestigial tail. Logging a ticket with Trac: core.trac.wordpress.org/ticket/20536
    – Tom Auger
    Commented Apr 24, 2012 at 17:58

2 Answers 2

Reset to default
3

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.

Improve this answer
6
  • 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
    Commented Mar 23, 2013 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
    Commented Mar 23, 2013 at 0:41
  • 1
    Reminder to update this question - btw, wasn't there something with term alias ?
    – kaiser
    Commented Jul 2, 2013 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
    Commented Jul 2, 2013 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
    Commented Jul 2, 2013 at 19:36
1

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.

Improve this answer
4
  • 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
    Commented Dec 20, 2011 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
    Commented Dec 20, 2011 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
    Commented Apr 24, 2012 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
    Commented Apr 24, 2012 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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