During a recent meeting focused on the taxonomy roadmap, a number of contributors discussed the possiblility of adding metadata for taxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. 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 A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. implementation (function names, database table schema, etc) and to mount an outreach and documentation project to help affected plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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.
- Term metadata will be stored in a new database table, called
wp_termmeta, for convenience in this proposal).
- The termmeta table name will be stored at
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,
PRIMARY KEY (meta_id),
KEY term_id (term_id),
KEY meta_key (meta_key($max_index_length))
- New API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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:
_prime_post_caches() for how this works for postmeta.
'update_term_meta_cache' argument for functions that fetch multiple 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 for
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!