Question – Taxonomy & Categories

Drupalers – how do you mostly use Taxonomy? How do you usually create content categories in your Drupal sites? (pls RT) #d7ux

(Tweeted 14 May 09)

FYI- Just a quick survey to see what people are doing, not a request for Taxonomy tutorials 🙂

38 thoughts on “Question – Taxonomy & Categories”

  1. I’m not really sure how to answer that…

    Varies hugely, to be honest. Sometimes Taxonomy becomes a programmatic trick to group things for automated tasks or something like that – other times I use it in a more “traditional” way (like I am now, organising newspaper articles in to classic nested categories).

    One interesting feature of the Taxonomy module which, to my mind is hugely under-used and not talked about much, is the ability to tag data in different ways for different audiences. I did a small amount of consultancy for NHS Connecting For Health in the UK who are (or were at least thinking about) using Drupal and they had an interesting problem whereby all hospitals and healthcare trusts are run by different teams and have different systems. Consequently they categorise data differently too. This makes Taxonomy in Drupal a really strong contender, because it manages a scenario like this effortlessly! You can give each trust it’s own set of vocabs and let them create their own taxonomy on the same set of nodes as every else is using.

    To answer the “how do you create” bit *literally*, using the UI mainly – though sometimes I’ll write a little module for a client that installs vocabs and terms automatically on install, for ease of deployment. And at Defaqto we wrote a content publishing engine which auto-creates terms in a specified vocab – see this project:

    Such a versatile tool and no real “usual” way of implementing it, I guess. =)

  2. Mostly simple categories for a blog

    It’s a pain to show Categories with post count in a block on blog posts, by the way: have to use another taxonomy module, such as Taxonomy Menu.

    It’s good I can specify pages, where not to show the block, otherwise I’d have to use custom PHP snippets or more modules to control block visibility across content types.

    So term list with amount of nodes in them, in a block on specific content types is what I’d really appreciate.

  3. I think you need to rephrase that question.

    As it stands now the only possible answer is ‘it depends’.


    Enter terms ahead of time or during content creation. Sometimes a little of both.

    Which is really rephrasing ‘it depends’.

    1. I thought asking ‘mostly’ and ‘usually’ might help get around the ‘it depends’ aspect – understand it does depend. Just looking for trends.

      Having said that – when you say you’re entering terms ahead of time, why are you entering terms? what are you going to use them for?

  4. To group and sort content more detailed than just by content type OR to group content of different content types together.

  5. I usually use it for sorting content into different categories, and often use one or more vocabularies for most content types; one for the main section, another for free tagging.

    This is also an easy way to get things sorted into custom views, as I did on

  6. I would just like to say, that I have never used some term options from “Advanced options” fieldset.
    Like synonyms and Related terms. I don’t understand how can I use it later in drupal 🙂

    And also adding multiple terms is a bit nightmare. I know there are some import scripts, but usualy I have a document with terms, in a format like:

    which is easy and quick to manage in txt editor. copy and paste would be great instead of adding a term per page (add term form)

  7. Lately I find myself creating mostly multi-lingual sites, thus multi-lingual taxonomy.

    Usually starting by adding all the terms for the default language via the “taxonomy” section. Then translate everyting via the “translate interface” section. Still trying to figure out how to get pathauto set up in a way it’ll automatically create term aliasses for all different languages instead of just the default one—something I’m doing manually at the moment until I find a better solution.

    Examples of recently created vocabularies:

    * “ingredients” and “taste” for a cocktail site * “location” and “type of building” for a site where people can look for office space

  8. To mesh nodes together regardless of content type. Newsletters, forum posts, and blogs are all searched by one taxonomy term.

    I also use taxonomy to separate nodes. I have defined separate taxonomies for isolated node types that will only pull those node types.

    In brief: for organizing my content.

  9. A lot.

    Three main uses:

    Tags: (both on community sites, and sites where only a couple of people are creating categories and I want them to be able to be able to do it on the fly rather than using the taxonomy interface).

    Anything where I need a hierarchy: (regions etc.) which isn’t an about section/handbook.

    Most things where I need a select list on content input and associated listings based on that: you can do this with CCK, but the storage is less efficient. Although deciding which to use for ‘labels’ is a matter of individual use cases and personal taste most of the time.

    I have several sites with more than one vocabulary. Will use my very first Drupal site as an example (all this was set up before I knew anything about development, so covers the ‘weekend admin with complicated requirements’ usage rather than Drupal developer setting things up for a client):

    Four vocabularies: Tags, authors, regions, (economic) sectors
    Tags are unstructured. Regions, sectors and authors are managed.

    We have four separate sets because we want to be able to list authors, regions and sectors distinctly – which you can’t do with single bucket tags.

    We’ve also moved between free-tagging and structured vocabularies several times over the years due to changes in our editorial process etc. This has also involved splitting and merging vocabularies (or individual terms) when we wanted to change things around (it’s a pain, but doable).

    Since we also have forum module installed, which uses taxonomy for hierarchy and listings – there’s a fifth vocabulary for the forums as well, but that’s managed from the forum administration. At one point we were using forum_access (which limits posting and viewing rights to specific forums, again piggybacking off of the taxonomy system), but ripped it out due to performance issues.

  10. Either we set up a specific amount of terms ahead of time (Taxonomy the gives us the flexibility to add later) or we set it up to free tag content and watch it grow.

    Setting it up ahead of time will typically be used for content aggregation and grouping for primary navigational purposes.

    Free tagging is mostly an uncharted territory for me.

    Synonyms and multiple parent aspects of taxonomy are unused for the 80%.

    The “many to many” aspect of taxonomy is a highly sought-after relationship for data, and currently can’t be answered easily with “node references” without installing something like “node auto term” or similar.

    I struggle with abusing taxonomy as a sort of “glue” for other nodes that can have fields.

    All of the limitations that I’ve spoken of, however, will most likely be taken care of with Drupal 7 where I believe taxonomy will have fields.

  11. I have a few different ways of using taxonomy.module and they usually vary based on the kind of vocabulary (or non-vocabulary) I’m building. I hope this doesn’t get called a tutorial; taxonomy.module is all about building vocabularies. The relationship of terms to nodes is almost secondary.

    I usually need a few vocabularies on my sites. Often one or two will be ones that I’ve had to carefully think about as a major part of the site architecture. I will use taxonomy.module or taxonomy_manager.module to develop these vocabularies in advance of any other node content. These vocabularies really can exist “outside” my site’s content, and they can communicate meaning without having relationships to nodes.

    Other taxonomy.module vocabularies aren’t vocabularies at all. Tag lists aren’t a vocabulary, so I don’t create these in advance. These are always created in the context of content.

    People also use taxonomy.module vocabularies and CCK option fields in similar ways, and it’s a fine determination to say that one usage is “classificatory” and another (like this one) isn’t. This isn’t always a good shortcut though, because taxonomy.module vocabularies always have some costs when it comes to complex Views.

    Then there are standard vocabularies that exist outside my site entirely. The International Classification of Disease, toponym vocabulary, CRS Legislative Subject Terms, etc. are all vocabularies that I don’t need to build myself but I need them in my site right away because I already know that I’ll be using them, but it’s always a new problem to import a new vocabulary to Drupal’s taxonomy.module from a standard shared vocabulary.

  12. Currently I do have 3 Vocabularies in Action on my Drupal-Blog:

    1. “Ressort”, which contains the major Content-Cateogries like “Thinking, Living, Humans, Machines”. It’s a multi-select, must-select Vocab. It contains 6 major Ressorts and about 10 Subressorts.

    2. “Series”, contains about 12 Terms for like “Learing Drupal”, “The Uncapitalism of the web”. It helps me to keep several Articles which belong to a series. Always wanted to make a blog, which contains all Nodes, chronologicalle sorted to a series. This ist also a select Vocab, but obviously not a must-select.

    3. “Lexicon”, which contains about 4500 Terms / Tags, which form a Lexicon of the Content inside my Blog. I try to make sure, just to have Terms in it, which would be worth a Lexcial Article like in Wikipedia. Most of the Terms are People, Institutions, Places, Movies, Books, Songs, Albums, and other Topics. This Vocabulary is a Tagging Vocabulary.
    I don’t use “poetic” or “functional” tags like “cool”, “hot stuff”.

    I used to have multiple Vocabularies, for different sorts of Tags. Like one Vocab for People, one for Pieces of Art, and so on. But it was too confusing.

    I also used to have an own Vocabulary for the journalistc form of an article, like “News”, “Essay”, “Opinion”. But I got rid of that too, because I didn’t really use it.

    All three vocabularies apply to all 6 Node-Types in my Blog.

  13. Besides categorizing content, I sometimes use it to create separate CSS styles for content and to present different Views ( block and page ) based on Taxonomy.

    Like marek, I have never used the free tagging and synonyms, as those things have never been part of any project requirements that I’ve had in the past.

    Taxonomy is quite useful most specially when you want to show the same content types ( for example a content type news – create a News vocabulary and add the terms : Sports, Local, Business, World, etc. ) but want to add a level of separation in terms of design / presentation.

  14. Adding terms in advance:

    Regions – it’s easier to grab a standard list from somewhere and import it than do it by hand – actually adding terms by hand in the admin interface is really, really painful, and I usually do it with tagging then change the vocabulary settings if I’m in a rush with < 40 tags to add.

    For any site which is migrating to Drupal from another CMS with some kind of category system, you’ll usually need to bring in their categories in bulk – there’s modules which allow you to import from .csv and XML etc.

    There’s also other standard taxonomies (biological etc.) which specialised sites are likely to have access to in a structured format and want to import wholesale. The Encyclopedia of Life is doing this with vocabularies of hundreds of thousands (I think up to 2 million) terms. One site does lice, another site does bird, etc.

  15. We use taxonomy primarily for top-level site architecture. It’s then referenced (through synonyms) to select a lot of the section features, such as secondary navigation, section images, etc. that are regular parts of the pages. Beyond the top level, we’ve found it useless.

    In Drupal 5, we’ve had enormous issues with the inconsistencies between Taxonomy and CCK Taxonomy.

    Taxonomy uses a top-down approach, where you choose which content types it should be required for. It does not let you add help text, proper default, select proper labels for the input forms, or other features that would make the admin interface better.

    CCK Taxonomy uses a more natural bottom-up approach, letting you customize the admin interface and set different defaults for various content types. CCK Taxonomy is not referenced by most contrib modules, though.

    Other than that, we haven’t found much difference between taxonomy and using say, a multiple-choice CCK text field.

    There’s a lot that can be done to make taxonomy more useful: more choices for setting up the admin interface and a much better explanation for synonyms.

  16. Our primary use of taxonomy is to relate content together. This means both through modules like Related Content but also through Views based on taxonomy term. By extension, that means to help us build autocompletes on node-edit pages which pick a match out of a view. Related to this, we set up taxonomies to create simple “media libraries” – image galleries, but also a dedicated taxonomy for document nodes, so the client can track media resources more easily.

    We feed these primary taxonomies in a number of ways. One site had an existing vocabulary which we imported (by, er, screen scraping, ugh.) Others, we get definitions from the client. Image galleries and media libraries tend to grow organically, with terms being added during site development to serve the nature of content being uploaded.

    A common secondary use is to define a site structure. This makes up for the deficiencies in core menu/breadcrumb (if you’re not on a menu, you’re not in the site hierarchy) using modules like Menu Trails.

    The site structure taxonomy almost always comes out of the existing Information Architecture work we do to define the hierarchies.

    Finally, we do set up tagging, but different clients use it to wildly varying extents, so I wouldn’t say that was as core for our client base as I think it is for others. Tag vocabularies are invariably organic.

    1. I see a common thread in some of these comments where taxonomy is used as a bit of a hack for, as you say, site structure, and, as someone else said, grouping content types.

      These are interesting uses and seem to reflect deficiencies in menus and in the ways content types can be leveraged.

      1. I don’t see it as necessarily evidence of a deficiency (although using the same system for both registering page callbacks and for your site’s breadcrumbs and left-hand navigation has clearly reached the limit of usefulness). I see it more as a vote of confidence in categorisation.

        Drupal’s categorisation is already flexible and powerful, even though elements such as synonyms are arguably unfairly neglected. Using potentially different vocabularies, but the same engine, all over the place makes perfect sense for me: for content types, site structure, even modules (precisely why are modules categorised using keywords in the .info files?)

        I wouldn’t want to *force* all categorisation into using core taxonomy. What’s important is for their implementation to feel natural for the user. But if that UX can sit on top of a tried and tested system then all the better.

  17. How? In many different ways, depending on how the site’s needs, often in multiple ways.

    Firstly, there’s usually a taxonomy of the overall site architecture – essentially mirroring the main navigation. Often I’ll use that to group content in the main site sections.

    Secondly it’s a way of categorizing and organizing content, sometimes that’s a fixed vocabulary, sometimes freetagged, sometimes both.

    Taxonomy is extremely powerful, and good part of what makes Drupal unique…tread carefully =D

  18. I’ve used taxonomies for “categorizing nodes or content” Sometimes I have used taxonomy for meeting design requirements. There should be little need to categorize content if it’s just presented in one page and doesn’t need sorting because there aren’t too many entries.

    For an e-commerce site that uses Drupal, taxonomy module itself hasn’t been of much help. Categorizing normal content and categorizing products should somehow be different.

    1. “Categorizing normal content and categorizing products should somehow be different.”

      Well, it can be different: create a different taxonomy and assign it to your “product” content types. Product listings, as I see it, are the kind of thing that the current taxonomy implementation actually does rather well.

      It’s when you want to create a site that has a designed IA that taxonomy stops being useful, in my experience.

  19. @Katz for your e-commerce site wouldn’t you just have two separate vocabularies, one for normal content vs one for products? Don’t really see why they should be ‘somehow different’.

  20. 1) simple tags

    2) hierarchical content organization

    3) access control

    4) “tricks” where the objective is something else but you can “fake it” using taxonomy.

  21. [Drupalers – how do you mostly use Taxonomy? ]
    I use to categorize content most of the time. But I also use instead of creating a new content type. I create for example a vocabulary called “page type” and I add terms like, “is_page”, “is_article”, etc.

    [How do you usually create content categories in your Drupal sites? ]
    As many already said through UI or from the code.It depends…

  22. First off, I’d like to express my infinite love for taxonomy. I don’t know if it’s the incredible simplicity both on the API-side as on the backend interface side, or if it is it’s sheer flexibility, but there’s something about it that makes it useful for so many things.

    I often use it in the “classic” way, simply to group stuff together to show them in a hierarchial and easy to scroll ladder like
    – country1
    — area1
    — city1
    — city2
    – country2
    … u get the point

    And taxonomy makes tag clouds a walk in the park.

    But recently, I’ve discover it’s hidden power on the internal side. Even without a hierarchy, it makes grouping nodes together more than easy.

    And since Drupal 6, the multilingual possibilities for taxonomy cover every possible use-case.

    The only downside about Taxonomy is that it can be a lot to grasp right away, but I would say its flexibility and ease (once u grasped the concept) make it more than worth taking a couple hours to figure out exactly how it works and what it can do.

  23. I mostly use free tagging vocabularies so I don’t need to create terms in advance for the purpose of relating content.
    I do also use taxonomy to structure a site into main sections in this case I use a fixed set of terms where one can be selected to organize a piece of content within the site’s structure.
    Since Drupal 6 I prefer using different node types for the latter.

  24. In the beginning i had difficulties in understanding the concept behind taxonomy, not at last because its not called category. But with more experience i did understand, why it is not called category because it can be used in so many different ways. And i learned to use and love the concept behind it.
    Sometimes i just use it to flag content with icons. Doing that requires the taxonomy image module, but works so well!
    Although i never use the free tagging or synonyms, i am glad that i had the option to.
    So i think the use of taxonomy is uncounted, perhaps the basic explanation should receive a little rework.

  25. I mainly use taxonomies to group related content together.

    When (re)designing I look at content that already exists to see if it already falls into separate containers, and I look at
    the objectives of the web site and try to categories how the web site will be used to communicate with the stakeholders.

    I generally use a mind mapping tool, such as freemind, to design the taxonomies – either flat or hierarchical. With freemind, I can tag containers where content already exists. I try to make sense of the taxonomy, (re)moving those containers that “don’t really belong” and after trimming and pruning, I am left with my final taxonomy.

  26. Using taxonomy to define site architecture is a non-starter for the kinds of sites that we build. There’s effectively no useful integration with the menu system, so you can’t use it to place pages on navigation, and the kind of pages you get if you rely on Taxonomy to produce your site IA are just wholly inappropriate for marketing sites. You just don’t have enough control over the presentation, at least not at the “Verity” (or, arguably, even the “Jeremy”) level.

    Right now, I’m only using Taxonomy to make things show up in views. I don’t find it useful for anything else in a corporate setting, because the idea of automatically organizing a site by taxonomy is just simply opaque to most users and is totally inappropriate for a site where you’re trying to communicate a coherent message. (A.k.a. a “marketing” or site.)

    Put another way: Organizing a site by taxonomy in Drupal is not easy. Takes a lot of work. Organizing it by menus is easy. It’s the default. Taxonomy and menus at this point are basically not integrated in any way that’s very useful out of the box.

  27. To follow up on comments by Greg and tdskate, I’m creating vocabularies in advance so that I can present logged-in website users with the content that is most useful to them, based on their stated or assumed interests (stored in their profile).

    This is sometimes happening when profiles are synched with 3rd party CRM profile data.

  28. Categories are used on our website, so that users put their posts (of certain types) into fitting (both!) topic- and geography-based sections themselves. Unlike the approach of putting nodes into menus (which have limitations), node authors may do this themselves, the selection may be required and for more independent hiearchies simultaneously, and we also allow multiple selection as the content fits. That’s the positive side. Negative is, that having a good navigation into these sections (=terms) is virtually impossible. We need something what looks like browsing directories in a filesystem (very natural way for every computer user), so that readers may walk the hiearchy tree from root to the section of interest, without having to use search engine or other funny ways to “break in” to the needed term’s page. Our content is of permanent value, so “latest posts” kind of navigation is often not fitting. Core have no page for a vocabulary, which is a serious gap in the navigation from root even if the whole tree of links was hand-made. (D.O. Issue #185146). After evaluating several Taxonomy based contributed modules, none of which gave the needed functionality, we finally dumped Taxonomy in favor of the Category module. Category, despite all it’s bugs and questionable aspects, offers nearly flawless navigation, plus other improvements, such as fully-blown introduction texts (=node bodies) for categories (node listings). Also having category-based breadcrumb on nodes (without putting all nodes into a menu) is a notorious problem of Drupal.

  29. Three major ways:

    1) To relate content together so that Views (+ Panels) and Faceted Search can generate custom lists
    1b) A major subapplication of this is that we export the data from Location.module to Taxonomy so that it can be used to make maps for a specific city or country (via Gmap Views)
    2) To make custom homepages/landing pages (through assigning a taxonomy term to the posts that should be featured on each)
    3) SEO: freetagging terms on each node are links to actual indexable pages

Comments are closed.