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-taxonomy-terms-on-node-creation-update
  • 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?