RIP Taxonomy Module in Drupal 7
I have come to the conclusion that the Taxonomy Module is not necessary in Drupal 7 for the vast majority of situations. While there is a lot of built-in functionality and a pre-built view for Taxonomy, the module makes too many assumptions about the way content categorization should function. And overriding the pre-built view for taxonomy terms is never as straightforward as I would like. The last few Drupal 7 sites we have built I have not used Taxonomy at all.
Fixed List Categorization
The most common scenario when taxonomy is used is for a fixed list of terms to select from when a node is created. There are two ways I would go about this without using taxonomies.
- If the list of terms are unlikely to change or the end-user/client doesn’t need to add terms, a simple select list field works great (for example, categorizing by state). The caveat is that the individual terms don’t need their own nodes.
- If the terms need to be changed regularly by the end-user/client or the terms need their own node pages, it’s better to make a new content type for the vocabulary and use a node reference field (References module) to categorize the content. For example, a real estate site has a list of counties and they want each County to have a page on the site with a view listing all of the for sale property in that county. Making a content type called County and adding a node reference field to the property content type accomplishes this goal.
Added 4/5/12 8:30 am: As @Bill Fitzgerald pointed out the References module claims that it will be deprecated in favor of Entity Reference at some point, although with 39,000+ sites using References I'm still very comfortable using it on new sites. Take a look at both before you decide.
Free-Tagging Categorization
Reproducing free-tagging categorization is simple. It’s the same idea as option #2 above, but use the Node Reference Create module (depends on References module) on your node reference field (autocomplete) so that when a user enters a tag in the node reference field that doesn’t already exist it will be automatically created in the tagging content type.
Added 4/5/12 8:30 am: Due to the References module's claim that it will be deprecated in favor of Entity Reference at some point, the Entityconnect module will accomplish something similar to Node Reference Create, if you are using Entity Reference instead.
Hierarchy
Reproducing the Taxonomy module hierarchy functionality is by far the most difficult part of abandoning the Taxonomy module, but it is not impossible. A node reference field called “Parent” linking to nodes of the same type is the start of the solution. Then depending on your specific needs, that field can be used in views to create a hierarchy of terms.
This part can be complex, but in most cases, at least for me, it is worth it to be able to get away from the Taxonomy module.
Views
Fully customized views is the reason to go the sans-Taxonomy route. The Taxonomy module forces you to have a view for each vocabulary and term, but sometimes you just don’t want or need that. Trying to override those views is a real pain, especially for a new Drupaler. I find it’s much easier to build my own views.
If you intend to attach a view block to the term pages, you need to learn to use the “contextual filters” on the view. Add a contextual filter of the node reference field you set up earlier. Use the option to “Provide default value” and set it to the type “Content ID from URL”. Your view will only display nodes that were tagged with the term for the page you are on.
Of course you can do much more advanced views, but this one will reproduce the basic functionality of the Taxonomy module.
The Prosecution Rests
An argument I’ve heard in support of the Taxonomy module that carries weight is that it’s already there out of the box. This may be a good enough reason for a new Drupal site builder to use the Taxonomy module, but a site builder with a little bit of views experience can do anything that the Taxonomy module does and better, without too much effort.
If you decide to abandon using the Taxonomy module and find yourself repeating this work on multiple sites, build a feature to setup a custom vocabulary and install it on subsequent sites.
If you agree, disagree or just want to weigh in on this discussion, leave your thoughts in the comments below.
Added 4/5/12 8:30 am: Thanks to everyone for being cordial in the comments. It is a testament to the strength of the Drupal community that we can openly discuss a topic without resorting to personal attacks. Thanks again!
MONTHLY MARKETING INSIGHTS.
Get thought-provoking and actionable insights to improve how your firm makes a connection with your customers.
LEAVE A COMMENT
Given that References is slated to be deprecated in favor of Entity Reference (as stated on the project page of the Reference module) and that Node Reference Create has a dependency on Reference (as seen in the .info file) the solution you are outlining here could become obsolete during the D7 lifespan.
I'm not wedded to taxonomy either, but I'd rather use something that will remain supported during the entire D7 cycle than implement something that could become obsolete.
Taxonomy arguably isn't perfectly implemented, but its better in d7 than d6. The weakest part is support for the hierarchy, especially in views.
But I wouldn't want to dump it because
1) taxonomy is a well understood discipline with familiar and important concepts, and is an excellent approach to content management
2) many contributed modules have extended what taxonomy can be used for
3) Drupal developers are very invested in the taxonomy approach. Better to improve it than junk it.
Interesting point of view!
My main gripe with your solution of using Nodes and references (be them references or entity reference or whatever) is the unecessary overhead that is generated.
Node have revisions and other properties (sticky, promoted, published) that simply may not apply if you just want a user-editable list of values.
Maybe dumming down the taxonomy module and moving some of those assumptions to a separate module would be a more feasible solution?
I found your post interesting because in a recent project I had to decide whether it would be best to organize some nodes around taxonomy or referenced nodes. This is the classic "everything is a node" dilemma that fields in core for Drupal 7 only made it more dramatic. In this sense, we could also think about RIP the user module. However, I still think some of these assumptions hard-coded on both the taxonomy and the user module are quite useful. Perhaps moving both of these modules to a more entity like approach with these assumptions soft-coded would be a more elegant solution. But until then, long live the taxonomy and the user module! :)
Presenting no arguments other than your personal dislike and a handwavey “the module makes too many assumptions about the way content categorization should function”, you dismiss and declare dead one of the historical great strengths of Drupal, namely an industrial-strength taxonomy system, and then proceed to present a list of inefficient workarounds for its use. Creating nodes for all tags on a site? Really?
That you can't think of good use cases does not imply that they do not exist. And if you find overriding taxonomy/term/% with Views, Panels or a custom module hard, I worry about your Drupal proficiency.
Interesting thoughts. Ditching taxonomy is not likely to happen so long as Dries is keen to make Drupal and Drupal Gardens as accessible as Wordpress, as well as developing Drupal as framework. New users should not need to use Views and should have the equivalent of WP 'post categories' out of the box. If Drupal were only seen as framework, rather than trying to be an easily usable CMS at the same time, your arguments may have more chance of being adopted.
Good breakdowns, thanks. I had better luck with references sometime ago. Knowing that entityreference is getting matured, I soon turn into loving it. Apart from its shortcomings, I found the most part, and surely the future, is good.
If you are using entityreference, there is now http://drupal.org/project/entityreference_prepopulate
What about http://drupal.org/project/hierarchical_select? :) See http://wimleers.com/demo/hierarchical-select/taxonomy to find out what it can do.
Any tips on how to take a Drupal site that does use Taxonomies (none of them are free-tagged ones) and migrate them to entities?
Overriding the Taxonomy View is dead simple in D7 with Taxonomy Views Integrator, to control output with Views, or Taxonomy View Modes, to control output with TPL and field configurations.
In any case, the added pages taxonomy gives you is good for SEO and content.
A 'category' is -not- a content type in my mind. You could have a site with 15 vocabularies- would you want that piled on to the site content types? You should strive to maintain as few content types as possible to reduce the overhead.
TVI: http://drupal.org/project/tvi
TVM: http://drupal.org/project/taxonomy_view_mode
Either one of those solves 95% of the issues you outlined with it.
"For example, a real estate site has a list of counties and they want each County to have a page on the site with a view listing all of the for sale property in that county. Making a content type called County and adding a node reference field to the property content type accomplishes this goal."
You can easily do this with Taxonomy, or Entity Reference, or Views. Make the county a contextual filter argument, and off you go.
Thanks all for the great comments. I think this discussion is health and I've made some additions to the post to reflect some of your suggestions.
Also, to clarify my position: I am not at all suggesting that the Taxonomy module be taken out of core or that development be abandoned. And I'm sure that there are some very specific use cases where it is essential.
What I am suggesting is that we as site builders and developers not make a knee-jerk decision to use Taxonomy just because it's there and we've "always done it that way". There are other more elegant ways to accomplish a task that may in turn push us to improve the Taxonomy module.
@Alex Weber & @Mikkel Hogh, Since taxonomies are now fieldable in D7 and are essentially entities just like nodes, I'm not sure if there is much of an overhead difference. Maybe someone more familiar with their underpinnings could comment. I've found it an advantage to have the terms as nodes in many situations. Although I can also think of some situations where I wouldn't want those nodes navigable.
@Mikkel Hogh, despite questioning my "Drupal proficiency" :-), you make a great point about the historical significance of Taxonomy. Thanks for bringing that up. I think it deserves consideration when someone it deciding whether or not to use Taxonomy.
@gaus: Nice module suggestion!
@James Oakley: Lot's of patience! If you've already headed down the Taxonomy road, you might consider just staying on that path unless there is some serious roadblock that is preventing the project from moving forward.
@matslats: Excellent points! We should all consider these when deciding when and how to use Taxonomy or not. To reiterate my position: Taxonomy should remain in core and continue to improve (as it did in D7) but we should consider other approaches before using a module that is overused for every kind of tagging and categorization despite not being ideal for every situation.
@Kevin Quillen: Thanks! Both of those modules are in alpha and don't have a lot of usage. How has the stability of them been for you?
Absolutely. TVI is excellent for Drupal 6, and I use it in D7 to override outputs on taxonomy/term/% pages.
View Modes is another great concept to look into for D7 for even greater theming control of output and presentation.
I am fairly familiar with the technical underpinnings, and the whole reasoning behind having fieldable entities in Drupal core is precisely that we no longer have to make nodes of everything we want to add fields to.
You might not know of, or appeciate them, but there are a great many good usecases for a good taxonomy system (it is, after all, its own branch of science: http://en.wikipedia.org/wiki/Taxonomy )
So if you don't like Taxonomy, you're free to do something else, but please stop bashing what you don't understand.
@Mikkel Høgh: Understand my purpose here. It is not to bash anyone's hard work in developing the Taxonomy module, but to challenge what I see as the overuse of a module and encourage developers and site builders to think outside the box when building a Drupal 7 site. I apologize if some of my hyperbole in the post has offended you directly. It was meant to promote a discussion not offend. As you stated and I've mentioned a number of times in the post and comments, there are clearly some usecases for the module.
The science of taxonomy is not in question here but only the implementation of said science in Drupal. :-)
To All: The exercise of writing this post, reading and responding to the comments so far has taught me a lot about taxonomy and related modules. While I consider myself an experienced Drupal developer I do not know all. Discussions like this help me become a better developer and I hope they also educate others. And as always I reserve the right to change my mind as I learn and Drupal improves.
I also use a entity/node reference approach in many projects since Drupal 5 even. I still think the taxonomy module is a great strength for Drupal, having the ability to build relationships between terms is awesome.
I came across this post after pulling my hair out for a week just trying to find out how to theme a custom view based on taxonomy as an argument. To see an example of my pain, here is my most recent post http://drupal.org/node/1516146. To see more pain, just click on my name to see the scores of unanswered questions related to the subject as well as the upteen stackoverflow requests for help. Why is this so hard? Why is it not just simple default functionality to be able to use Views or another simple method to theme a taxonomy page? Thanks for the article. I will try the different approaches, as taxonomy is useless for my needs if there is not a simple and easy way to interact with it.
I think people do forget about referencing nodes. If I have a project where I have a central object like a community for example. It will be a node and all things that attach to that node will be node referenced. If taxonomies were used, and this has been done too much in the past at my company, you would have to check off the term in the community and in the related items. More checking less efficient.
If I have a number of content types need to be connected to a category than taxonomies win out.
My point is I do think node referencing first taxonomies second. View modes are wonderful in 7 for taxonomies and nodes for that matter.
Long live options! I don't care if they are in the core or contrib as long as options are available I will keep on loving drupal and the community that supports it!
Oh and by the way I have been using http://drupal.org/project/taxonomy_display to tame how taxonomies are displayed. I has seemed to be working great.
@Blue: I'm glad this post was helpful and I hope you are able to find an alternative solution that works for you. You may also want to look at some of the taxonomy modules other commenters have suggested if you've already built the site with the taxonomy module. Changing in mid course would be difficult at best.
@circuscowboy: I like the way you think. Also, nice module recomendation.
So, you're entitled to your opinion and of course should use whatever architectural solution works best for your use-case, but the title of this post is utterly misleading.
taxonomy.module is lovingly supported and maintained in D7 core, and will continue to so be in D8. :)
Furthermore... it would be great to see some of the great brainstorming and analysis in this issue to improve the core taxonomy module!
http://drupal.org/project/issues/drupal?component=taxonomy.module
I wrote a significant part of Taxonomy module in D7 (the taxonomy term reference field) and am named in the MAINTAINERS.TXT for this work.
Taxonomy.module is a strange beast, because there are easy ways to accomplish what it does for most users without ever touching taxonomy.module's functionality. Likewise, if Taxonomy.module ever became a more advanced and powerful tool for building controlled vocabularies and actual scientific taxonomies, the "Drupal core" use case is marginalized.
The way I use taxonomy module is this: my content (nodes) are original to my site, but the terms that describe it (taxonomy terms) are concepts that are part of universal, cultural and scientific truths that exist independently of the content on my site. For these concepts, I only need a name to represent those concepts. Taxonomy.module is a place where relationships of meaning are played out against the content of my site.
Taxonomy.module is basically three unique things:
1. An inflexible hierarchical relationship.
2. Free-tagging or the automatic creation of entities by name.
3. A UI for managing controlled vocabularies and their hierarchies.
The data and UI of taxonomy.module's hierarchical relationship has not kept up with the rest of Drupal. This is a lot more complicated than simply indicating that a term has a parent. It's also a method of querying data hierarchically: show me content whose nature is like X, where X is also things that encapsulate a thousand other concepts.
The UI for managing vocabularies is barely suitable for hierarchical, controlled vocabularies. How useful is Taxonomy.module's vocabulary admin UI for a tagging vocabulary with 1 million terms? Not at all.
The tagging field could be better, but it's probably the least problematic of all.
Meanwhile, there are a few things Taxonomy.module needs to be but isn't:
1. Terms need to link against concepts externally and universally not just internally. We have no way to associate the "Drupal" tag on my site to Drupal tags on other sites or to larger concepts of "CMS" and "web development."
2. The hierarchical relationship needs to be re-imagined merely as a transitive relationship. Terms need to be able to have lots of these not just one.
3. Terms should always be unique. The same term should be able to appear in many vocabularies.
4. Data sources like dbpedia should be usable as field data sources for taxonomy terms. I shouldn't have to create new terms ever unless I've invented something truly new.
Well, I'm going to say that I agree that the Taxonomy of Drupal, is rather... a pain in the butt. Sure it's easy to create a vocab and add terms and such, but if you want to change the output of the taxonomy display, you pretty much have to have a MIS degree to know how to do it.
Sure, you can override it with views but from my own personal experience, it's very easy to override ALL of the vocabularies, but not specific ones. I looked into TVI around March 2012 and it was way too buggy to do me any good.
The absolute EASIEST and cleanest way I've found to override the display of taxonomy, is to override them using the Panels taxonomy template. Unfortunately, it's a lot of overhead just to change the display output but I fell in love the first time I figured out how to do it. What took me 2 days of jacking with in Views and never resolving, took me 20 min to figure out with Panels. (I wish views handled "contexts" in a similar way Panels does, but that's a completely different rant)
I do my best to stay away from Taxonomy but there are times I do have to resort to using it. I've had bad experiences with Taxonomy ever since I started using Drupal 5 and while Yes, it has come a long ways since then, there is still something about it that just doesn't play nice with the rest of Drupal. It's almost like it's the stubborn red-headed stepchild of Drupal.
Anywho, I'm not bashing Taxonomy nor the developers who created what it is today, I'm just agreeing with the author that there's something "Off" with Taxonomy when compared to the rest of how Drupal works.
@Benjamin Doherty I wrote my previous post before reading yours. Very insightful!
Not being a coder (at all) I have a limited knowledge or (completely) ignorant knowledge of the backend workings and forget that it's sometimes extremely difficult to accomplish certain things because of the limitations of the API, code language or database engine.
Your post made me realize that the backend of Taxonomy has a heck-of-a-lot more going on behind the scenes when compared to a node and explains why it's the "red-headed stepchild"...
Hat's off. I'll do my best to quit complaining :-)
If using node and node reference for categories, each tag will create a individual node page and clients may wondering it's not looking good as they are such for content categorization but not expose the node to public.
@Adrian: You are correct, you have to handle what happens with the node view on that ... add to robots disallow, 301 redirect, and/or noindex
@Benjamin Doherty
Totally agree on your point of view!
I'm no coder or themer but well practiced in database-design.
From the beginning of using taxonomy in Drupal 5, I didn't understand, why there was no easy possibility given to create tables and relations (1:1, 1:n as the important ones in taxonomies).
It seems to me, as if taxonomy in Drupal in the beginning was only a possibility to provide more tag fields. Tags don't need a hierarchy, but taxonomies always do.
Maybe that's the reason why the backend is as you described: "The UI for managing vocabularies is barely suitable for hierarchical, controlled vocabularies. How useful is Taxonomy.module's vocabulary admin UI for a tagging vocabulary with 1 million terms? Not at all. The tagging field could be better, but it's probably the least problematic of all."
In a relational database you never have a hierarchy in one table, but you have it in Drupal running on MySQL, a database designed for all kinds of relations.
I'm using entities now, haven't been into Drupal for a while. Entities are an improvement but the UI could be far better. It's funny to mention that I need a quarter of time building tables, relations, queries, forms and reports in MS-Access or in oO Base.