drupal cck vs taxonomy

Drupal provides two methods for adding structured data to a node.

The first is the out-of-the-box Taxonomy module. Taxonomy allows you to associate a vocabulary with a content type. When creating or editing the node, you are invited to choose a value for the vocabulary from its associated list of terms. In essence, you are associating a structured field with your node. The name of the field is the name of the vocabulary and the value is the selected term.

The second method is the CCK module. The terminology of CCK is less confusing. Using CCK you define fields and associate these with a content type. When creating or editing the node, you are invited to set values for the associated fields. There are a few obvious differences between Taxonomy and CCK

  1. CCK fields can be created with many different data types (text, integer, image). Taxonomy terms are always text.
  2. The terms in a vocabulary may be arranged into an inheritance hierarchy. There is no such concept with CCK fields.
  3. Taxonomy vocabularies are exposed in the out-of-the-box Drupal advanced search feature. Combined with a hierarchical vocabulary, theoretically this allows for very sophisticated searching across site content.

But, the core functionality is the same - they both allow you to add structured data to a node. So, how do you know which of these methods you should use? After much experimentation, here are some simple rules I've found useful.

  1. Use Taxonomy to classify your content.
    • At first, this decision seemed obvious, because Taxonomy is built into advanced search. However, when I discovered that the advanced search feature does not correctly search your taxonomy hierarchy, I became dubious that there was any point to Taxonomy whatsoever. If you could not perform a hierarchical search, what on earth was the point?
    • Enter the Views module. Even though the out-of-the-box Drupal advanced search feature is not actually fully integrated with Taxonomy, the Views module is. You can easily use the Views module to create a personalized version of advanced search. As long as you set the magic "Option" flag to be the depth with which you want to search your taxonomy, Views-based searches will correctly perform hierarchical searches.
  2. Use Taxonomy to manage permissions
    • Out of the box, Drupal allows you to set different permissions for different content types. E.g. you can allow a particular role to edit only a particular subset of content types.
    • This is nice, but can get a little clunky. Suppose you are a news site, and you want to define a content type called "News Article". Suppose you have defined a vocabulary called Region with terms south-west, north-west, mid-west, south-east and north-east and that you have a different reporter assigned to each region and you only want to allow the north-west report to edit north-west articles, etc.
    • One option is to make a bunch of different Content Types, one for each region. The other option is to install the Taxonomy Access Permissions module. This allows you to set permissions using the Region vocabulary.
  3. Use CCK fields for everything else
    • In the end, CCK is more flexible, so for most other structured data needs, it should be just the ticket!

Taxonomy was my friend for

Taxonomy was my friend for the last 2 months but now it's my enemy.

I've spent 2 months building a website. I have all my cck content typse related to a single taxonomy vocal. Everything was great. The website was ready to go live.

Then the client decides to tell me yesterday that they need fields to be added per taxonomy term. So basically when they add a term, they want to also add content to go with this term (drupal core only supplies a term description, and that doesn't even have input format for e.g. adding html/wysiwyg). And most of it needs html, so require a wysiwyg. But wait, isn't this where I would need cck NOT taxonomy. Oh No...Big ohh no..noooooooooooooooo

Looked into a module called Term Fields, but it's buggy and it doesn't support setting an input format for a term field that you would add. Meaning no wysiwyg!

So now I am "forced" to redo the entire site (whereever I am using the taxonomy terms) by adding a cck content type to replace the taxonomy term. Can you image changing all the admin views, main website views, all the ajax calls, custom module, sql queries :(

This is changing my opinion about Taxonomy. I now believe that the entire taxonomy concept is wrong. I'm starting to think that taxonomy should be scrapped all together, instead add those taxonomy properties/featured to cck. Even the name "taxonomy" is confusing. It should at least be called "Category". So why not have taxonomy as a 'feature' that you can set for a cck field. Then you would tell it to behave as a "Category" or not...

So in a nutshell, make sure you have full specs and use cases for the project you are working on BEFORE you decide to use taxonomy.

very helpfull, thanks

very helpfull, thanks

Thanks for this post. I'm

Thanks for this post. I'm relatively new to Drupal, and I am having problems with a hierarchical search. IE - If you search with a parent term (Oak), it does not return nodes related to the parent's child terms (Red Oak, White Oak, Sessile Oak). I assumed this would be the default behavior. I'll try Views now to solve this problem. I haven't seen any others in the Drupal community talking about this - is there a plan to fix this?

There's another important

There's another important factor we should mention: translating CCK fields is problematic.

http://drupal.org/node/182881
http://drupal.org/node/182884#comment-280925
http://drupal.org/node/293297

It seems like translating taxonomy has better support. I'm no expert though, so confirmation on this from someone would be helpful.

Also, on a node related to certain taxonomy terms, the terms appear one after another inline. This is a problem for theming. So here's some code you can put in your template.php that separates them based on their vocabulary:

http://11heavens.com/putting-some-order-in-your-terms

CCK fields on the other hand appear separate from each other so you can theme easily.

I agree with the comment

I agree with the comment (above) that is is not necessarily a VS comparison, but rather a discussion on where either approach is best suited relative to the other for the areas where their abilities overlap.
CCK may be the new kid on the block and I do use it a great deal, but I still find situations where CCK would be an overkill or Taxonomy is the best tool.

For instance, you are creating different content with the same structure, it may be redundant to create different CCK types just as a foundation for output (querying/VIEWS/Search). In such situations, I find it idea to create one CCK and use Taxonomy to differentiate between the sub-types. Granted you could create a field and use it to differentiate the sub-types, but that is tantamount to attempting to rebuild taxonomy within CCK.

Another common advantage of CCK is the fact that you can easily move a node from one taxonomy term to another after creation while it is a development job to nicely move a node from one CCK-type to another and match the fields, data types etc

I think it's not taxonomy vs

I think it's not taxonomy vs cck, it's taxonomy+cck. You may need both on your site :)

Nice information explaining

Nice information explaining difference between taxonomy and cCK. I got some idea after reading your blog.

Thanks. As a new Drupal

Thanks. As a new Drupal user, I've been trying to decide when to use taxonomy vs cck fields. This provides some helpful guidance.

post new comment

the content of this field is kept private and will not be shown publicly.
  • web page addresses and e-mail addresses turn into links automatically.
  • allowed html tags: <h2> <h3> <h4> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • lines and paragraphs break automatically.
  • you may post code using <code>...</code> (generic) or <?php ... ?> (highlighted php) tags.

more information about formatting options

captcha
are you human? we hope so.
copy the characters (respecting upper/lower case) from the image.