1) Default wp_options
table
I really don't understand why folks propose
update_option( "taxonomy_term_$t_id", $term_meta );
when we can have one single option, whose indexes are the Term ID and the custom fields as values
$options = get_option( 'taxonomy_term_meta' );
$options[$t_id] = $term_meta;
update_option( 'taxonomy_term_meta', $options );
and then simply pull the option and get the value stored for a given Term ID
$options = get_option( 'taxonomy_term_meta' );
echo $options[$tax->term_id];
2) Custom wp_taxonomymeta
table
That's what the plugin Taxonomy Metadata, linked by James, does. And it's quite simple, once this table is created, the functions add_
, get_
, update_
and delete_metadata
will start working with 'taxonomy'
. Like so:
function add_term_meta($term_id, $meta_key, $meta_value, $unique = false) {
return add_metadata('taxonomy', $term_id, $meta_key, $meta_value, $unique);
}
function delete_term_meta($term_id, $meta_key, $meta_value = '') {
return delete_metadata('taxonomy', $term_id, $meta_key, $meta_value);
}
function get_term_meta($term_id, $key, $single = false) {
return get_metadata('taxonomy', $term_id, $key, $single);
}
function update_term_meta($term_id, $meta_key, $meta_value, $prev_value = '') {
return update_metadata('taxonomy', $term_id, $meta_key, $meta_value, $prev_value);
}
3) Helper Post Type
As described in Matthew Boynes answer (I think someone mentions this too in the ticket #10142.
4) Outside the Box
In the plugin code, there's a link to the Core Ticket #10142 discussing all this. It's a 4 years old ticket, (closed)(maybelater)
, lots of developers jumped in, but no conclusion was reached.
By the end of it, we have this nugget (my emphasis):
As I need this regularly, I've wrote my own solution: Misuses 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.
Pretty clever.