I've been having a bit of trouble getting prepared for my upcoming deployment presentation at DrupalCamp Austin, but I've found that when I write things down, it really helps me understand them better. So, without further ado and in no particular order, here are some of the most helpful things I've learned about the Drupal features module in the last few weeks.

Features are just modules

When you download that freshly-exported feature archive and drop it into your site, you're really just installing a new module. It has all the standard Drupal module files: my_feature.info, my_feature.module, and so forth. The difference is in how it's handled and in what it's handling. That is to say, features are Drupal modules designed to help install and configure functionality provided by other modules …they're modules themselves, but at a higher level of abstraction.

Here's an example for you. Let's say you wanted to build an event calendar for your Drupal site. Without features, the typical workflow (at least what we've always done here at CWS) would be something like this:

  1. Download and enable the date and calendar modules.
  2. Create an "Event" content type with a date field.
  3. Clone the calendar view that comes with the calendar module and modify it such that it uses the Event content type and date field.

All told, then, this single "feature" (an online calendar showing dated events) requires 2 separate Drupal contributed projects, along with the manual configuration of a content type and a view. Maybe 20 minutes tops, but still, it'd be lovely to be able to do the whole thing with a single click.

That's where features really shines. Once you've performed the above steps on one site, you can use features to build all of that configuration into a single encapsulated module that can be versioned, packaged, and deployed on any Drupal site with features installed. It's still using every last one of those dependencies, but it serves as an abstraction layer between the end user and the more esoteric kinds of configuration that can make Drupal a bear for lay people…all the user needs to do is turn on the feature, and all the nitty gritty details are taken care of.

If you want to see it in action, feel free to check out the calendar feature we put together for UNT Drupal sites; it handles all of the above steps and didn't require any custom code apart from what features exported.

Features doesn't handle everything yet

Features is still in beta at the time of this writing, and there are a number of pretty common use cases it doesn't handle just yet. One of the biggest missing pieces (in my book) is taxonomy integration, specifically the ability to export taxonomy vocabularies.

One common case where this would be necessary is a blog feature. A blog isn't really a blog without tags, and out-of-the-box Drupal doesn't come with a tagging vocabulary pre-configured. As a result, a blog feature would generally need to include such a vocabulary.

Taxonomy integration in features is still very much a work in progress, mainly due to the fact that Drupal 6 vocabularies don't have machine-readable names (a requirement for features export). There's work being done to resolve this; for example, I'm currently co-maintaining the exportables module, which provides a means for vocabularies to have machine-readable names at a separate layer. It's not an ideal solution (it'd be better if vocabularies actually had machine names in core, which they do in Drupal 7), but it gets the job done (as long as you don't need to use your taxonomies in exported views…that's another issue entirely).

Features servers

When I first read about features servers I was pretty excited; I figured that it would be possible for CWS to run its own features server and automatically deploy any code updates from there, rather than having to re-deploy the code by hand from the command line. I'm going to let you know up front: this isn't how it works, at least not based on what I've seen so far.

Rather, a features server is just a decentralized hosting site for features-generated modules, much as drupal.org/project hosts traditional Drupal modules. Decentralization is certainly a good idea, but I did want to see this functionality taken a bit further…maybe I just haven't read the right blogs yet.