[wp-hackers] Term Meta - Trac'd already?

[The WordPress Web Warlock]

Al 13/07/2011 20:43, En/na Otto ha escrit:
> What's your use case?
> (...)
> I'm not saying that there isn't a use case, I just don't know of one
> off the top of my head, and would be interested in finding a good one.
>
> -Otto

I'm developing a *big* term meta based plugin (indeed, I've talked some 
times about it in this list). I'll name some of its features (the ones I 
can remember right now):

· Multiple term parentage. Have your flowers sorted both by type and 
color, and list all your posts on "Red Roses" category under the cats 
"Flowers>By color>Red flowers" and "Flowers>By Type>Roses".
· A term group system that allows multiple parentage for the term 
groups. Like, "Venn diagrams" and such. (Please note that you can't do 
better with any taxonomy-based system, because taxonomy-based systems 
are taxonomical; that is, they "grow like a tree": any parent (branch) 
can have any number of children, but any given children has only one 
parent. This is, one-to-many relationships. I'm talking about 
many-to-many relationships: all red roses are red flowers AND roses with 
a given color). This system of mine does not add a table for each 
taxonomy in the relationship, and thus scales far better. Because, well, 
taxonomies are really not needed if you already have some other 
hierarchy system (they are, though, imprescindible... because the 
relationships table maps to term_taxonomy table, not terms table).
·Thumbnails for terms. Sorry... I meant "featured images".
·Custom order for any given term. (We were talking about this one abouth 
a month ago...)
·Custom order for any given term when listed from another term (either 
parent or children). List Patrick Stewart as "Patrick Stewart" under 
"Actors>P" and "Stewart, Patrick" under "Actors>S".
·Label system for terms. Same for descriptions. You may use "Click here 
to see all the posts in Uncategorized" for term lists, and "Add here the 
posts that don't belong to any other category" in the admin UI 
(user-oriented design).
·Select template on a per-term basis. You don't need to copy 
category-1.php to three differently named files if you want use it four 
times: you can reuse the very same template as many times as you want 
(which, btw, is the whole philosophy behind templates, isn't it?). 
Neither you do have to go looking for IDs, or rename the same template 
used in different WP installations (same terms across different blogs 
don't usually share IDs, so this can be a nightmare to update and 
maintain). A dropdown list or a humble textbox is much easier. (BTW, 
this also enhances the versatility of themes: they don't need the user 
to rename/change/add any file, just to select different values in a 
textbox/dropdown).
·Link any term to any Page (hooking to get_term_link).
·Restrict the meta boxes and "taxonomy boxes" with a term dependency 
system. If you're not talking at all about any "place", you really don't 
need the "places" metaboxes... and not loading it is better than loading 
it and then unloading it.
·If you can allow something, you can also forbid something... so you 
could also hide parts of the admin section for the posts of a given term.
·And, obviously, do things as "lock" terms (do not allow users to unset 
or set that term), or display icons instead of text in the admin 
section. If the icons are recognizable, this may save space while being 
user-friendly (think of, say, the PEGI classification system).
·Also, make term groups "one only": allow posts to be only in one term 
of a given group. Easy to do with radio buttons. (PEGI system, again: if 
a game is for 12 or older, it cannot be for 16 or older also).
·A much more user-oriented interface. If two terms share the same name, 
the current UI does not let you know which is which, neither allows you 
to add any clue to the user. But you can use the label system, add TITLE 
attributes...
·Automatically add custom fields to any post that belongs to a term. 
Since terms and posts have many-to-many relationships (the only objects 
to do so by default in WP), you can use this with "cascading effect"
·Auto-replace terms (see "term alias" below) and autoinclude terms on a 
per-term basis (if you're talking about Seattle, you're also talking 
about the United States, though not the USA "as a whole"). This is 
specially useful with widgets. given the way that "post count" of terms 
are implemented in WP. The post count is strict: if a term has zero 
posts to it, its count is 0, even if its child terms *do* have posts 
assigned to it. If the widget was to stop listing at the "zero count" 
parent level, and the option of "Hide empty terms" was set on true, the 
term wouldn't display, even if its children have posts, because the 
(recursive) count (stopped at the zero-count parent) would yield 0.
·And well, yes, this "auto-replace" terms option can easily bring to 
property inheritance. Like if it worked like an OOP object class and 
so... ("All the includers of these term shall have a coulour, and shall 
have a name, and shall have a flowertype"). It's possible that someone 
can find this feature marginally useful.
·Incidentally, you can also have the *two counts* (both "strict" and 
"extended") with term meta.
·Link terms to term groups. That is, say, "display all the posts that 
have place-related info".
·HTML/CSS goodies like custom classes by term, or term group...
·Custom query terms. You do not assign posts to these terms: these 
return posts that comply with the specified query parameters. And this 
would be a part of the term system (which Pages aren't, so it's not only 
about displaying a query.).
·Term alias. Make a term an alias of other terms. (Yes, I know... there 
is *already something like this* buried deep inside WP, without a clue 
of how would it work, and how it's supposed to be used.)
·Link terms to anything, like users or dates. An easy way to 
multi-credit a post ("Photos by X and Z, text by T, via wordpress.com. 
Published by admin."). Or to see all the things you did write in a 
Wednesday. Or with full moon.
·Term by permissions. Specify custom permissions, roles and caps on a 
per-term basis (say, specific permissions to edit a given term, or even 
to know that a given term exists). And viceversa (require a given 
permission to see the posts of a given term. This can be done 
accumulatively and also in cascade). List all posts that require a given 
cap. Or allow exceptions to permissions on a per term basis. Or whatever 
combination of cap/cat/perm/role.

And my fav feature:

·Combine some, or all, of the above. Have a list terms widget that lists 
terms in a custom order, displaying a term thumbnail, and having a 
widget-special description in the TITLE attribute (again, this is only 
for user experience). Extra points if it's a definition list (dl, not li 
or ol) that uses term meta for the description (dd). Use the term 
thumbnails in the admin meta boxes. Have a term that adds not only its 
own custom fields, but also of the terms it "includes". Have custom 
fields by term group, term group templates. Have the alias automatically 
replace itself with the "aliased" term (This feature, for instance, 
would have save Wikipedia editor's time; there's a bit of a mess, say, 
with categories of "American Actors" and "North American Actors", 
because for many people outside the US —and some inside, AFAIK— 
"America" means "*both* North and South America", not USA). Skip the 
alias from listings with some term-meta enabled widget.

I use term meta mostly as options work, meaning that there are lots of 
term meta which "autoload" on init (actually, right now I'm autoloading 
all term meta). This means that for all the above features, I need just 
1 query, the object cache and some parsing. (I mean that, therefore, 
termmeta are not quite like postmeta, commentmeta or usermeta as much as 
options. But it's best to use, instead of wp_options, just a termmeta 
that maps to a term_id: in wp_options we'd need additional info just to 
mark that it should map to terms.)

And when you combine term meta with a term meta enabled theme, you can 
do a lot of sweet things (mostly, again and again, very user-friendly). 
Easily change the number of columns in a template (you should just need 
to specify a single value somewhere if you just want to change the 
number of columns). Template variations on a per-term basis. Integration 
of all that custom-field-by-term stuff with templates, to sort or 
display by those keys. Or show them automatically, should them exist. 
rewind_posts() and show different subsets by term, or term group: I do 
this to make the reference for my functions (kinda a WP-powered Codex 
with wikifeatures). Have "description posts", regular posts that link to 
a term (via postmeta) and are used by it (via termmeta) as a description 
in the template. (Think of how Wikithings list their Pages and 
categories, and make it more user-friendly: users don't care if they are 
about to read "Posts", "Pages", "Custom Taxonomy Wobbly Thingie" or 
whatever. They just want all you've got, say, on red roses or naval 
battles involving the USA and Turkey during the Korea War, or clam 
cellphones with camera of at least 3Mpx, but don't care the brand, and 
in the $50-150 range). If you get many questions like that (like, if 
you're running a store or talk about lots of gizmos in your householding 
blog), you need terms like those. You can also automatically add, say, 
preselected terms to a new post in a given category. And things like 
sorting, metakeys, meta_num, additional data... are really easy to 
implement in a template. Same with stylesheets, specialty HTML header 
info that maybe couldn't be fit in wp_head, who knows... You can use a 
single Page named as category.php for an incredible lots of things, just 
with termmeta and the Page's own postmeta (again, with cascading or 
defaults/fallback effect).

Or, sort the categories/terms to use them as a description/excerpt: 
"*Review* of the *Tron Legacy* movie: *three star* rating. Looks like a 
*Daft Punk* *videoclip*". A clean description, with links to five 
meaningful cats there. (Oh, the "three star" could actually display a 
—termmeta— thumbnail of three stars. And have —by termmeta— some rating 
microformat. First one looks nice for the users, second one is SEO good.)

(BTW: get_template_part rocks. And with termmeta, you can break down 
sections and select the "section template" on a per-term basis.)

Maybe the most important thing here is that I'm possibly using another 
paradigm on what are terms —the old-fashioned, "wordy" way. (Which is: 
Words are each unique combination of form —morpheme— and meaning —seme, 
or "mix of semantic fields"—. A morpheme is not a word. Words are 
arbitrary and conventional. Different words may be homonimous —have the 
same morpheme—. A morpheme may relate to different words —that's 
ambiguity—. I use terms as "wordy" words.). I'm doing things this way 
because terms are the only thingies that posts can relate many-to-many. 
So, basically, by assigning posts to terms, I'm describing them and 
saying what they are, usign a hierarchy of meanings, because this can't 
be done with nothing else in WordPress (posts can only be of a single 
posttype, which do not have any kind of many-to-many hierarchy, etc.), 
and because terms are the best things in all WP to do this very job. 
Actually, it's the very job that "terms" do in other contexts —like 
encyclopaedias or library management, like the DCU.

Best,

Xavier

PS.: For the more curious, I've got a severely outdated version of it 
working at web-warlocks.net. By "severely" I mean "one year old" in 
plugin development time... so don't take it too seriously.