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.

  1. Database
    1. Term metadata will be stored in a new database table, called {$wpdb->prefix}termmeta (wp_termmeta, for convenience in this proposal).
    2. The termmeta table name will be stored at $wpdb->termmeta.
    3. 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;
  2. 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).
    1. add_term_meta( $term_id, $meta_key, $meta_value, $unique = false )
    2. delete_term_meta( $term_id, $meta_key, $meta_value = '' )
    3. get_term_meta( $term_id, $meta_key, $single = false )
    4. update_term_meta( $term_id, $meta_key, $meta_value, $prev_value = '' )
    5. update_termmeta_cache( $term_ids )
  3. Other API improvements
    1. 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.
    2. 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.
    3. A new 'meta_query' argument for get_terms() and wp_get_object_terms().

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!

#proposal, #taxonomy