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

[Mike Schinkel]

On Jul 13, 2011, at 6:21 PM, Otto wrote:
> I agree with the need for a custom post type in the given example. I'm
> just not sure why you can't use the existing relationship methods
> instead of creating something special for it.

Yes, in many ways something special is not "needed."  We both agree that one of the beauties of WordPress is its ability to let us extend it in practically whatever way we see the need to.  

But extending for a use-case doesn't benefit more than the people who extend it and/or the few who happen to use a specific plugin.  Taxonomy metadata has been downloaded 480 times.  Said another way, 0.01% of sites are using it.  How many sites are using the infrastructure of Custom Post Types?  Over 3.4 million of them. There were many ways to get CPT-like functionality in WP 2.9, but a very tiny percentage of people used them and almost nobody built on top of them because there was no identified standard.  Yet since 3.0 was released CPTs have become a fundamental building block for people extending WP.

So when a request for functionality emerges constantly its often because there is a fundamental pattern not being addressed.  Baking the solution to that pattern into the core allows people to build on a shared infrastructure instead of having to constantly reinvent the wheel and having to build all related functionality themselves.  So when I advocate these things I advocate for a shared "standard" way of addressing a common use-case pattern, and currently only WordPress core can set such as standard.

> For example, let say you have a taxonomy for your locations here.
> You're applying it to normal posts. Now you have a need for something
> to display the description to be used on the archive pages. For this,
> I'd use a CPT called location-info or something. To then associate it
> to that term in the location taxonomy, I'd simply give it that term.
> Put it in that taxonomy with the term I want. Your query in the
> template table to display that location-info post is then simply a
> matter of retrieving the location-info CPT for the taxonomy-term that
> *you're already trying to display* for posts as well. It's a natural
> mechanism. Group the posts into the taxonomy and the location-info CPT
> into that taxo as well.

That is definitely one way of doing it, and it is also one of the ways that motivated end-users are able to build incredible websites that work for their needs using WordPress. It is a huge benefit that WP can do this. 

But it does require a lot of data maintenance effort on the part of the end-user, and when the end-users are not highly motivated to understand how to maintain the connections (i.e. when they are 9-to-5er employees or others who don't own the site) this approach falls down.  The non-motivated users shouldn't have to know to first add a taxonomy term and then add a related post and apply the same taxonomy term, especially when the term and the related post have a 1-to-1 correspondence.  And while the data maintenance overhead might be acceptable for a website that showcase 5 major cites it would not work for sites where there there is a post for every city in the country because the data maintenance burden would be too great.

Yes, this linkage could be automated but you'll find when you start doing so it becomes overly cumbersome and complex which is, ironically the exact reason you gave for not wanting taxonomy meta.  To illustrate the relative complexities between what you propose here and taxonomy meta consider the two MySQL queries (I am using SQL just to illustrate complexity, I know WP caches data but the less complex the SQL the less complex the cache lookups end up being):

Shared Taxonomy Terms (6 JOINS)
======================
SELECT 
	* 
FROM 
	wp_posts post
	INNER JOIN wp_term_relationships ptr ON post.ID=ptr.object_id
	INNER JOIN wp_term_taxonomy ptt ON ptr.term_taxonomy_id=ptt.term_taxonomy_id
	INNER JOIN wp_terms pt ON ptt.term_id=pt.term_id
	INNER JOIN wp_term_relationships ptc ON ptt.term_taxonomy_id=ptc.term_taxonomy_id
	INNER JOIN wp_posts city ON ptc.object_id=city.ID
	INNER JOIN wp_postmeta cm ON city.ID=cm.post_id
WHERE
	pt.slug='san-fran'
    

Shared Taxonomy Terms (4 JOINS)
======================
SELECT 
	* 
FROM 
	wp_posts post
	INNER JOIN wp_term_relationships ptr ON post.ID=ptr.object_id
	INNER JOIN wp_term_taxonomy ptt ON ptr.term_taxonomy_id=ptt.term_taxonomy_id
	INNER JOIN wp_terms pt ON ptt.term_id=pt.term_id
	INNER JOIN wp_taxonomymeta ptm ON ptt.term_taxonomy_id=ptm.term_taxonomy_id
WHERE 
	pt.slug='san-fran'
    
If we want less complex then taxonomy meta is definitely the less complex of the two. And having a taxomomy meta would mean that we could add custom fields into the taxonomy edit screens and then that themes could assume it is any taxonomy meta is meta they might might want to be able to display.  

Of course themes can already display information via the linked taxonomy approach but maybe the fact that so few do it is telling?
    
> This seems pretty universal to me. For all the cases where a
> custom-tax needs a meta, because you're storing something special
> about each term in the tax (like a description), then a CPT with that
> term will associate it. It's simple enough to do and it makes your
> queries natural. When you query, you get posts. If you query for a CPT
> and the term, you'll get the post with that term. And it can let you
> make multiple entries too, since you can make more than one post in
> your CPT.

In the case of associated posts I would then argue that we need a standard and performant approach to enable this so that the WordPress community will gravitate around the standard.  Maybe the addition of a 'post_id' field to wp_term_taxonomy?  Otherwise we just get a bunch of differently implemented hacks with no real ability for anyone to build on the work of others without bundling their plugin which itself is problematic.

So there's a need for both use-cases, taxonomy meta and related posts.  It would be nice if WordPress core could provide the leadership needed for these use-cases, but I am also long resigned to appreciate that doing it likely not in interest those who make said decisions.  (And with that, I'll be leaving this discussion for now so I can get back to actually writing the code I spoke of. :)

-Mike
[1] http://wordpress.org/extend/plugins/taxonomy-metadata/
[2] http://wordpress.org/about/stats/

>