Taxonomy roadmap for 4.4 and beyond

In WordPress 4.3, we eliminated shared taxonomy terms once and for all. This means that, by the time WordPress 4.4 is released, just about every WordPress installation will have the same number of rows in the wp_terms and wp_term_taxonomy database tables.

Why does this matter? When terms in different taxonomies could share the same term_id, terms could only be uniquely identified by a ID-taxonomyTaxonomy 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. pair. This is why every nearly function in our taxonomy APIAPI 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. has $term_id and $taxonomy as required arguments. (The decision was made long ago to keep the truly-unique term_taxonomy_id internal for most purposes.) The lack of unique IDs for terms made our API interfaces and internals complicated, and it made it cumbersome to add new features like term metadata.

Now that term IDs are unique, we can begin the projects of unraveling the now-unneeded complications of the taxonomy API and adding new features that take advantage of the simplified data model. In this post, I’ll outline some of these tasks, and point to areas where interested folks can contribute.

API simplification and other work on taxonomy internals

Once each row in the wp_terms table corresponds to a single row in wp_term_taxonomy, there’s no point in having two separate tables (and all the JOINs that two tables require). In 2013, @nacin sketched how this might be done, through a combination of $wpdb tricks and a MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. view. Here, we need someone to write a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., and we also need to start a discussion about graceful failures for situations where there are still shared terms in the DB, as well as MySQL version compatibility (view functionality was phased in over the 5.0 series). The tracking ticketticket Created for both bug reports and feature development on the bug tracker. for simplification of the taxonomy database schema is #30262.

With a single term table, we can begin to rewrite our internal SQL queries to remove costly table joins. This kind of refactoring is probably at least one version (and a hundred unit tests) away. In the meantime, we can begin the process of simplifying the API interfaces. For example, functions that accept term IDs, like get_term() no longer need to require an explicit taxonomy parameter.

Having a unique identifiers for terms means this is also a good time to move toward WP_Term; see #14162. This class can start off being a fairly simple model that takes care of things like basic cache management and data integrity – see WP_Post – but over time, I envision moving business logic to the WP_Term, introducing convenience methods for chaining, and so on.

Term MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.

There’s been lots of clamoring for taxonomy term metadata #10142. Unique term IDs make it viable, since WP’s *_metadata() functions assume object IDs as identifiers.

The technical implementation is not complex. We need wrappers for the CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) functions, ‘meta_query’ support in get_terms(), an update routine to create the database table, metadata pre-caching (‘update_term_meta_cache’) when fetching terms, and maybe a few other small items.

The larger challenge is to build a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. solution that minimizes conflictconflict 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 third-party tools. Developers have wanted termmeta for a long time, so there are many public plugins and private libraries that provide it. Many of them use unprefixed function names like update_term_meta(), and many of them use a database table called wp_termmeta. We should do a survey of publicly available plugins to get a sense of usage statistics and schema compatibility. We’ll need to organize outreach to developers of known plugins, so that they can add off-switches to their tools before termmeta appears in core. And we may decide to borrow code from one or more of the existing GPLGPL GNU General Public License. Also see copyright license.-licensed tools, ideally with the participation of the original author.

Let’s share this journey

Many hands make light work. We need code, but more importantly, we need folks who are nuts about strategy and outreach and backward compatibility.

There’ll be a meeting for all Taxonomy Heroes, on September 3 2015 20:00 UTC, in the #core channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. If you’re interested in helping out with any of these taxonomy projects, drop a comment below or come to the meeting. We’ll get a team or two together, and make a plan for 4.4 and beyond.

#4-4, #roadmaps, #taxonomy