Add metadata support for taxonomies

[sirzooro]

At this moment there is no dedicated way to store additional data for taxonomy. Plugin developers have to develop their own method for storing this data, e.g. by storing them encoded in description field or using set_option(). It will be good to add new functions for this, e.g. add_taxonomy_data()/get_taxonomy_data().

Since taxonomies can be hierarchical, if a certain taxonomy needs metadata why not just have a descendant taxonomy that handles the metadata? I've done this for several plugins.

For non-hierarchical taxonomies this may be an option. For hierarchical ones you have to implement way to distinguish parent metadata from child. I know it can be done, but it will be tricky :)

True. Another option is just to make another taxonomy, outside of the hierarchy, that handles the metadata.

Or maybe we should go to a general metadata table after all: #5183

Looks that with changes made in WP 2.9 for comments metadata this should be quite easy to implement - see attached path.

TODO: delete metadata when term is removed (and probably other things).

1st attempt (diff vs WP 2.9 RC1)

Can't we start to put the taxonomy meta functions into a class? I mean this is PHP 4 code, functions could be called staticly by plugin authors with only little overhead.

as suggested in #5183 I think it's worth to consider an "overall" meta api first. this can be factored upon the current comments metadata API which has been used as a pattern by sirzooro as well. Then Plugin authors can create on their own needs right away (and we would reduce code duplication as with the current patch).

Taken from #5183:

get_general_meta, update_general_meta, and delete_general_meta functions successfully.

By the way, update_meta and delete_meta would have been cleaner names, but they're already taken for admin post meta stuff.

#11847 closed as a duplicate of this.

See also #9674.

Replying to hakre:

as suggested in #5183 I think it's worth to consider an "overall" meta api first. this can be factored upon the current comments metadata API which has been used as a pattern by sirzooro as well. Then Plugin authors can create on their own needs right away (and we would reduce code duplication as with the current patch).

I really agree with this and wish that commentmeta had been general purpose instead of specific. I have use for linkmeta, termtaxonomymeta, termmeta, and termrelationshipmeta. I'd propose get_object_meta(), update_object_meta() delete_object_meta().

Not part of 3.0 scope.

I'm +1000 for this. Would love to utilize the update_metadata (and similar) functions, but with taxonomies it requires a custom table be created first. If wp_termdata existed it wouldn't be an issue.

+1, not every user needs this but many of us do and we need something that we can count on working forever.

+1, I believe this must be considered for the 3.1 release.

+1

Questions on what people are wanting: Meta for term_id, meta for taxonomy_term_id, meta for object_id+term_taxonomy_id` (i.e. for term_relationships), or a meta for all of them?

Personally, I think you should allow developers as much freedom as possible and therefore would ideally prefer meta on all of them, mikeschinkel.

A firm +1 from me on the 'idea' of this ticket.

Unfortunately, "developer freedom" comes at a high cost, much like "end-user freedom" when it comes to giving them a lot of options.

I think meta for term_id and for taxonomy_term_id would be enough. Meta for object_id+term_taxonomy_id can be stored as post meta.

BTW, CC list is getting longer and longer. Is it possible to include this ticket in 3.2 (preferable as Task)?

Currently, terms can be shared between taxonomies, although there is a trend against that: #5809

With such a shared term, it's much more likely that you will want to associate different metadata for different taxonomies.

Therefore, as it is now, if we add a term meta table, it should be connected via taxonomy_term_id only.

Flipping the coin, if we connect it via term_id only, it's easy to differentiate based on taxonomy, by adding the taxonomy name to the meta key, for example.

My point is that we should have one or the other, not both.

Replying to sirzooro:

BTW, CC list is getting longer and longer. Is it possible to include this ticket in 3.2 (preferable as Task)?

This won't become a task until consensus is reached, firstly on the usefulness of the feature, and secondly on the approach.

Replying to scribu:

Flipping the coin, if we connect it via term_id only, it's easy to differentiate based on taxonomy, by adding the taxonomy name to the meta key, for example.

My point is that we should have one or the other, not both.

FWIW, I have had need for both metadata for taxonomy_term_id and also for object_id+taxonomy_term_id (wp_term_relationships); I have not really had need for metadata for term_id.

FWIW, I have had need for both metadata for taxonomy_term_id and also for taxonomy_relationship_id;

The latter can be used with the former with the use of a prefix or suffix however, which tends to boil it back to only needing a tt_id metastore.

Replying to dd32:

The latter can be used with the former with the use of a prefix or suffix however, which tends to boil it back to only needing a tt_id metastore.

Sorry, I don't follow that at all. Can you give a use-case example to clarify?

Sorry, I don't follow that at all. Can you give a use-case example to clarify?

Example meta key with taxonomy_term_id, to apply to a specific tt for all relationships would be:

• 'colour' => red

If you needed relationship meta, ie. object_id+taxonomy_term_id for a specific tt to a specific object,

• $post->ID . '_colour' => red

My point, was that negates the need for a relationship meta table, and pushes it back to only needing the term_taxonomy meta

Replying to dd32:

Sorry, I don't follow that at all. Can you give a use-case example to clarify?

Example meta key with taxonomy_term_id, to apply to a specific tt for all relationships would be:

• 'colour' => red

If you needed relationship meta, ie. object_id+taxonomy_term_id for a specific tt to a specific object,

• $post->ID . '_colour' => red

My point, was that negates the need for a relationship meta table, and pushes it back to only needing the term_taxonomy meta

Thanks for the example.

So by that logic we don't actually need taxonomy meta at all. Instead we can just use wp_options with a prefix like this:

• 'taxterm_' . $taxonomy_term->taxonomy_term_id, and
• 'taxtermrel_' . $post->ID . '_' . $taxonomy_term->taxonomy_term_id

Right?

So by that logic we don't actually need taxonomy meta at all. Instead we can just use wp_options with a prefix like this:

Technically, Yes, It can be done that way, same as Postmeta can be done that way.

But I'm basing that off the current methodologies used in WordPress already for meta.

We have User Meta, which is per-user, however, in that same item, we can apply meta for user+site or user+network Meta, this is roughly the same as TT Meta, TT+Object Meta.

The reasoning for saying it like that, Is that Meta for objects always has a primary target, which is where the majority of the meta goes in 99% of scenario's, which is followed by a few other related spurs, which 10% of sites might use 1% of the time on average.

To make a specific table for (for example) taxonomy relationships to objects would probably fall into the 95/5% use case bin, where for the 5% that need it, 75% of those will find a prefix a working solution. The others will feel the need for a new table. Those that need the new table in the specific implementations are free to do so if they desire the extra performance gains that it may give them.

Replying to dd32:

The reasoning for saying it like that, Is that Meta for objects always has a primary target, which is where the majority of the meta goes in 99% of scenario's, which is followed by a few other related spurs, which 10% of sites might use 1% of the time on average.

To make a specific table for (for example) taxonomy relationships to objects would probably fall into the 95/5% use case bin, where for the 5% that need it, 75% of those will find a prefix a working solution. The others will feel the need for a new table. Those that need the new table in the specific implementations are free to do so if they desire the extra performance gains that it may give them.

Fair point. But let's look at statistics from another perspective.

For almost any site that uses or needs taxonomy meta the likelihood of having more than 1000 term_taxonomy records in a given taxonomy is very low; wouldn't you agree? As such, optimizing it doesn't really make much sense; we can easily simulate with wp_options and 'taxterm_' . $taxonomy_term->taxonomy_term_id without any scalability issues.

On the other hand the likelihood of having 1000 or even 10,000 or more wp_term_relationships records is reasonably high and the chances of 100,000+ or even 1 million such records is not complete remote. So leaving the only option in core for term_relationship meta to use a 255 byte key effective ensures it cannot be use for any site that might grow beyond a moderate number of post records in order to optimize for the case that won't ever need to scale.

Given that analysis if I was given the option to ONLY have meta for term_taxonomy_id OR for object_id+term_taxonomy_id I would pick the latter because it would be easy to simulate the former in a performant way with 0+term_taxonomy_id.

I'm all for this feature to be added and would like to share my experiences with taxonomy meta as well as my thoughts on why a term meta table is important in core.

I created a  taxonomy images plugin a while ago and it has been really well received. It stores a serialized array of image->ID => term_taxonomy_id in a single row of the options table. While this is not ideal it seems to work and will accommodate thousands of image/term associations. I thought all was well and then one day I received a  support request alerting me that my plugin did not retain associations when a user moved a blog using the  WordPress Importer plugin.

Having a core term meta table that is able to be imported/exported from one installation to another is very important.

I would also like to become more involved in core. If this enhancement is accepted I am more than willing to help see it through for 3.2.

Best, -Mike

@Mike and @dd32: If you're replying to the message exactly above, please don't quote the entire thing again. It uselessly clutters the screen. Thanks.

@mfields: Isn't there a hook in the exporter and importer for adding your custom tables?

@scribu: You've definitely inspired me to take a look at the code in the importer/exporter to see what I can do! Thanks for that. If it's relatively easy and sound to send custom data to and fro, then maybe a core termmeta table is not as necessary as I thought.

Related #17477

As Otto has said countless times, terms are just a convenient name for a group of posts in a taxonomy, which is a named set of groups. They're not meant to hold any data of their own.

If you find yourself needing to add additional fields to terms, you should actually make them posts and link them to other posts. See #14513

In other words, post-to-post relationships is the more appropriate solution.

We haven't ruled this out. Closing instead as maybelater.

@nacin

You mentioned somewhere about writing out a guide on how you'd do this for core if implemented. Did you ever get around to that? I'd just like to future-proof some stuff I'm working on as much as possible.

Replying to scribu:

As Otto has said countless times, terms are just a convenient name for a group of posts in a taxonomy, which is a named set of groups. They're not meant to hold any data of their own.

If you find yourself needing to add additional fields to terms, you should actually make them posts and link them to other posts. See #14513

In other words, post-to-post relationships is the more appropriate solution.

What if someone wanted to create a "category image" plugin? Or, add SEO features (meta, keywords, title) to category archive pages?

These are just simple examples of extra fields someone might want to add to terms. Obviously, there are some things better handled by post-to-post relationships, but not everything fits into this scenario.

Replying to greenshady:

@nacin

You mentioned somewhere about writing out a guide on how you'd do this for core if implemented. Did you ever get around to that? I'd just like to future-proof some stuff I'm working on as much as possible.

I didn't, mainly because after a few conversations we couldn't come up with a good way to do this for core.

As described in #17477, we don't pass around term_taxonomy_id in our API, but rather term_id, which requires one to also pass around the taxonomy argument. For a meta table, ideally we'd want just one key (thus term_taxonomy_id) rather than two (term_id, taxonomy) but our current taxonomy API doesn't really allow for that (and our metadata API doesn't allow for the other). So I don't think this can happen in core until our API grows further.

There are three plugins in the directory [1]. IIRC, one uses term_taxonomy_id, one uses term_id (alone), one uses term_id + taxonomy. They seem to use different terminology for either function names, field names, or table names.

[1]
 http://wordpress.org/extend/plugins/simple-term-meta/ (removed, unsupported by author)  http://wordpress.org/extend/plugins/taxonomy-metadata/  http://wordpress.org/extend/plugins/meta-for-taxonomies/

Found on WordPress codex - How to Add Metadata to a Term:  http://codex.wordpress.org/Function_Reference/add_metadata#Add_Metadata_to_a_Term

(Using Metadata API located in wp-includes/meta.php)

Examples for things like that shouldn't be on the Codex.

I'd rather a low-level function like get_metadata() to not even be on the Codex.

Replying to nacin:

There are three plugins in the directory [1]. IIRC, one uses term_taxonomy_id, one uses term_id (alone), one uses term_id + taxonomy. They seem to use different terminology for either function names, field names, or table names.

 http://wordpress.org/extend/plugins/simple-term-meta/ (removed, unsupported by author)  http://wordpress.org/extend/plugins/taxonomy-metadata/  http://wordpress.org/extend/plugins/meta-for-taxonomies/

Nice list. Which is closest to an implementation that the core team would consider?

any movement on this for 3.4? Just as an example: right now I need to implement a taxonomy header image, and there is no clean way to do it. There are so many other use-cases for taxonomy meta.

I wrote a blog post a while back on storing taxonomy meta data in the options table:

 http://www.strangework.com/2010/07/01/how-to-save-taxonomy-meta-data-as-an-options-array-in-wordpress/

Not ideal for large amounts of data, but if you have a small number of taxonomy terms it works great!