Drupal 7 Taxonomy Reinvented

This time I have taken a closer look at the changes to the core taxonomy features in Drupal 7. Initially I thought this would be a short post, but as with most things with taxonomy it grew quite a bit. I hope you find it interesting and useful.

Taxonomy in Drupal has been one of its strong points for a long time. What is also known is that the core features hasn't changed much between the last major releases. For Drupal 7 that is not the case and taxonomy has received a much welcomed modernisation. The main, and biggest, change being that taxonomy now use the new Field API. Opening up a whole slew of new possibilities.

Using taxonomy in Drupal is both an art and a science. For many, like myself, it took quite some time to start to really understand its full potential. Even though it is a rather simple feature, its flexibility and usability have made it being used for much more than just classification of content, such as those modules that uses it for access control to name one.

On top of that, there exists many other contributed modules adding even more functionality to it. Taxonomy Manager, Taxonomy Hide, Content Taxonomy and Taxonomy Image are examples of contributed modules that does this and makes the core taxonomy support much more useful. More about contributor modules later on in this post.

Taxonomy Settings Minimal

Lets start with the visible changes. When you add a new taxonomy vocabulary (or category as it is also called) you will notice the largest changes in the settings.

Now there are only two visible fields; Name and Description. Compare that the the page in Drupal 6 where you had to decide between Tags, Multiple choices and if it was going to be required. Also, you could set for what content types it should show up for.

Neither of these settings are now controlled here, instead you decide that when you add them to for example a node or a comment. Yes, since they now are fields, they can be added to anything you can add fields to, including taxonomy terms in other vocabularies as well.

Another change you notice here is that core doesn't have visible machine name fields any more. Instead it is automatically generated from the Name field, when one is needed. As soon as you start typing the name, you see the machine name appear to the right of the field. It does provide an edit option and if you click it the field for editing it will appear and you can manually change it. A small, but smart change in my opinion.

Managing Fields

This is where you find the new really cool stuff. In Drupal 7 you can easily add any field to your taxonomy terms, individually for each vocabulary. This new possibility will immediately render many Drupal 6 modules more or less not needed to be ported, at least not their main features.

It is now possible to quickly add additional fields to transform the core term pages from being a simple name and description to, in many cases, replace what you before had to create special content types for.

Take a category named Organisations as an example. In it you store all the names of companies and other organisation that the vocabulary is used to categorise content for. By adding a few more fields, such as logo, link etc, you can collect all the basic information about that organisation in one place.

This information can then easily be themed to create a much better summary and information about the term when a user clicks on it. The logo will be displayed and any links relevant to it will also be there.

In the content you tagged with it, you will be able to easily reuse this as well. For example show a fact box with the logo, description and URL.

This will make this kind of information much more manageable and easy to reuse. Did I say it comes right out of the box?

When editing the term you also have the option to select text filter for the Description, so integrating it with a WYSIWYG editor is not a problem.

For content types the Manage Displays has three options, Basic, RSS and Search. For Terms there are no such options, at least not visible in alpha 5. Considering the example above, being able to fine tune each of those three displays would make things complete. Without them you will have to think a bit extra when you adding a lot of fields to a term. Hopefully we will see a contributed module adding this.

Another thing you will notice is that both the core Name and Description fields can't be edited. You can rearrange the order in which they are listed, but there are no edit buttons, nor do they show up in the Manage Display list.

I do realise that they are both required fields, but I also believe they should still offer limited settings and display controls.

Adding & Editing Terms

Here too you will notice some changes. Not directly but when you click and expand the Relations (Advanced options in Drupal 6). Now it contains only Parent and Weight. Gone are both the Related terms and Synonyms options.

Synonyms are easy to replace by simply adding one or several new fields to the term managing that. In the Organisations example above you would probably also add a date field so it is easy to see when that name change took place.

A problem here is how to handle redirects from the old URLs to the new, but that can be sorted with for example Path Redirect.

Related terms will though be harder to emulate this way. Even if you can add other vocabulary fields to the term, you can't add the terms own vocabulary to it. For those needing this functionally, I am sure there will be a contributed module adding it back.

What else do I Miss

While I haven't had time, yet, to fully explore the new possibilities with the new taxonomy system, I have found a few things that I believe would have made it more complete.

• Moving terms between vocabularies - As far as I know, it has always been possible to move a term between vocabularies. I am actually surprised this wasn't added for Drupal 7. After all, in Relations you can set the Parent Item and I don't believe it would have been to difficult to change that so it could be used to move it to another vocabulary as well.
• Replacement pattern for term titles - I've always thought that just the term name on the view page has looked a bit dull. To be able to spice it up a bit by being able to create a replacement pattern in the vocabulary would have been nice. Token is in core, so getting the term name would not be difficult.
• Autocomplete Widget - It is still limited to 128 characters. This severely limits it, especially considering that it is not the term name, just the term ID number, that is stored in the tables. Often when you use free tagging you will use multiword terms and that will quickly eat up this limit.

There are of course many other things that can improve taxonomy, but everything does not belong in core. Of the above three, moving terms between vocabularies and a higher limit for the autocomplete widget is two that does belong there, while the replacement pattern is a little more doubtful.

Contributed Modules

Contributed modules will of course still be needed as they will add a lot of possibilities we have grown used to. Some of them have seen a their functionality been fully, or partly, replaced by what is now in core.

A short list of common modules and how Drupal 7 affect them:

Taxonomy Manager

More or less all its features are still needed. It adds the capability to move terms between vocabularies, which is most useful. Its merging of terms features will have to change though. In Drupal 6 it uses the synonym feature to store them and that is gone now. As mentioned above, this can be solved by adding a new field. However, that requires changes to the modules logic to manage, as well as the logic handling the URL's for the old terms.

Its UI and integration with the core taxonomy, would also do good with an update. For example, moving terms requires the double tree view to be used. It would be nice if this also could be performed directly on individual term pages, plus that Taxonomy Manager would take care of redirecting from the old URL's (system paths and aliases) to the new.

Taxonomy Hide

Its main feature, to hide the terms from being viewed on nodes, is now managed by core individually where the vocabulary is used.

The group feature would still be a welcomed addition to Drupal 7, but it will require quite a big rewrite since the old logic is based on grouping the vocabularies that is viewed by Drupal 6 core in nodes. To get this to work fro Drupal 7 it needs to integrate with the Field API so you can select which vocabularies to group, but also how they are presented.

Taxonomy Image

The features in this module is now in core so no point porting it.

Content Taxonomy

Here too the main functionality has been superseded by the new core features, but not all.

One thing I like, and use, in Content Taxonomy is to be able to select if the terms used should only be stored in the node or also synchronised with the taxonomy. This allowed you to use a vocabulary as an option field list and it also to be used multiple times in the same content type. It also made it easier to add options to.

The only drawback is that you end up with vocabularies with terms that does not link to any content. Together with that I haven't found a way to block access to those term pages, other than robots.txt, for visitors and search engines limited its usability a bit.

It would be great if that feature could be reused in a new module, call it Field Options List Manager or something similar.

That module would replace the "Allowed values list" text area for the Lists field. It would either let you use a vocabulary as template, or let you create a new list with the same structure as a taxonomy vocabulary. The difference would be that the non taxonomy lists would only be accessible from the fields using it, but still centrally managed. Letting you select the list source like this would provide great flexibility.

Take a country list as an example. This would be perfect to have in taxonomy, adding fields for flag, language, etc. It would be usable to both classify content and used as an option list. Such a list you would sometimes need more than once in a content type. For a product content type you use the taxonomy to classify that the product is available in certain countries, while you also use it to set what languages the documentation is available in.

Integrated with the next example would combined create a very flexible solution.

Hierarchial Select

This module you definitely want to see ported. With its integration with both Content Taxonomy and Views it added a lot of very useful features to Drupal 6.

Two of those features is the ability to add terms to any vocabulary directly on the node edit, as well use it for exposed filters in views. Getting those for Drupal 7 is a nobrainer.

Since terms now can be easily extended with new fields, Hierarchical Select is up for new challenges as well. How about if it would let you configure how the terms are viewed. For the country list above you can set it to view the flag instead of the name, of course also be able to set the Image Style to be used for each individual place the vocabulary is used in.

By being able not only to use its flexibility to provide a much better selection, but also how that selection is viewed would make it extremely versatile.

Verdict

Overall I am very pleased with the new updated taxonomy system. It is not perfect, but the improvements have added to its powers. Missing pieces can, and will, be added by contributed modules.

Personally I have already thought of several interesting ways of using it and I am sure you will too, if you haven't already.

When we start seeing missing features trickle through as contributed modules, then we will really start to be able to use its true new powers.