I’ve recently come to the conclusion that it’s far better to add vocabularies via CCK than it is to use the default Taxonomy setting.

Why? Oh, so many reasons. Here are three:

1. Content display
2. Tokens
3. Views

1. Content Display

Main Drawback of Drupal’s Taxonomy: You can’t separate out a specific vocabulary for special theming. You also can’t choose to display only one vocabulary, and have another be hidden.

The default Drupal implementation of taxonomies are all-or-nothing. If you have several vocabularies assigned to a content type – like, say, a site vocab and an audience vocab, and a free-tagging vocab, then Drupal just treats them as “terms” and prints them all in a block at the bottom of your post (for the programmers in the audience: they’re all lumped into the $node['vocabularies'] variable).

With CCK Content Types in place of the default taxonomy, though, you can set what shows up on the field’s “Display” settings page, and can choose to hide vocabularies there. You can also theme them separately on the theme layer.

2. Tokens

Main Drawback of Drupal’s Taxonomy: You can’t separate out a specific vocabulary for use in tokens.

The default Drupal implementation of taxonomies is also all-or-nothing in tokens. For example: if you’re using Pathauto and want to create “Category” paths, you can only tokenize the term that happens to come first in the first vocabulary assigned to your node. What?!

Using separate CCK fields, on the other hand, lets you choose the vocabulary you want to use – it’s available as a token, and since they are separate, well, there you go.

3. Views

Main Drawback of Drupal’s Taxonomy: Again, mainly by virtue of being separated out, CCK taxonomies allow you to use separate vocabs in views. This allows you to sort much better when displaying fields.

Main Drawbacks of using CCK Fields: Well, this is great for View fields, however it’s not so great for View arguments, because they’re specially written to leverage Drupal’s main site taxonomy… as are a lot of things.

OK, so can we do both?

YES! Views “Arguments” implementation is written to mesh really well with Taxonomies, allowing you to, for example, take the page terms as a default argument into a block (by specifying “Provide Default Argument”) and filtering on them. If you are using CCK Fields, of course, this becomes a problem. Unless…

Workarounds: Always always always select “Save terms to core taxonomy tables” when adding a CCK Taxonomy Field. You have to have the core Drupal Taxonomies set up in advance anyway – CCK Fields can just be used as a better way to leverage them. So make sure you’re still saving all those terms onto your nodes as if they were using core Taxonomy terms. That way you can have the best of both worlds. Really.