WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 7 weeks ago

#10142 reopened feature request

Add metadata support for taxonomy terms

Reported by: sirzooro Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords: needs-patch
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 6 years ago.
1st attempt (diff vs WP 2.9 RC1)

Download all attachments as: .zip

Change History (115)

comment:1 @filosofo6 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 @sirzooro6 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 @filosofo6 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 @ryan6 years ago

  • Milestone changed from 2.9 to Future Release

comment:5 @sirzooro6 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).

@sirzooro6 years ago

1st attempt (diff vs WP 2.9 RC1)

comment:6 @hakre6 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: @hakre6 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 @hakre5 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 @nacin5 years ago

#11847 closed as a duplicate of this.

See also #9674.

comment:10 in reply to: ↑ 7 @mikeschinkel5 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 @nacin5 years ago

  • Milestone changed from 3.0 to Future Release

Not part of 3.0 scope.

comment:12 @filosofo5 years ago

  • Owner filosofo deleted
  • Status changed from new to assigned

comment:13 @williamsba15 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 @blepoxp5 years ago

  • Cc glenn@… added

comment:15 @kevinB5 years ago

  • Cc kevinB added

comment:16 @jeremyclarke5 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 @atoon5 years ago

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

comment:18 @scribu5 years ago

  • Cc scribu added

comment:19 @mfields5 years ago

  • Cc michael@… added

comment:20 @tetele5 years ago

  • Cc tetele added

comment:21 @ramiy5 years ago

  • Cc ramiy added

+1

comment:22 @travisnorthcutt4 years ago

  • Cc travisnorthcutt added

comment:23 @mikeschinkel4 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 @iamfriendly4 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 @scribu4 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 @sirzooro4 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: @sirzooro4 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: @scribu4 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 @scribu4 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 @mikeschinkel4 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 4 years ago by mikeschinkel (previous) (diff)

comment:31 follow-up: @dd324 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 @mikeschinkel4 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: @dd324 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 @mikeschinkel4 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 @dd324 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: @dd324 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 @mikeschinkel4 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 4 years ago by mikeschinkel (previous) (diff)

comment:38 @mfields4 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 @scribu4 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 @mfields4 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 @bainternet4 years ago

  • Cc bainternet added

comment:42 @pento4 years ago

  • Cc pento added

comment:43 @petehobo4 years ago

  • Cc petehobo added

comment:44 @knutsp4 years ago

  • Cc knut@… added

comment:46 follow-up: @scribu4 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 @nacin4 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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

comment:48 @nacin4 years ago

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

comment:49 in reply to: ↑ 46 ; follow-up: @greenshady4 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: @nacin4 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 3 years ago by scribu (previous) (diff)

comment:51 @ramiy4 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 @nacin4 years ago

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

comment:53 @nacin4 years ago

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

comment:54 @stephenh19884 years ago

  • Cc stephenh1988 added

comment:55 in reply to: ↑ 50 @mikeschinkel4 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 @Mamaduka3 years ago

  • Cc georgemamadashvili@… added

comment:57 @Chouby3 years ago

  • Cc frederic.demarle@… added

comment:58 @dwenaus3 years ago

  • Cc deryk@… added

comment:59 @dwenaus3 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 @williamsba13 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 @pauldewouters3 years ago

  • Cc pauldewouters added

comment:62 @husobj3 years ago

  • Cc ben@… added

comment:63 @jtsternberg3 years ago

  • Cc justin@… added

comment:64 @dominicp3 years ago

  • Cc dominicparisi@… added

comment:65 @eddiemoya3 years ago

  • Cc eddie.moya+wptrac@… added

comment:66 @emzo3 years ago

  • Cc emzo added

comment:67 @dempsey3 years ago

  • Cc dempsey@… added

comment:68 @jfarthing843 years ago

  • Cc jeff@… added

comment:69 @redrings3 years ago

would like to be able to add link and image fields to custom taxonomies

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

comment:70 @redrings3 years ago

  • Cc robert@… added

comment:71 @stephenh19883 years ago

  • Cc stephenh1988 removed

comment:72 @dominicp3 years ago

  • Cc dominicparisi@… removed

comment:73 @wpsmith3 years ago

  • Cc travis@… added

comment:74 @jazbek3 years ago

  • Cc j.yzbek@… added

comment:75 @rogercoathup3 years ago

  • Cc rogercoathup added

comment:76 @dnaber-de3 years ago

  • Cc dnaber-de added

comment:77 @hughwillfayle3 years ago

  • Cc t.herzog@… added

comment:78 @ryno2673 years ago

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

comment:79 @ramiy3 years 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 @goblindegook3 years ago

  • Cc goblindegook added

comment:81 @maor3 years ago

  • Cc maorhaz@… added

comment:82 @AliMH3 years 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 @SergeyBiryukov3 years ago

  • Version 3.4.2 deleted

comment:84 @aaemnnosttv3 years ago

  • Cc aaemnnosttv added

comment:85 @082net3 years 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 @andyadams3 years ago

  • Cc aadams@… added

comment:87 @dwenaus3 years ago

  • Cc deryk@… removed

comment:88 @kwight3 years ago

  • Cc kwight@… added

comment:89 @F J Kaiser3 years 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: @husobj3 years 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 @stephenh19883 years 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 @brokentone2 years ago

  • Cc kenton.jacobsen@… added

comment:93 @goto102 years ago

  • Cc dromsey@… added

comment:94 @DuGi_dk2 years ago

  • Cc DuGi_dk added

comment:95 follow-up: @sil.linguist2 years 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 Kaiser2 years 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.gz2 years ago

  • Cc code@… added

comment:98 @mboynes2 years ago

  • Cc mboynes@… added

comment:99 @maxaud23 months ago

  • Cc dustin@… added

comment:100 @ocean9020 months ago

#25902 was marked as a duplicate.

comment:101 @prionkor18 months ago

  • Cc prionkor.business@… added

comment:102 follow-ups: @TweetyThierry17 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 17 months ago by TweetyThierry (previous) (diff)

comment:103 @SergeyBiryukov17 months ago

  • Milestone set to Awaiting Review

comment:104 in reply to: ↑ 102 @helen17 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/

comment:106 in reply to: ↑ 102 @ericlewis14 months ago

  • Keywords has-patch needs-testing 2nd-opinion removed
  • Resolution set to maybelater
  • Status changed from reopened to closed

Replying to TweetyThierry:

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,

Hey TweetyThierry,

as this would be a game-changing ticket, it would require a blessed task team working on it during a cycle. This ticket was closed three years ago; as has been stated elsewhere, trac is a good place for working out implementation, not waiting around for someone to name a brilliant paradigm-shifting API.

If you'd like to be involved (or anyone else) I'd suggest you to join the metadata UI API team's next dev chat, as @juliobox suggests.

comment:107 @SergeyBiryukov14 months ago

  • Milestone Awaiting Review deleted

comment:108 follow-ups: @boonebgorges8 months ago

  • Keywords needs-patch added
  • Milestone set to Future Release
  • Resolution maybelater deleted
  • Status changed from closed to reopened
  • Summary changed from Add metadata support for taxonomies to Add metadata support for taxonomy terms

In 4.1 we've begun to phase out shared taxonomy terms. See #5809, #21950. In a future release of WordPress, we'll have one-to-one correspondence between items in wp_terms and wp_term_taxonomy (and indeed, the two may be merged). See #30261, which blocks this ticket. So I think it's time to reopen and consider what a termmeta API would look like.

A few initial thoughts:

  • Since term_id and term_taxonomy_id will be one-to-one, I think it makes sense to use the public term_id as the "owner" of termmeta. term_taxonomy_id thus becomes deprecated. (It could just as well be the other way around, though then we need a translation layer.)
  • We'll need CRUD wrappers for add_metadata(), update_metadata(), etc.
  • meta_query support for get_terms() and maybe other term-fetching functions.
Last edited 8 months ago by boonebgorges (previous) (diff)

comment:109 in reply to: ↑ 108 @MikeSchinkel8 months ago

Replying to boonebgorges:

  • Since term_id and term_taxonomy_id will be one-to-one, I think it makes sense to use the public term_id as the "owner" of termmeta. term_taxonomy_id thus becomes deprecated. (It could just as well be the other way around, though then we need a translation layer.)

It's a little thing, but I do so hope we'd go with term_id instead of term_taxonomy_id; my fingers object in a passive aggressive manner every time I try to type the latter; they inject typos into that long identifier name. :-)

  • We'll need CRUD wrappers for add_metadata(), update_metadata(), etc.

What's the chance of revisiting the idea of a more generic meta_data table that would allow for other types of metadata in addition to metadata for term/taxonomy? I'm not suggesting we change post, user or comment meta but that we consider term meta being just meta with an object_type field?

Last edited 8 months ago by MikeSchinkel (previous) (diff)

comment:110 in reply to: ↑ 108 @cjaimet2 months ago

Replying to boonebgorges:

I've been waiting for term meta data pretty much since I started WP development. I work with a large news agency and we use home/cat/tag pages extensively and serve several post lists to each with a modular layout defined by editors in the back end.

Right now, I'm using WP Large Options to store the JSON encoded configuration data in custom posts. It works well enough when serving data to an index page, but feels like a hack to me and isn't very queryable.

comment:111 @slackbot2 months ago

This ticket was mentioned in Slack in #core by sergeybiryukov. View the logs.

comment:112 @marsjaninzmarsa2 months ago

I'll be glad if i can see this in 4.4 core, probably after providing feature-plugin for 4.3 (if we can close #30261 before 4.3).

It's very important thing for lot of plugin and theme developers...

comment:113 @slackbot8 weeks ago

This ticket was mentioned in Slack in #core by boone. View the logs.

comment:114 @slackbot7 weeks ago

This ticket was mentioned in Slack in #core by boone. View the logs.

Note: See TracTickets for help on using tickets.