Features, Dependencies and the Drupal Way

By mrbagnall | 17 April 2016

I recently gave a talk at the DC Drupal group where the subject of features and dependencies came up. I may have been the only person in the room who dislikes and dis-trusts features as vehemently as I do. Why? Because it’s terrible upgrade management, unpredictability in terms of reversion and the overall realization that it can take a perfectly working site and reduce it to a pile of rubble with the click of a button.

 

And now to further complicate things, there are Feature Overrides modules - which Features is “supposed” to handle by default. Which seems to be just another potential site dependency and abstraction that gets in the way of being able to track problems and revisions within features. 

 

In a nutshell, I don’t get the fascination with features. If you want to use it to create content types for your modules - there are plenty of other “Drupal” ways to do that. Drupal gives us a wonderful set of functions to do this which can be performed on a module install or during an update hook that makes the upgrade path much cleaner and more reliable. 

 

In fact, I have a module that takes entity types from Nodes to Taxonomies and even custom entity types and creates an include file that re-creates them on the fly. It’s nowhere near ready for prime time but it will be. But once completed you can use it in your module or as part of an install profile to create your content types easily and on-the-fly without the need for features as a dependency (as well as everything that goes along with it).

 

Now before I go much further, I know there are other advantages to Features aside from simple content type management. But even stronghold items can be handled within modules. Views setups can be trickier, but even these can be handled within a module.

 

All of this to say that you can do these things in much more of a Drupal way and Features is nothing more than an unreliable shortcut which can actually break things. How many times have you feared doing a feature reversion on a production site as part of a deploy and crossed your fingers that nothing would be hopelessly lost?

 

One additional problem, I worked for an organization that built a complete platform on Features1 1. It may be different 1, but last I knew they still had to hack Features 1 to support it due to the lack of an upgrade path from Features 1 to Features 2 within the scope of their project. To say nothing of future versions of Features which are sure to come down the road. And as of this writing, a security note was posted for Features 1 & 2 this past week to which Features 1 will not be fixed.

 

So friends don’t let friends use Features. I know I don’t unless I absolutely need to. I am writing modules to do things the Drupal way like my Entity Type Export module… which does NOT re-create features, but generates code that does things in the Drupal way and will even soon generate update hooks.

 

It’s all part of my evangelistic tone of reducing dependencies and having cleaner Drupal installs without the need for extraneous and unnecessary overhead in modules. That makes Drupal slower (something nobody needs) and seems like an un-needed short cut to me. We, as Drupal developers, can do better. And we must do better for the sustainability of our code, for the predictability of our upgrade paths, and just for plain and simple doing things the way Drupal was designed to do them in the first place.