Term meta has been committed to core in changeset 34529. This is a hugely anticipated change, and will excited a whole lot of developers. I’ve covered term meta a good bit the last several weeks, so I’ll spare the justifications. Instead, I’m sharing the commit message! It actually does a great job on telling us exactly what is happening:
Introduce metadata for taxonomy terms.
Introduce metadata for taxonomy terms.
Adds a new table to the database schema (
wp_termmeta
), and a set of*_term_meta()
API functions.get_terms()
andwp_get_object_terms()
now also support ‘meta_query’ parameters, with syntax identical to other uses ofWP_Meta_Query
.When fetching terms via
get_terms()
orwp_get_object_terms()
, metadata for matched terms is preloaded into the cache by default. Disable this behavior by setting the new$update_term_meta_cache
paramater tofalse
.To maximize performance, within
WP_Query
loops, the termmeta cache is *not* primed by default. Instead, we use a lazy-loading technique: metadata for all terms belonging to posts in the loop is loaded into the cache the first time thatget_term_meta()
is called within the loop.Props boonebgorges, sirzooro. See #10142.
That’s a good commit message :thumbsup:. Check out the code while you are there.
Now that term meta is slated for 4.4, we’ll start to see plugins adopt the core methodology for post meta, and I’m sure various UIs and helper classes for actually managing meta data on terms — maybe the Fields API will be next!
There is more that can be done thanks to the three legged term splitting exercise, but term meta was by far the most in demand, and here you go. And note that the original term meta roadmap was written by Andrew Nacin over two years ago. Big props to Boone Gorges for going full diesel engine on this project.
I hope the software in Boone’s diesel-powered engine is not hacked to bypass backcompat-regression-emissions testing 😉