[wp-hackers] get_terms() & 'term_group'
The WordPress Web Warlock
wordpress at web-warlocks.net
Sun Jul 17 01:11:55 UTC 2011
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.
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.
More information about the wp-hackers