The definitive Drupal "Field API Option List vs. Taxonomy" pro & con list

Here I am building out a content type for a new project again. I've got to decide whether to use a Option List field or a Taxonomy field. It's an easy choice right? Right? Once you think far enough down a site roadmap, you'll discover it rarely becomes a simple answer. I've read many articles on the subject and nothing I've found seems to cover all details. That being said, if you find any details or related links I've missed be sure to let me know in the comments.

Taxonomy - Pros

  • Terms can be added/removed/changed at any time.
  • Terms can be added on node edit pages with free-tagging.
  • Terms are full fieldable entities.
  • Each term gets its own themeable path to view all content tagged with the term.
  • Can be organized in a parent-child relationship hierarchy.
  • Can be used with Entity Reference.
  • The same Taxonomy Vocabulary can be used across all Node Content Types and Fields.

Taxonomy - Cons

  • Requires creating vocabularies and terms in the Taxonomy admin, before being added to a Node(or any entity) as Term Reference field.
  • Stored in Term reference field database tables as Term ID (tid)
  • Complicates Views sorting/filtering and Views Table click-sorting by requiring Relationships: https://drupal.org/node/2051485 Otherwise sorting will function by Term ID, which is always extremely confusing when you try to figure out why the sort is working near randomly.
  • Node create/edit via Services API must use Term IDs, instead of easier-use machine names: http://drupal.stackexchange.com/questions/48413/services-3-setting-taxon...
  • Database queries require additional JOIN statements to get data from Taxonomy tables/entites.
  • Each term gets its own themeable path to view all content tagged with the term.
  • Associated HTML classes include Term ID in Forms, but not additional identifying information. Theming becomes more difficult.
  • Complicated to export Terms using Features. The process requires Universally Unique IDentifier and UUID Features Integration. Terms IDs will not stay the same.

Field API Option List (float/integer/text) - Pros

  • Labels & values are added to directly in the Field edit pages.
  • Labels can include many HTML tags: <a> <b> <big> <code> <del> <em> <i> <ins> <pre> <q> <small> <span> <strong> <sub> <sup> <tt> <ol> <ul> <li> <p> <br> <img>
  • Stored in field database tables as the value entered on the Field edit page.
  • Views sorting/filtering and Views click-sorting work as expected without additional Relationships.
  • Node create/edit via Services API can use human and machine readable values.
  • Database queries can load all required values from Field API tables without additional JOIN statements.
  • Associated HTML classes include option value in Forms, making theming straightforward.
  • Features easily exports Option List labels and values.
  • Each Option does not get its own path (A Pro or Con depending on your needs.)
  • Options Lists are not entities (A Pro or Con depending on your needs.)

Field API Option List (float/integer/text) - Cons

  • Labels & values cannot be added/removed/changed once data exists for the field (without manually editing the database.) Often a huge negative!
  • No free tagging.
  • Each Option does not get its own path (A Pro or Con depending on your needs.)
  • Options Lists are not entities (A Pro or Con depending on your needs.)

Both options have many benefits and many negatives. Generally, you'll need to decide per field, not per content type which to use. Now, here is a list of questions and answers that may help you make a decision.

  • Will the list of items be changed after content has been created? Taxonomy
  • Do you need to export the options in features? Option List, but with hassles Taxonomy could be used.
  • Do you need to manage the list of items for multiple content types? Taxonomy, but Option List could be used.
  • Will the items need custom theming on node edit forms? Option List, but Taxonomy could be used.
  • Will you be changing the data often via DB queries? Option List, but Taxonomy could be used.
  • Do you want a unique identifier that's automatically consistent across your site? Taxonomy.
  • Got any more question/answers?

Comments

Great article, thanks! You mention as one of the cons on the 'Field API Option List' is that 'Labels & Values' can't be added/removed/changed once data exists. This is not completely accurate, you CAN add new items.

Hi Brad, great and useful article.

Just to keep it up-to-date:

"Labels & values cannot be added/removed/changed once data exists for the field (without manually editing the database.) Often a huge negative!"

Labels and values can now be modified, added, deleted, directly in the field settings.

Regards

I'm wondering, if there are differences considering translation. In former times (Drupal 6.x), there wasn't full support for translating fields (CCK). Actually it's possible to translate taxonomy terms and fields. Both can be done by using the same translation interface. So perhaps is there anyone who can tell me, if there is a difference between both? I guess it doesn't matter to use taxonomy terms or fields considering translation issues.

Add new comment