WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 2 months ago

#10142 reopened feature request

Add metadata support for taxonomies

Reported by: sirzooro Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords: has-patch needs-testing 2nd-opinion
Focuses: Cc:

Description

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().

Attachments (1)

taxmeta.diff (4.3 KB) - added by sirzooro 4 years ago.
1st attempt (diff vs WP 2.9 RC1)

Download all attachments as: .zip

Change History (105)

comment:1 filosofo5 years ago

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.

comment:2 sirzooro5 years ago

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 :)

comment:3 filosofo5 years ago

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

comment:4 ryan4 years ago

  • Milestone changed from 2.9 to Future Release

comment:5 sirzooro4 years ago

  • Keywords has-patch needs-testing 2nd-opinion added
  • Milestone changed from Future Release to 3.0

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).

sirzooro4 years ago

1st attempt (diff vs WP 2.9 RC1)

comment:6 hakre4 years ago

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.

comment:7 follow-up: hakre4 years ago

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).

comment:8 hakre4 years ago

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.

comment:9 nacin4 years ago

#11847 closed as a duplicate of this.

See also #9674.

comment:10 in reply to: ↑ 7 mikeschinkel4 years ago

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().

comment:11 nacin4 years ago

  • Milestone changed from 3.0 to Future Release

Not part of 3.0 scope.

comment:12 filosofo4 years ago

  • Owner filosofo deleted
  • Status changed from new to assigned

comment:13 williamsba14 years ago

  • Cc brad@… added

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.

comment:14 blepoxp4 years ago

  • Cc glenn@… added

comment:15 kevinB4 years ago

  • Cc kevinB added

comment:16 jeremyclarke4 years ago

  • Cc jer@… added

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

comment:17 atoon4 years ago

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

comment:18 scribu4 years ago

  • Cc scribu added

comment:19 mfields3 years ago

  • Cc michael@… added

comment:20 tetele3 years ago

  • Cc tetele added

comment:21 ramiy3 years ago

  • Cc ramiy added

+1

comment:22 travisnorthcutt3 years ago

  • Cc travisnorthcutt added

comment:23 mikeschinkel3 years ago

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?

comment:24 iamfriendly3 years ago

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.

comment:25 scribu3 years ago

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

comment:26 sirzooro3 years ago

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.

comment:27 follow-up: sirzooro3 years ago

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

comment:28 follow-up: scribu3 years ago

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.

comment:29 in reply to: ↑ 27 scribu3 years ago

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.

comment:30 in reply to: ↑ 28 mikeschinkel3 years ago

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.

Last edited 3 years ago by mikeschinkel (previous) (diff)

comment:31 follow-up: dd323 years ago

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.

comment:32 in reply to: ↑ 31 mikeschinkel3 years ago

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?

comment:33 follow-up: dd323 years ago

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

comment:34 in reply to: ↑ 33 mikeschinkel3 years ago

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?

comment:35 dd323 years ago

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.

comment:36 follow-up: dd323 years ago

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.

comment:37 in reply to: ↑ 36 mikeschinkel3 years ago

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.

Last edited 3 years ago by mikeschinkel (previous) (diff)

comment:38 mfields3 years ago

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

comment:39 scribu3 years ago

@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?

comment:40 mfields3 years ago

@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.

comment:41 bainternet3 years ago

  • Cc bainternet added

comment:42 pento3 years ago

  • Cc pento added

comment:43 petehobo3 years ago

  • Cc petehobo added

comment:44 knutsp3 years ago

  • Cc knut@… added

comment:46 follow-up: scribu3 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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.

comment:47 nacin3 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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

comment:48 nacin3 years ago

  • Resolution set to maybelater
  • Status changed from reopened to closed

comment:49 in reply to: ↑ 46 ; follow-up: greenshady3 years ago

@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.

comment:50 in reply to: ↑ 49 ; follow-up: nacin3 years ago

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]

Last edited 2 years ago by scribu (previous) (diff)

comment:51 ramiy3 years ago

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)

comment:52 nacin3 years ago

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

comment:53 nacin3 years ago

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

comment:54 stephenh19882 years ago

  • Cc stephenh1988 added

comment:55 in reply to: ↑ 50 mikeschinkel2 years ago

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?

comment:56 Mamaduka2 years ago

  • Cc georgemamadashvili@… added

comment:57 Chouby2 years ago

  • Cc frederic.demarle@… added

comment:58 dwenaus2 years ago

  • Cc deryk@… added

comment:59 dwenaus2 years ago

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.

comment:60 williamsba12 years ago

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!

comment:61 pauldewouters2 years ago

  • Cc pauldewouters added

comment:62 husobj2 years ago

  • Cc ben@… added

comment:63 jtsternberg2 years ago

  • Cc justin@… added

comment:64 dominicp2 years ago

  • Cc dominicparisi@… added

comment:65 eddiemoya2 years ago

  • Cc eddie.moya+wptrac@… added

comment:66 emzo2 years ago

  • Cc emzo added

comment:67 dempsey2 years ago

  • Cc dempsey@… added

comment:68 jfarthing842 years ago

  • Cc jeff@… added

comment:69 redrings2 years ago

added

Version 0, edited 2 years ago by redrings (next)

comment:70 redrings2 years ago

  • Cc robert@… added

comment:71 stephenh19882 years ago

  • Cc stephenh1988 removed

comment:72 dominicp23 months ago

  • Cc dominicparisi@… removed

comment:73 wpsmith23 months ago

  • Cc travis@… added

comment:74 jazbek21 months ago

  • Cc j.yzbek@… added

comment:75 rogercoathup21 months ago

  • Cc rogercoathup added

comment:76 dnaber-de20 months ago

  • Cc dnaber-de added

comment:77 hughwillfayle20 months ago

  • Cc t.herzog@… added

comment:78 ryno26719 months ago

really would love to see this in 3.5 or soon...

comment:79 ramiy19 months ago

I'm just thinking loud, but why not adding an extra theme feature:

add_theme_support( 'taxonomy-thumbnails' );

just like:

add_theme_support( 'post-thumbnails' );

using the new taxonomy metadata, of course, when it will be available.

comment:80 goblindegook19 months ago

  • Cc goblindegook added

comment:81 maor19 months ago

  • Cc maorhaz@… added

comment:82 AliMH18 months ago

  • Version set to 3.4.2

i don't think it's really a need for wordpress right now, i developed my own movie review site and though to have extra field per term but after a little thinking i found term description enough so just create a CPT and add all you need at a post then store postid in term description, when ever you wanna need anything (like images, rating,custom fields and..) will use that postid to show them, here is my example:
http://www.animcentral.com/directors/kichi-mashimo

comment:83 SergeyBiryukov18 months ago

  • Version 3.4.2 deleted

comment:84 aaemnnosttv18 months ago

  • Cc aaemnnosttv added

comment:85 082net17 months ago

As term and taxonomy is related to objects(almost to posts), I think we better go with 'nav menu' like system. And if we need 'REAL' metadata, then we can use postmeta system.

Advantage of following 'nav menu' system is much more than just using 'metadata', considering about what we need is... not a metadata but a relationship for objects or just an object.

Agree with scribu

comment:86 andyadams17 months ago

  • Cc aadams@… added

comment:87 dwenaus17 months ago

  • Cc deryk@… removed

comment:88 kwight16 months ago

  • Cc kwight@… added

comment:89 F J Kaiser16 months ago

As I need this regularly, I've writte my own solution: Missuses the "description" field as storage container for a serialized array. The only thing that was a little tricky was to display the plain description in the admin UI. Anyway this would be the solution I was hoping for: Simply convert the description field instead of adding a bunch of new fields. If there's a need for it, then we will see the use cases after we got it and move for a searchable solution with a later version. Just my two cents...

comment:90 follow-up: husobj16 months ago

It's also worth noting here that in a lot of plugins I've seen that add meta for taxonomies, the metadata is stored against the term_id.

This means that if a term is used by multiple taxonomies you can only store one set of data for it rather than one for each taxonomy - better to attach to term_taxonomy_id perhaps?

comment:91 in reply to: ↑ 90 stephenh198816 months ago

Replying to husobj:

It's also worth noting here that in a lot of plugins I've seen that add meta for taxonomies, the metadata is stored against the term_id.

I think normally plug-ins doing this are adding in a meta table for a specific taxonomy. In general, yes it would require the term_taxonomy_id to be used - unfortunately, the taxonomy API passes around term-taxonomy pairs rather than the term_taxonomy_id.

Nacin mentioned earlier that for that reason the API needs to 'grow'. I heard via twitter that a (long) roadmap was draw up. Sounded like it involved several table reshuffles... My point is that as eager as I am to see this in core - there is no immediate solution :(.

comment:92 brokentone15 months ago

  • Cc kenton.jacobsen@… added

comment:93 goto1014 months ago

  • Cc dromsey@… added

comment:94 DuGi_dk14 months ago

  • Cc DuGi_dk added

comment:95 follow-up: sil.linguist13 months ago

  • Cc sil.linguist added

Someone above mentioned that it is highly unlikely that a single taxonomy will have more than 1000 terms. I have a use case where I have a taxonomy with over 7000 terms. And these terms do have meta as well. In a way the post-to-post relationships makes sense for taxonomies this large and detailed. [1] Has anyone on the list here attempted a typology of use caes? Would such a discussion possibly bring us to a point where consensus could be achieved?

Not mentioned yet in the discussion, is the ability to turn any CPT into a taxonomy. If we go the route that taxonomies need to be just as flexible as CPTs (with respect to meta) then why does core support taxonomies as a separate object type? Just add to core the ability to make a CPT function as a taxonomies would have functioned. There is a plugin which sorta does this: http://wordpress.org/extend/plugins/cpt-onomies/

BTW: I deal with language and linguistic data.

[1] http://wordpress.org/extend/plugins/posts-to-posts/

comment:96 in reply to: ↑ 95 F J Kaiser13 months ago

Replying to sil.linguist:

Someone above mentioned that it is highly unlikely that a single taxonomy will have more than 1000 terms. I have a use case where I have a taxonomy with over 7000 terms.

Has anyone on the list here attempted a typology of use caes? Would such a discussion possibly bring us to a point where consensus could be achieved?

Just add one pretty common use case: Locations. In some installations I built, I got locations as hierarchical taxonomy - Country/State/District. There're currently (depending on the definition of state) ~196 countries in the world. You can guess the number of states and districts.

comment:97 tar.gz11 months ago

  • Cc code@… added

comment:98 mboynes9 months ago

  • Cc mboynes@… added

comment:99 maxaud8 months ago

  • Cc dustin@… added

comment:100 ocean905 months ago

#25902 was marked as a duplicate.

comment:101 prionkor3 months ago

  • Cc prionkor.business@… added

comment:102 follow-up: TweetyThierry2 months ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened

Hi all,

Personally I think there should the a wp_termmeta table (term_id, term_meta, term_value) which works the same way as the postmeta. This would handle scalability, keep it conventional and well organized. The saving part would simply use update_term_meta() and the deleting part would then be automated just like the post works with custom metas.

I am happy to contribute if necessary.

Thanks,

Last edited 2 months ago by TweetyThierry (previous) (diff)

comment:103 SergeyBiryukov2 months ago

  • Milestone set to Awaiting Review

comment:104 in reply to: ↑ 102 helen2 months ago

Replying to TweetyThierry:

I suppose this was a "maybelater" because there are some other steps to take first. You'll probably be interested in this: http://make.wordpress.org/core/2013/07/28/potential-roadmap-for-taxonomy-meta-and-post-relationships/

Note: See TracTickets for help on using tickets.