[wp-hackers] get_terms() & 'term_group'

[The WordPress Web Warlock]

Al 16/07/2011 23:12, En/na Otto ha escrit:
> Term aliasing is one of those things that nobody really uses, but it's
> left there because there's some ideas floating around it that could be
> useful for somebody.
>
> Basically, the idea is to group terms together showing that they're
> related or similar or the same or something. For example, if I went to
> /tags/wordpress then maybe it'd be nice to get posts with the tag "WP"
> as well. If those two terms were in the same group, then I might be
> able to do something like that.
>
> Marking terms as aliases is there and works. How you can use that term
> grouping is not really in there at all. That's more advanced
> functionality that needs to be fleshed out and rethought before
> becoming core code.
>
> -Otto
>

There's quite a difference between a "term group" (just what WP 
so-called "taxonomies" are) and a term alias (that redirects, or means, 
another "parent" or "main" term). "Similar" is a different thing of 
"Identity" (being the same) and both are quite different to "related". 
If wp and wordpress (sorry, no uppercase danging in slugs) are aliased 
(meaning that "wp" is alias of "wordpress", *and obviously not vice 
versa*), you should never, ever, be able to assign posts to *both* 
terms, because that's asking for disaster.

Besides, the "term group" thingie, as designed/slightly implemented, 
doesn't show which is alias or synonim of which. I sincerely doubt that 
"making terms as aliases" really "works" because *no term can be 
actually alias of any other term* with the column system. That is, *they 
do not know who they're alias to*. (How can an alias system possibly 
work with that?) Terms may, at most, share a value in a non-API-ed 
column in the table... which is linked to no term at all. It just keeps 
score of how many "term groups" area already in the table, but that 
doesn't point to any term (and if you're pointing to no other main term, 
*you're making no alias*, don't fool yourself). That just "floats". So 
it's actually a (numerical) "taxonomy" set in the wp_terms table, with 
no API and number value instead of string. But there are already 
"taxonomies", which is the thing that WP core uses, so that column is 
absolutely useless. Also the term API is heavily dependant on taxonomies 
—the "term groups" and, ahem, "alias" you're talking about, have no 
mention to taxonomies whatsoever, and have no way to reference it 
because the "term group" are supposed to refer to the number of term 
group, not term_id, not any term_taxonomy_id nor taxonomies. And term_id 
may map to multiple records in term_taxonomy (though it's a mess and a 
bad idea to do that, yes, but it's possible, and more feasible than the 
"term group" column thingie).

So the term_group column marks the terms as having some kind of unnamed 
relationship, which by no means can be an alias (synonimia/redirecting) 
relationship, and that you have to specifically define by hardcoding it 
somewhere. And are site-exclusive (the number of the very same "term 
group" can be different across sites). But that doesn't matter much, 
since you've got also to code all the rest of the API...

It's far more efficient to implement term meta and with a single field 
(or two for taxonomy and term_id, if you don't want to store serialized 
data), assign any term as alias of another term. Then, you can hook any 
operations to terms, and see if the term you're working with is alias of 
another; and if it is, you may redirect to the aliased term template, 
link to the aliased term link, and even substitute the alias term for 
the aliased term in wp_set_object_terms. I know because I've done that. 
(Also, you can get things the other way, that is, you may know which 
terms are aliases of any given term).

(And using groups with term meta instead of taxonomies, btw, can also be 
pretty more efficient that using taxonomies, even if "taxonomies" are 
already built in. You may just get the IDs of the terms, and have 
hundreds or thousands of term groups, and still add just another 
instance of the term_taxonomy_table, not hundreds or thousands of them. 
A "group" that has hundreds of terms, with no subdivisions, is hardly 
manageable or useful at all: the term parent id would be much more 
meaningful and detailed than the "taxonomy").

That's another of the use cases and features for term meta I explained 
the other day, back when you were asking for them, and you paid no heed. 
See, there are other people thinking out there, too, so maybe you'd need 
just to listen sometimes instead of rethinking.

So, yes, mark another to go for term meta.


Best,

Xavier