Deploying Drupal Taxonomy Terms

Prelude:

A Drupal Taxonomy is a very neat concept. They are handy for categorizing content. Combined with the Autocomplete Term widget, Taxonomies allow content creators to easily find an existing term or create a new term to associate with their content. I use a single taxonomy "Tags" to categorize content on this site. This post is tagged with Drupal and Taxonomy (look below at the "Tags" section).

The stock Drupal 7.x point and click administration interface makes it trivial to use a Taxonomy to categorize content:

  • create the taxonomy (confusingly also referred to in many places as a vocabulary)
  • add a Term Reference field to your desired content type (Article in my case)
  • point the Term Reference field at your desired Vocabulary ("Tags")
  • use
  • rinse and repeat

Taxonomies are useful, simple and should be included with all great features. At first glance they provide categorization of content. But content categorizing is the trivial starting point. Taxonomies are flexible enough that they can be extended to many other concepts. For example, they also provide great support for user definable select lists. Drupal provides static predefined select lists for List fields. But these predefined fixed lists are not suitable for cases where you require user defined lists. An example would be attaching a Risk Rating to a piece of content. Taxonomy to the rescue! You create a taxonomy called risk rating and you provide Very Low, Low, Medium, High and Very High terms. This gets the end user started with a nice set of choices and they can later tailor the list by adding, modifying or deleting terms for the risk rating Taxonomy (vocabulary).

The Real Problem:

In the real world deploying a predefined Taxonomy via code is not easy. As the business example above illustrates It often makes sense to deploy the definition of the Taxonomy along with a set of terms. At first glance many developers would suggest that Features is all you need to deploy a Taxonomy. But in this case Features is not your friend. Features handles definition. But the terms are content. Features does not include content - it ignores the terms. The important Very Low, Low, Medium, High and Very High content are not included. The standard Drupal world likes to separate definition and content (this makes sense, but I want both). Features will allow you to move the Taxonomy, but not it's terms.

How to deploy both the definition of the Taxonomy and a set of useful terms? Simply? Without a lot of extra clutter?

Solutions...

You can start down the rat hole of using UUID Features which depends upon UUID but this approach starts the "simple solution" alarms bells ringing. We are piling yet another set of modules on top of our system. We want simple. Least amount of code, least amount of modules. We also must be able to deploy automatically via code rollout, not manually via error prone Point and Click.

We had prior experience incorporating Features produced code into an automated code deployment. We developed a simple framework that would call the low level code produced by Features. Worked great for content types. But we did not see any simple means to have Features capture the taxonomy terms in code so that we can invoke the code. This prompted the question "What else is out there?".

We discovered Bundle Copy. This module sported a manual export-copy-paste-import model similar to exporting and importing view definitions. We had already used the View export model to capture view definitions in code for automatic deployments. This model was familiar. Warm & fuzzy. It should be easy to leverage Bundle Copy to do what we needed: manually pull up the export interface, copy the generated code and paste it into our custom deployment module. Bob's yur uncle.

Oops. On closer inspection we fell short once again. Definition vs Content. Like Features, Bundle Copy was definition only.

What to do? If only Bundle Copy provided the Taxonomy terms...