7: Taxonomy

Taxonomy is the word Drupal uses to talk about categorizing. The tags used on articles in a standard Drupal installation are an example of how Drupal's taxonomy system can be used.

Categories of similar things, such as section tags on articles, are collected into vocabularies. A vocabulary called cities might contain Miami and Mumbai, while a vocabulary called news sections might contain sports, science and politics. In a standard installation, the article tags are collected in a vocabulary simply called tags. Drupal refers to each individual thing in a vocabulary as a term.

It may take a little while before you use these words without getting confused, but it helps knowing them when reading or talking about Drupal. Here is a quick summary for your phrase book:

• Taxonomy is the framework for categorizing—the practice of classifying things.
• A vocabulary is a set of categories, used to separate different kinds of categories. An example vocabulary could be cities.
• Terms are the actual category words, such as Miami or Mumbai. Each term belongs to exactly one vocabulary.

TIP: You will often see the phrase taxonomy term, used to make clear that we're dealing with terms in the Drupal sense, not terms in general. Sometimes the word taxonomy is used as a synonym to vocabulary, which is correct in a more general sense but not the way Drupal uses these words.

The initial version of this section of the Community Documentation came from the book Drupal 7: The Essentials, courtesy of NodeOne and Johan Falk.

Using the taxonomy system

In a standard Drupal installation, it is possible to use Drupal's taxonomy tools to categorize content. You can add tags (terms) to an article. These terms are usually displayed as links, leading to a list of all nodes marked with the same term. (See figure 7.1.)

Figure 7.1: Each taxonomy term has a list page displaying teasers of all nodes marked with the same term. Here is a list of all content marked with the tag alpha.

These lists – term lists – have some similarities to the front page list in a standard Drupal installation: Nodes are displayed as teasers, and the option sticky at top of lists make nodes appear on top of the list. Just as with the front page, there is also an RSS feed for each term list. In contrast to the front page, though, each term list has a title and if the term has a description it will also be displayed.

Users with access to edit terms will see tabs at the term lists – one to view the list and one to edit the term.

TIP: The internal path for taxonomy terms is taxonomy/term/TID, where TID is the unique ID for the term. By appending /all to the path, the term list will include nodes marked with any sub terms to the viewed term.

Taxonomy and fields

Terms are added to nodes and other entities using term reference fields. The settings for term reference fields include an option to set which vocabulary should be used. There is also a special widget called the autocomplete term widget (tagging). This widget makes Drupal display suggestions matching what the user types. It also allows the user to add new terms if the typed text doesn't match any existing term in the relevant vocabulary.

Creating and managing vocabularies and terms

Under the toolbar option Structure, Taxonomy is a list of all the vocabularies on your website. In a standard Drupal installation you will only see tags. (See figure 7.2) Each vocabulary is presented along with some management links for editing the vocabulary settings, listing existing terms, and adding new terms.

Figure 7.2: The administration page for taxonomy has links to manage each vocabulary, and create new ones.

The list of taxonomy terms allows you as administrator to reorder the terms, which includes creating tree structures. It is also possible to edit each term (See figure 7.3) The form for adding or editing terms holds information about the term name, any URL alias for the term, and also a term description. (See figure 7.4) The term description is actually an entity field, and it is possible to add more fields to terms. The edit page also allows you to set any parent terms, but this is easier to manage in the drag-and-drop list of terms.

Figure 7.3: Each vocabulary has a list of all its terms. Terms can be sorted into a tree structure.

Figure 7.4: Each term may be edited. You can change the fields available on terms, for example adding images to terms.

TIP: It is possible to select more than one parent term on the term edit page. This allows for interesting relations between terms, but makes it impossible to use the click-and-drag list for managing the list of terms. If you set more than one parent term, the click-and-drag list is disabled.

Above the list of vocabularies you will find a link add vocabulary, leading to a form used for (you guessed it) adding new vocabularies. Each vocabulary has a name and, optionally, a description. Drupal will automatically suggest a machine name for the vocabulary, based on its plain-text name.

Fields on taxonomy terms

Just as with node types, comments and user accounts, you can add entity fields to taxonomy terms. The fields are set on a per-vocabulary basis, and the field settings are available from the edit page for the vocabulary and the tab manage fields.

Elaboration: taxonomy terms, text fields or nodes?

In basically all medium-complex Drupal sites you will face one or two decisions relating to taxonomy:

1. Should a particular field (for example section) be a text list field, or should I use taxonomy terms? Both could give me a selection list for sections when creating content.
2. Should a certain type of data (such as product types) be a node type, or should they be taxonomy terms? Both are fieldable and may contain whatever information I need.

Deciding these questions usually requires both good knowledge of the website and its data, and experience of managing data with Drupal. Sometimes it has little or no consequence what you choose, but an incorrect choice could lead to a lot of extra work later on.

Here are some tips for approaching these kinds of decisions.

• What is good or bad is, at the end of the day, determined by what works and what doesn't work.
• That taxonomy terms give you automated lists of content is not a reason to choose terms over text fields or nodes. The Views module allows you to build similar lists based on text fields or other data. (See Chapters 8-10 for more information about Views.)
• When deciding between text fields and taxonomy terms, determine if the information is a necessary part of the node/entity. If so, text fields are usually the better choice. If you're dealing with meta information, on the other hand, taxonomy terms are usually the better choice.
• When deciding between text fields and taxonomy terms, be aware that taxonomy terms may be edited and even deleted independently of the node/entity. The term information is separate from the node/entity.
• When deciding between node types and taxonomy determine if you need any of the functionality available only to nodes, such as publish states, revisioning, access control, authors, and so on.
• When deciding between node types and taxonomy terms – will the data only be used to describe other content on the site? If so, taxonomy terms could be the better choice. If it makes sense to look at the data in itself, nodes are probably better.

Example implementations of taxonomy

This section contains examples of how the concepts and functionalities in this chapter may be used. You can find more examples in the exercises.

Using categories in parallel

As the editor on my recipe site I want to be able to categorize recipes as either starters, main courses, desserts or other. I also want to be able to categorize recipes according to dietary preferences such as gluten-free, lactose-free and vegetarian. This helps the site visitors find recipes they are interested in.

The functionality above can be achieved with the following steps:

• A new vocabulary with the name type of course, where the terms starter, main course, dessert and other are added manually.
• A new vocabulary with the name dietary preferences, where the terms free of gluten, free of lactose and vegetarian are added manually.
• The node type for recipes (assumed to exist already) gets a new term reference field, referring to the type of course vocabulary. The field is set as required, accepts one single value, and uses the select list widget.
• The node type gets another term reference field, referring to the vocabulary dietary preferences. The field is not required, accepts an unlimited number of values, and uses the check boxes/radio buttons widget.

Faculties and departments

As editor on the university information site I want to be able to mark a piece of news as relevant to only selected departments. I also want to mark entire faculties to denote that all departments on that faculty are affected. This is important since it lowers the amount of irrelevant information the university staff have to read.

The functionality above can be achieved by the following steps:

• Add a new vocabulary with the name administration unit.
• Each faculty at the university is entered as terms in the vocabulary.
• Each department on the university is entered as terms in the vocabulary, and sorted as child terms of their respective faculty. (In case a department belongs to more than one faculty, this has to be done on the term edit page – not the drag-and-drop list of terms.)
• The node type for news (assumed to already exist) gets a new term reference field, referring to the administration unit vocabulary. The field is set up to allow unlimited number of values, and will probably use the select list widget.

TIP: Note that both cases described above strictly speaking aren't user stories, for two reasons.
One: The new functions are described from the editor's point of view, but the functionality should be useful for the site visitors.
Two: There is no actual use case described in the cases, only descriptions of how data should be stored. User stories like these should be avoided in real projects, since they border on technical specifications rather than value added to the website.

Exercises: documentation site

These exercises build on previous exercises in the documentation site suite. They can be carried out individually, with some preparation, or in sequence with the previous exercises. The exercises require using the concepts described in this and the previous chapter, as well as concepts covered in part A of this book.

Topic tags

As a site member I want to be able to freely add chosen topics as tags to documentation pages and collections. This is important since it allows me to create another level of structure to the on-line documentation, making it easier to browse and search.

Figure 7.5: An example of how topic tags may be utilized on the documentation site.

How to demo

1. Log in to the site.
2. Edit an existing documentation page and add one or several topic tags. Verify that you can add new topics.
3. Add a documentation collection and add topics to it. Make sure you reuse at least one of the topics from the documentation page.
4. Verify that topics appear as links when viewing documentation pages and collections. Also verify that the links lead to lists of all content tagged with the selected topic.

Preparation

• The site should have documentation pages and collections, as described in the first exercises in this suite.

Suggested solution

1. Go to the taxonomy overview page and add a new vocabulary called topic. Give it a description before saving. (See creating and managing vocabularies and terms.)
2. Go to the field overview for documentation pages and add a new field of the type term reference, using the autocomplete widget. (See taxonomy and fields.)
3. Give the field a label topics, and let it refer to the topic vocabulary. Enter a help text and allow the user to add an unlimited number of terms to the field. (See adding new fields.)
4. Add a similar field to the documentation collection node type.

Comments

• In this user story it would work fine to reuse the taxonomy reference field for documentation pages in collections as well. But if in the future the client would like documentation pages to have exactly one topic, and collections to have several, you would have to break up a shared field into two separate fields. This could result in a lot of user-entered data being lost. It is better to use two separate but identically configured fields.
• Whenever using the autocomplete field, it is a good habit to let the help text inform users that terms are separated by commas – not spaces.
• It is not completely obvious that we should use taxonomy terms for topics. We could use simple text fields, or node references or topics as nodes. Since everything we know about the topics field tells us that it is metadata, taxonomy terms is a good choice. As a bonus, we get the listings wanted in this user story.

Exercises: News site

These exercises build on previous exercises in the news site suite. They can be carried out individually, with some preparation, or in sequence with the previous exercises. The exercises require using the concepts described in this and the previous chapter, as well as concepts covered in part A of this book.

(See subsequent pages for the actual exercises.)

Sections and sub sections

As a writer I want to categorize my articles according to news sections and sub sections. The main sections should be world (sub sections Asia, Europe, Middle East, Africa, Americas and U.S.) and science (sub sections environment and space & cosmos). This is important since it helps site visitors to find news stories they are interested in.

How to demo

1. Log in to the site as writer.
2. Create a news article. Verify that you get a select list of all sections of the site, with sub sections sorted by their main sections.
3. Verify that you cannot save the news article without selecting a section, and that you can only select a single section.
4. In the saved article, verify that the section appears as a link to all articles in that section.

Preparation

• The site should have a news article content type, as provided by the first exercise in this suite.

Section editors

As a site builder, I would like to mark user accounts belonging to section editors with the section for which they are editors. This is important since it allows me to re-use this information in upcoming development tasks, connecting section editors with sections.

Note that this is not a proper user story, since it does not add any value to end users of the site.

How to demo

1. Log in to the site as administrator.
2. Edit a user account. Verify that you can select a section for the account (the same sections as in previous exercise), but that you can also leave the section selection empty.

Preparation

• The site should have a section vocabulary set up, as described in the previous exercise.