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.

The judicious use of taxonomies can be a powerful component of any content strategy that is intended to grow and change. 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.

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. Here are some sensible guidelines:

If you want the client to be able to add, change, or remove the allowed values of the field in question, then taxonomy is definitely the right choice. Even if you will likely never alter the list, 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. 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. 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. For instance, to begin populating a newly-created vocabulary with the names of, say, various colors, the single operation would require no more effort than pasting the list of names into a text area, one per line.

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.

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

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. The import process contains six steps; hierarchy is indicated using commas:

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.

The final result is, as intended, hierarchical.

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 downstream, 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 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.

Image:"misc. felis" by nauright is licensed under CC BY-SA 2.0