Website Adaptability, One Tag at a Time

By Michael Ross

A shorter version of this article was published in the print magazine Drupal Watchdog, Volume 5 Issue 1, Spring/Summer 2015, on pages 32-33, by Tag1 Publishing. The magazine was distributed at Drupalcon Los Angeles, 2015-05-11. The article was also published on their website.

When comparing the most commonly-used content management frameworks, web developers typically cite Drupal's robust support for taxonomies as one of its leading strengths. This should come as no surprise to anyone with even minimal experience in using taxonomy vocabularies and their terms in designing and building new websites, largely because they provide a proven way to categorize and make findable the content of any website, with relatively little effort.

Specifically, every piece of content can be tagged with zero or more terms defined within an unlimited number of vocabularies, and these tags can be used in myriad ways for grouping and sorting that content. In the case of a taxonomy term reference used by a view of one or more content types, the sort order and filtering can be specified by the developer using the Views interface or within a custom module, or that functionality can be exposed to the end-user, giving her even greater control over what data is displayed.

The judicious use of taxonomies can be a powerful component of any content strategy that is intended to grow and change in the future as a website's owners and users demand new ways to organize the site's content so as to minimize the time and steps required to find specific content. This is true not just for on-page site visitors, but also for people consuming that content in RSS aggregators for whom only some of the content is of interest — for example, everything published in a particular category or during a certain month.

In this examination of some best practices, techniques, and useful contrib modules associated with taxonomies, it is assumed that the reader has a basic understanding of vocabularies and terms.

Select Field Versus Taxonomy

When adding to a content type a new field that will contain a value from a predefined list of possibilities, you have the option of utilizing a field of type "List (text)" (or one of the two numeric variants of "List"), and setting the Allowed values list on the field settings page. Or, you can employ a taxonomy term reference, which, as the name implies, refers to a term in the taxonomy vocabulary specified when creating the field. There are no absolute rules as to which of the two methods are best, but here are some sensible guidelines:

• Perhaps you want the client to be able to add, change, or remove the allowed values of the field in question, without risking the dangers of permitting the client — and having to explain how — to edit that field settings in the content type. Then taxonomy is definitely the right choice. Even if you will likely never alter the list — for example, the names of Canadian provinces — then a select list should work fine as the field type.
• If tag modification is not an issue, then consider whether or not the new field is needed for the content type to make sense, for example, a state or province name in a postal address. In such cases, a list field may be called for. Conversely, if the field simply adds additional information independent of the content's identity, then a term reference would be optimal, as it is more loosely coupled from the other fields in the content type. For instance, an article filed under a "Technology" category is still an article if you were to remove the category association, so taxonomy would be a good fit.
• If database performance is an issue, then a list field would make more sense than a taxonomy term reference, because the latter involves additional table joins.
• Finally, if the field needs to support hierarchies or focused RSS feeds, then you should use a taxonomy field. (A summary of the possible types of hierarchies follows.)

Less Taxing Taxonomies

While the Taxonomy module built into Drupal 7 core makes it possible to build an unlimited number of useful vocabularies, that building process can be quite tedious. Do you have hundreds of country names to enter, and dread the clicking and pasting? Fortunately, there are several contrib modules that can be tremendously helpful in reducing the time and effort required.

As its name suggests, Taxonomy Manager provides far more control than the core module for working with vocabularies, including the addition and deletion of multiple terms in a single step. For instance, to begin populating a newly-created vocabulary with the names of various colors (instead of countries, for brevity's sake here), the single operation would require no more effort than pasting the list of names into a text area, one per line.

Figure 1. Taxonomy Manager adding terms

The terms are then displayed as a list.

Figure 2. Taxonomy Manager terms added

Moreover, the terms can be manipulated by selecting one or more of them and using the UI buttons for moving or deleting them, or performing other actions. Although a move operation requires multiple clicks instead of a single drag-and-drop, multiple selected terms can be moved as a group.

Figure 3. Taxonomy Manager moving terms

Yet even greater power is available when working with hierarchical taxonomies. For such vocabularies, the module displays its terms in a tree format.

Figure 4. Taxonomy Manager terms hierarchy

Taxonomy Manager can export terms as a CSV file, but not import them. For that, consider the aptly-named Taxonomy CSV Import/Export module, which allows an administrator to import or export taxonomy terms in a CSV file or as text pasted from the system clipboard. It also supports internationalization and the Drush utility. You are guided through the import process through six steps. For either import source, hierarchy is indicated using commas, such as:

term 1
,term 1.1
,term 1.2
,,term 1.2.1
,,term 1.2.2
term 2
,term 2.1
,,term 2.1.1
,,term 2.1.2
,term 2.2
term 3

The module does a good job of explaining what steps it has performed, including automatically creating the import vocabulary if no existing vocabulary was specified prior to import.

Figure 5. Taxonomy CSV message

The final result is, as intended, hierarchical.

Figure 6. Taxonomy CSV imported vocabulary

You may benefit from a few lessons learned from my own experience: This module will take any earlier instances in the file of each repeated child term, and move it to the bottom of its list of child terms, when it encounters a later instance. To minimize confusion long after you have set up a website's vocabularies, if you allow the import process to name the new vocabulary, you should later change the machine-readable name to match your vocabulary name. This module handles several vocabulary structures: flat (no parent), tree (single parent), and polyhierarchy (multiple parents). Avoid that last one if you ever wish to be able to reorder terms, and if you wish to retain your sanity.

These are just two of the many taxonomy-related modules that have been contributed by the community as a supplement to the core functionality. Yet they can be effective components in your toolset, as you learn first-hand how the extensive use of taxonomies for organizing, displaying, and managing data can make a website extremely adaptable to future needs. It also can serve as a key component of a durable information architecture for any website.

Copyright © 2015 Michael J. Ross. All rights reserved.