Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This is split off from #674474: Review and update D7 core module handbook pages, part of the docs Sprint: April 2011. Landing page is a stub, first child is too long, so first task is to move general principles from second page to landing page and clean up some.
Comments
Comment #1
jn2 CreditAttribution: jn2 commentedPath to the Taxonomy section is http://drupal.org/handbook/modules/taxonomy.
Comment #2
arianek CreditAttribution: arianek commentedchanging tag to may sprint, don't want to add new work into this one. ;)
Comment #3
jn2 CreditAttribution: jn2 commentedUnassigning myself, since this will be part of the May sprint.
Comment #4
iandickson CreditAttribution: iandickson commentedI'm jumping in here with my first commit.
Comment #5
arianek CreditAttribution: arianek commentedgreat, thanks ian!
Comment #6
iandickson CreditAttribution: iandickson commentedTrying to pull the general stuff together - http://drupal.org/node/1160510
Comment #7
arianek CreditAttribution: arianek commentedhi ian - do you mind posting that to this issue and closing the new one as a duplicate? we want to keep it all in one place so people already following can keep up. thanks!
Comment #8
iandickson CreditAttribution: iandickson commentedConfused. Do you mean copy and paste it as a comment here?
Comment #9
arianek CreditAttribution: arianek commentedyep!
Comment #10
iandickson CreditAttribution: iandickson commentedSomething for people to work with...
These pages are designed to replace:-
About Taxonomy
Guidelines for Taxonomy Design
Understanding Taxonomies for New Users
Using Vocabularies for Navigation (the original page should be kept but highlighted D6 only). In D7 it's part of page 5.
Vocabularies and Terms (and it's subpages)
Layout should be (for brand new people starting from scratch).
Page 1
2
3
4
5
Adding a Vocabulary (and it's Terms) to your site - D7
PAGE 1
Taxonomy - Introduction Part 1 - Overview and Terminology
Introduction - for people new to taxonomy concepts. Understanding the basics will make the Drupal specific help much easier to understand.
Taxonomy is a way of classifying content to enhance the structure, display and searchability of web sites.
E.g.
Terminology
Taxonomies can be hierachical. Such as :-
Vocabularly = Music
In this case Concerto has Classical as a Parent Term, and New Orleans has Trad as it's Parent.
In many cases there is no one right way to design your taxonomy. For example instead of being one Vocabulary Music could have a Vocabulary for each major genre - e.g. Classical, Jazz etc.
The two types of Taxonomy can be combined - for example a site about local music might have a Controlled Taxonomy for Venue, but allow free tagging for Band Name. In this case it ensures that all gigs at the Frog and Fiddle have the same tag and that none are tagged "Frog & Fiddle", or indeed "Fog and Fiddel" in error. (Bad tags mean invisible content).
PAGE 2
Taxonomy Introduction Part 2 - Plain Text, Tags, Vocabularies and Other Modules
The three main taxonomy options are :-
Plain Text
Not a taxonomy but dodging the issue.
It works when the databases are vast, and there is multiple duplicate content covering the same areas in different ways. Thus any sensible search term brings results, as text searching allows people to find what they need, i.e. it doesn't matter if they call it football or soccer, they'll find the fixture list because both versions are out there.
Example - the web, as displayed by Google.
But this approach doesn't work on sites with limited content, and certainly doesn't let you deliver results in any kind of intelligent fashion. We have all been on websites where obvious seach terms produce rubbish results.
You are using Drupal. There is no excuse for not providing a decent taxonomy!
Tags (Drupal 7 Default)
The simplest taxonomy is TAGS - a simple list of terms that describe or categorise content. Hence video and photo tagging. This approach can work very well and might be all that you need.
Drupal's default assumes a simple TAGS list for content.
Example - A cookery site might simply ask you to put "main ingredients" in the tags list, knowing that anyone seeking "chicken in red wine" will simply search for "chicken + wine".
However many sites need a more structured taxonomy in order to deliver a better experience for their users.
Vocabularies
Use for sites where it is important to group terms together in order to extract / build meaningful relationships between users and content.
Example - Dating Site
User wants to enter a mixture of their details and those they seek in a partner.
So Vocabularies might be :-
It's easy to see that even though the words are duplicated, their meanings, once embedded in terms and the effect of combining terms, are not. Take the word Male. Imagine that the site used a simple TAGS system. Putting Male into that list would be meaningless unless they also added a term for their sexuality - but what would they put? Bi? Bisexual? Gay?
But a Multiple Vocabulary system allows simple choices to IMPLY other information. So My Sex Male, Partner Sex Any implies a Bi Guy.
Likewise the fact that cities duplicate in My Home Town and Will Travel To is a feature, because it allows the system to top list results where the womans Home Town is the same as his, followed by those where her Home Town is on his Will Travel To list.
Other Modules
The practical power of a well design taxonomy really comes to the fore when combined with Modules that make use of it.
If you are new to Drupal, create dummy taxonomies and nodes and then add Modules to explore their effect.
Views is worth looking at in this regard.
PAGE 3
Taxonomy Design - general notes
Taxonomy design can be a very iterative process.
Most people tend to start at an extreme - either "I really just want Tags" or "wow, by using 15 vocabularies I can get uber control".
It's Lumpers vs Splitters, a debate as old as taxonomy itself.
Lumpers - your default tendancy ensures simplicity of data entry ( a good thing) but can make it hard to design sophisticated display of content later. (Ever tried to find "pics of me, with joe, on mountains" in FaceBook?)
Splitters - you will tend to design systems capable of incredibily controlled display, but at the cost of requiring posters to work through a complex data entry process, (leading to skipped areas and data gaps).
Experiment - your aim is create the most simple taxonomy commensurate with the needs of your users to find content.
Practical matters - esp re larger projects for clients
Clients are not experts on taxonomy, not even their own
Taxonomy is a communications issue and if there is a budget for the site it's always worth running it past an outsider - but note that they will need to get to understand the purpose of the site and also to an extent the jargon of the subject.
Audience is important - a health site for doctors would probably require a taxonomy written in latinate language - no heart attacks, just myocardial infarctions - but one for the public would use common language.
To an extent, if the audience is non technical, and you are not technical in the field, then you can be the reality check - if it doesn't work for you, it doesn't work. If you do have technical skills in the area, try and run it by some laypeople.
If it's a technical audience and you are not technical, then you should probably do some reading, and again, try and get someone else technical to review, pref from outside the organisation, but certainly from outside the organisations development team.
PAGE 4
Designing your Drupal Taxonomy
This page is an overview to help you design your Taxonomy. It assumes you are familar with the general concepts. See Intro pages if not.
For Step by Step "How To" see Adding a Vocabulary (and it's Terms)
Consider what information you need , both for users and for modules such as Views.
This will determine the Vocabularies you need, and also their nature, for "normal" contributors:-
The "normal" users condition applies because whether or not a Vocabulary is Free or Controlled is actually a setting for the Content Type. So it is possible, on sites with multiple content types and roles to have a case where Admin create Reference Pages, and Users create Articles. Both use the Sections vocabulary, but for Reference Pages it's Free Tagging, and in Articles it's Controlled - tick the boxes that apply.
Are you au fait with Contextual and Relationships in Views?
If NOT, then you should try and use Controlled Vocabularies for anything you want available as a Filter for your Views, esp if it will not be exposed. (This is because you'll need to know the Term when building the View, and you can't know the term, in advance, of a Free Tagging Vocabulary).
Lots of Terms or Few?
Do you want to display the terms for User Selection in Checkbox or Dropdown?
If so, be aware of screen space limits and how that impacts on usability.
The main exception to the 100 rule is with "commonly used long lists" such as "Country" or "Major Cities" , lists where users can be expected to scroll directly to the right entry.
The most thought must be given to a large vocabulary where you can't trust users to use Autocomplete without error, and where errors could have important real world consequences.
For example "Medicines". It's all too easy to imagine a typo in Autocompete leading to the display of the wrong node in the wrong View and then someone dying from the wrong drug.
Large vocabularies need to be broken down. Usually there will be obvious major groups - in the case of medicines, the chemical group, but if there isn't, a per letter vocabluary - i.e. A to Z, is a good approach.
PAGE 5
Taxonomy Module
Principles that Apply to Drupal's Taxonomy Module
Using the Taxonomy Module
In Drupal 7, the Taxonomy module is turned on, by default. In earlier versions of Drupal, you can enable the Taxonomy module on the modules page (Administer > Site building > Modules).
Setting up Taxonomy
Using categories in menus
This is by way of simple example. In practice you will almost certainly be using accessing taxonomy for navigation and display by using other modules designed for the task.
The menus on your site can call for items that match specific taxonomy terms. To create a menu using Taxonomy, follow these steps:
If you are using a hierarchical taxonomy, and want all nodes tagged with child terms to show up also, you can create an URL link like taxonomy/term/2/2 where the second parameter is the depth that the tree will be recursed into, or taxonomy/term/2/all for all child terms.
Comment #11
arianek CreditAttribution: arianek commentedtags
Comment #12
sallybaker CreditAttribution: sallybaker commentedDowngrading priority as this is for previous version of Drupal. It also does not qualify under the Critical definition provided on the Priority levels of issues page: https://www.drupal.org/core/issue-priority
Comment #13
apaderno