Taxonomy term metadata proposal
During a recent meeting focused on the taxonomy roadmap, a number of contributors discussed the possiblility of adding metadata for taxonomy terms to WordPress #10142. Assuming we decide to build termmeta, a major hurdle will be compatibility with the many plugins – both publicly available and privately developed – that already implement their own version of termmeta. We plan to do an in-depth scan of all public plugins that conflict with the core implementation (function names, database table schema, etc) and to mount an outreach and documentation project to help affected plugin developers move to the core system. Our goal is zero fatal errors or lost data on WP installations.
But before moving forward with research of existing plugins, we need a fairly clear sense of what the core implementation would, in fact, look like. These details will serve as the basis for a set of heuristics developers can use to tell whether their plugins will conflict with what goes into core.
Toward that end, below is the outline of a proposed implementation of termmeta.
- Database
- Term metadata will be stored in a new database table, called
{$wpdb->prefix}termmeta
(wp_termmeta
, for convenience in this proposal). - The termmeta table name will be stored at
$wpdb->termmeta
. - The
wp_termmeta
schema will mirror the schema for postmeta and usermeta tables:CREATE TABLE $wpdb->termmeta ( meta_id bigint(20) unsigned NOT NULL auto_increment, term_id bigint(20) unsigned NOT NULL default '0', meta_key varchar(255) default NULL, meta_value longtext, PRIMARY KEY (meta_id), KEY term_id (term_id), KEY meta_key (meta_key($max_index_length)) ) $charset_collate;
- Term metadata will be stored in a new database table, called
- New API functions
New API functions will closely mirror those for postmeta and usermeta. They will primarily be wrappers for the_metadata()
family of functions. We may also build in some fault tolerance for when$term_id
does not identify a unique term (ie, because shared terms have not yet been split by the 4.3 upgrade routine).add_term_meta( $term_id, $meta_key, $meta_value, $unique = false )
delete_term_meta( $term_id, $meta_key, $meta_value = '' )
get_term_meta( $term_id, $meta_key, $single = false )
update_term_meta( $term_id, $meta_key, $meta_value, $prev_value = '' )
update_termmeta_cache( $term_ids )
- Other API improvements
- Termmeta cache priming for term-fetching functions:
get_term()
,get_term_by()
,get_terms()
,wp_get_object_terms()
. See_prime_post_caches()
for how this works for postmeta. - A
'update_term_meta_cache'
argument for functions that fetch multiple terms (get_terms()
,wp_get_object_terms()
) that will allow developers to prevent cache priming described in 3.1 above. As in the case of posts,'update_term_meta_cache'
will default to false. - A new
'meta_query'
argument forget_terms()
andwp_get_object_terms()
.
- Termmeta cache priming for term-fetching functions:
Please note that this is a draft. Details are subject to revision based on feedback from contributors. If you see something missing or amiss in the above, please leave a note below. (Please also note that this doesn’t mean that termmeta is a done deal. Sketching the implementation is part of the evaluation process.) Thanks in advance for your feedback!
John James Jacoby 3:44 pm on September 4, 2015 Permalink | Log in to Reply
I cannot +1 this enough without being blacklisted by Akismet.
Ben Huson 9:14 am on September 8, 2015 Permalink | Log in to Reply
ğŸ‘
marsjaninzmarsa 4:31 pm on September 4, 2015 Permalink | Log in to Reply
Can’t agree more.
Justin Tadlock 8:43 pm on September 4, 2015 Permalink | Log in to Reply
ğŸ‘
Chuck Reynolds 12:23 am on September 9, 2015 Permalink | Log in to Reply
👠agreed
Scott Kingsley Clark 3:46 pm on September 4, 2015 Permalink | Log in to Reply
If we can get traction for Fields API, would love to implement it for Term meta on the term pages! Of course, we’ll also start using it within minutes with Pods because it’s already built internally to handle term meta, it’s just not turned on
majemedia 3:47 pm on September 4, 2015 Permalink | Log in to Reply
I just built a plugin (not public) for a client that utilizes term meta. The guide I followed (mostly) was here: http://shibashake.com/wordpress-theme/add-term-or-taxonomy-meta-data
This utilizes update_metadata but requires wpdb queries to get metadata information.
nathanrice 3:52 pm on September 4, 2015 Permalink | Log in to Reply
In anticipation of this eventually being a thing, we chose (in Genesis) to avoid the custom table bit. Instead we just used a single option table entry (serialized) with key=>value pairs for each term ID.
It’s inefficient and doesn’t scale, so in general, we tell people not to use the term meta features (mostly SEO related) if they have a large site and lots of terms.
But the positive is that the transition would be pretty easy to make for us. Just a simple conversion function that runs on update, and update our helper functions to use the new API in WP. We prefix all our functions, so function name conflicts aren’t an issue for us.
Boone Gorges 4:24 pm on September 4, 2015 Permalink | Log in to Reply
This is excellent. Plugins/themes will, of course, be responsible for migrating their data to the new system. As the time gets closer, we’ll produce some documentation that suggests best practices for doing migrations to the core tables. In the meantime, thanks for using prefixes
marsjaninzmarsa 4:31 pm on September 4, 2015 Permalink | Log in to Reply
My proposal for WordPress update runtime, intended, but not limited to termmeta arrival:
As part of update process, just after turning on maintenance, we can force turn of all plugins not compatible with new version, and after upgrade we can try to turn on all of them, one by one, looking for errors and conflicts, just like we’re doing in time of activation of plugin via panel. That can cause break of features, but can prevent “white screen of death”.
Also, before core update we can check for new versions of this plugins, and if new versions are compatible with new WordPress, we can suggest updating this plugins first.
Crazy/stupid/brilliant?
Dan Cameron 6:13 pm on September 4, 2015 Permalink | Log in to Reply
This is awesomesauce! I’m excited and will try my best to help the progress within the trac ticket.
leemon 6:32 pm on September 4, 2015 Permalink | Log in to Reply
I really hope this goes forward in one way or another. Yesterday I was reading some people arguing against this in a trac ticket and the fact this could be wontfixed or pluginterritoried scared me. [Edited for unnecessary language.]
Tanner Moushey 9:33 pm on September 4, 2015 Permalink | Log in to Reply
Awesome!!! Super excited for this!
Guido Scialfa 3:33 pm on September 5, 2015 Permalink | Log in to Reply
Yeah! I can’t wait for this.
Maidul 4:42 pm on September 6, 2015 Permalink | Log in to Reply
Ah waiting for this flexibility
jadpm 7:18 am on September 7, 2015 Permalink | Log in to Reply
Here at Toolset we are pretty excited to see this landing in Core.
Types clients have been requesting this feature for some time now, but we never wanted to implement a custom solution because the taxonomy roadmap was well defined long ago and we do believe that a solution built in the native way was much better than hacking around a custom API or even using the options table.
We will be following how this unfolds. The proposal described here seems fantastic and consistent
thomask 9:55 am on September 8, 2015 Permalink | Log in to Reply
I was proposing slightly different approach – move terms to posts. It might seem strange at the begining, but if you think about it a little more, then you will see that all terms and posts need the same content and settings. You need name, description, slug, date created, and also other post features would be welcomed – author/owner, shorttext… It would make everything much easier – you will not need to come with extra features, you would not add new tables – instead you will get rid of one table, future multilanguage features would be again easier and what is the most important – it would be possible to do thinks, that are not possible now – all post to post / post to taxonomy / taxonomy to post / taxonomy to taxonomy relations, not only taxonomy to post as now. Typical example – authors for books, or brands to cars. I belive this would be also faster, as it would allow easier caching etc. And also the administration all all the relevant functions and pages would be much easier, you will not have to take care of two duplicating table lists, edit pages, meta boxes etc.
Stephen Harris 2:07 pm on September 16, 2015 Permalink | Log in to Reply
Late to the party, but a massive +1 to this, and it’ll be interesting to see what plug-ins emerge offering a user interface for this. I personally have used term meta (actually, restricted to a particular taxonomy) with a custom table and it sounds like migrating to adopt the proposed schema & API would be fairly painless.
Andrew Nacin 6:02 am on September 17, 2015 Permalink | Log in to Reply
One thing to note about cache priming is perhaps following more how it is implemented for comments, rather than posts — term metadata is not automatically primed unless you explicitly ask for it.
John James Jacoby 9:54 pm on September 17, 2015 Permalink | Log in to Reply
Related to this is #16894 which, no surprise, Boone is all over already. ğŸ‘
eddr 12:20 pm on November 16, 2015 Permalink | Log in to Reply
Hi people
That’s great, but I feel there might be a need for the ability to query meta terms efficiently
If you work heavily with meta fields for posts (or terms) and you want to search them dynamically, this is an inefficient operation in WP, in case you have lots of data
Any plans to handle it?
Boone Gorges 2:11 pm on November 16, 2015 Permalink | Log in to Reply
If you are putting lots of stuff in post (or term) meta, and you find yourself needing to query it in complex ways, it’s a good sign that you should not be using the meta system. Where possible, use taxonomies, which scale much more efficiently.
eddr 3:12 pm on November 16, 2015 Permalink | Log in to Reply
Hi and thanks! Much appreciated!
I know, but:
1. I’m using the ACF plugin which is very useful, and it does it like that
2. Taxonomies are not suitable in this case – many numeric values
Thanks
Boone Gorges 3:59 pm on November 16, 2015 Permalink | Log in to Reply
Yeah, if you need to *sort* by the data in question, taxonomies are not a great choice.
Related ticket: https://core.trac.wordpress.org/ticket/20134
I could swear that there was another ticket proposing a fixed-length index on meta_value, but I can’t find it right now. An index would help with many kinds of queries, though probably not sorts.
I’m glad to consider ways that we can improve the native performance of meta queries, but there’s only so much we can do with `LONGTEXT`. If you need to sort by numerical data at scale, you probably ought to be storing the data in a custom table.
eddr 4:33 pm on November 16, 2015 Permalink
Many thanks Boone!
I thought the maybe the roadmap will include something like that, maybe an additional table or something
Many thanks for your time and thought