Features Should Be in Your Drupal Toolkit

It's been a really long time since I've worked on a Drupal build that didn't make use of the features module in some way or another. For better or worse it's turned into one of those modules like Views that's simply a part of the expected toolkit for many projects. Yet I still occasionally meet people who haven't heard of it yet. It's always fun to see the lightbulb over their head when you explain it to them and you can see the gears start churning as they immediately start imagining all the tedious box checking they can eliminate from their daily workflow.

The 2.x version of Features came out not too long ago and we are starting to make use of it in our work. It's a great update that's added a few new elements and greatly improved the usability of the the module. It reminds me again how important this module has become to solving so many different problems for us. So I want to take this opportunity to remind you that it exists. And for those of you who haven't used it before, hopefully this post will get the gears churning a little bit.

What exactly does Features do?

James Sansbury wrote an excellent retrospective on the Features module that does a good job of explaining the problem space and how we ended up with the Features module. In summary, one of the things that makes Drupal awesome is the ability to do so much site building without ever having to write any code. You can create content types, click together views, and change the default behavior of the user registration process all through your browser. The challenge in this is deploying those changes to other team members or from a development instance on your laptop to a live site.

Because content is likely continuing to be generated on the live site whilst you work away on your flashy new view you can't (???) simply replace the database on production with a copy from your laptop. We need a way to remember the configuration changes that we made on our local environment, so we can replicate them in the production environment. Enter Features. I often think of features as way of automating the things that I used to record in a checklist. Deploying meant going through my checklist and configuring those things on the live site really fast; hoping no one saw the site when things were broken for a few minutes. This presentation from DiWD 2008, while a little dated, does a good job of explaining the problem space.

Tell me more!

Want to learn more about using Features in your own workflow? Here are some good resources to help get you started:

In addition to the blog post linked above, James also has a recorded presentation that covers a lot of the high-level who, what, and why of features.

The Drupal.org documentation for Features contains a lot of useful information.

We have a complete series on creating features and deploying them with Drush that covers the majority of things you're likely to do with Features in your day-to-day workflow.

While Drush isn't required to use Features it certainly makes it more pleasant. If you haven't used Drush before or need some help we've got a series of videos covering Drush basics that will help you on that front.

I would also recommend taking a look at this blog post about naming things, since it's important to have a good naming convention when using Features.

Sometimes you're going to run into things within Drupal that can't be exported with the Features module. In this case, we still fall back on old reliable hook_update_N() and performing direct database queries. It's not always pretty, but it's a whole lot better than the checklist approach. If you find yourself needing to go this route, review this video on Altering the Database. It covers the process of creating your own update hooks, with a focus on altering the schema of an existing table. But you'll learn how to execute an update function and you can start adding your custom queries there.

Finally, what about writing your own modules and making the configuration data exportable via Features? We've got a short video about making things exportable via CTools. And in Drupal 7 you can make your custom entities built (using the Entity API)[] exportable with just a few extra tweaks to your controller.

Related Topics: 

Comments

Add new comment