We All Had the Features Module Wrong

Nov 20, 2015 11:00:00 PM Mike

Drupal Features moduleIf you are familiar with Drupal modules, you may have heard of Features. It is a pretty cool module that allows you to capture your changes to fields, content types, etc, and pull them into a custom module. This is pretty cool since usually writing the code for these database changes can be tough and/or time consuming to do manually. Features can do some pretty cool stuff because you can pull in nearly all of the configuration you did on the site into code and that can be used to duplicate that functionality easily to different sites and environments. Sounds super cool, right? Too bad most everyone that used it in Drupal 7 got it wrong!

In the past, we would deploy features to an environment by committing the feature and enabling it through the Features module out on whatever environment we needed it on. This sounds like the right way to do it, since we were using the module to manage things created by the module. The problem was that changes made to the configuration on that environment would lead to the feature claiming it was overridden and making it far more difficult to role out updates or changes to it. I had all but given up on Features and this awkward deployment cycle that it caused. 

I attended the DevOps/Configuration Management summit at BADCamp this year and Features was a topic brought up a few times during this. It was here that I discovered something very interesting with how Features was intended to be used. The purpose of this module is simple, to package features into something portable that can be used for different sites. This means that if you have a slideshow you put together on one site, features would allow you to export all of the pieces of that slideshow into a module and then you can easily reuse that same feature on another site. It was never intended for deployment from dev to prod, but from site to site. This explains a good deal of the awkwardness we had experienced in the past in using this module.

Drupal 7 doesn't have too much in the way of configuration management and what it does have is a little time intensive, but there is a way to lean on Features to get maximum benefit with minimal issue. I would recommend not using the Features module on your production environment. It isn't necessary and it makes it more difficult to manage. Features creates modules that can be deployed like any other custom module and can be deployed and enabled just the same. This is one less headache when using Features and it can make deploying changes to a site a little less click intensive. 

It is worth mentioning that Features ultimately doesn't do anything that can't be accomplished with existing hooks in Drupal, so it might be worth your time to see what it creates and how much you actually need to lean on it for managing your configuration. In Drupal 8, configuration management has become a whole lot better and deployment seems to be way more simple and consistent that before, so we may see less use of Features in the near future. For now, at least we all know how it can be put to better use in Drupal 7.

 Also, make sure to check out Mike Potter's session on Features in Drupal 8 from DrupalCon 2015 Los Angeles.

 

Mike OUT

Topics: Configuration Management, Features, Badcamp