Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Saving extra fields that were added to a taxonomy. I want the most proper & efficient way of doing so. Where should I save the new fields?

2 possible solutions are to

1) Use the Wordpress options table as described here... Add Custom Fields to Custom Taxonomies. This is admittedly "not clean" and assumed not to be the correct answer.

// A callback function to save our extra taxonomy field(s)
function save_taxonomy_custom_fields( $term_id ) {
if ( isset( $_POST['term_meta'] ) ) {
    $t_id = $term_id;
    $term_meta = get_option( "taxonomy_term_$t_id" );
    $cat_keys = array_keys( $_POST['term_meta'] );
        foreach ( $cat_keys as $key ){
        if ( isset( $_POST['term_meta'][$key] ) ){
            $term_meta[$key] = $_POST['term_meta'][$key];
        }
    }
    //save the option array
    update_option( "taxonomy_term_$t_id", $term_meta );
}
}

2) Add a new table as described here Custom Taxonomies in Wordpress which follows the naming convention of 'wp_' + customtaxonomykey + 'meta'.

3) Some other option

share|improve this question

migrated from stackoverflow.com Jun 28 '12 at 1:51

This question came from our site for professional and enthusiast programmers.

3 Answers 3

up vote 3 down vote accepted

Option 2 is the cleanest method - which I've also used a number of times. Unfortunately, there is no default term_metadata table in WordPress yet. This post also covers the same approach, http://shibashake.com/wordpress-theme/add-term-or-taxonomy-meta-data

And of course, there's a plugin for that too :) http://wordpress.org/extend/plugins/taxonomy-metadata/

share|improve this answer
    
Great tutorial link. So easy! Thank you. (of course I wanted to roll my own as plug ins are too easy of a solution!) –  Christopher Ickes Jun 28 '12 at 15:38

The best answer is (3) Some other option.

This is a little unconventional, but it scales the best, leverages core the most, and doesn't require adding a database table: Add a hidden post type for the taxonomy. Each term in the taxonomy gets its own post in the post type. With that in place, the term meta can be stored as post meta. Here's an example of using this approach.

The main issues with any other approach (including the "use the term's description field to hold serialized data" option) are scalability, performance, and compatibility.

share|improve this answer
    
Well remembered, I'll change my numbering. –  brasofilo Oct 21 '13 at 21:21
    
Not just with a custom post type hidden. If a term happens to be associated with a single post, a post or page type. Then the term meta can store that posts ID and we can create a lot of custom fields for that post that exist to have a relationship with a term in our custom taxonomy. Whatever your approach. I highly recommend creating some protection from the deletion of custom terms if they hold so much meta and are linked to posts. I'm doing that in WP e-Customers now because deleting a term could create havok if the meta for the term is needed and in use. –  WebTechGlobal Feb 2 at 23:33

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

paco pepe
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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.