Should I use Features in Drupal 8 and how?

If you ever needed to deploy your Drupal 7 page from local environment to staging and further to production, you probably used Features to accomplish this task. Although the module itself wasn’t built for this purpose, it was widely (ab)used to move entire configuration from one environment to another.

Features were meant to bundle certain functionality (for example Image gallery or FAQ functionality), export it to a module and use it on another page with same requirements. But because there was no configuration management system on Drupal 7, Features were all we had for deployment.

And they were certainly not ideal. You have to had quite a lot of knowledge to wrap your head around all the configuration you were able to export. And if you wanted to export something to the Features, other modules had to write the integration. So there were often cases, when you used some new module and you weren’t able to export the configuration to the Features, because module developers hadn’t write the integration yet. Luckily, things changed in Drupal 8.

CMI

With Drupal 8 all the developers got what they were craving for. CMI stands for Configuration Management Initiative, and it’s probably one of the most successful initiative on Drupal 8 roadmap.

Content (articles, blogs, users etc.) and configuration (content types, fields, view etc.) got separated completely. Developers are now able to export all the configuration to files in YAML format, which can be described as a file format for describing data. So, instead of generating PHP code like it was the case with Features in Drupal 7, we now generate these YAML files and move them across different environments.

 

CMI

This thing is working, it’s great and we finally have a fully functional deployment tool. Now we only have one question to solve. Why would someone (that someone is mostly Mike Potter) spend hours and hours on developing Features for Drupal 8, if we have CMI?

Why use Features in Drupal 8?

Well, Features in Drupal 8 should be used as they were meant to be used in Drupal 7. To bundle reusable configuration.

Let's begin with an example. An FAQ feature is a good one. You often need it on several sites and you usually spend some time clicking around the Drupal backend. You need a content type with, for example, two fields, question and answer. Then you can create a page view, which lists all frequently asked questions. You can also create a block view titled Recent FAQ, in which you put a couple of latest questions.

To export this kind of feature with CMI, you would have to go to the exported YAML files, find the correct configuration files and copy-paste them to a module. You would take my-content-type.yml file, than the .yml files for both fields and you would also need to export view (which we can assume has both displays in it). After all that, how would you know you have everything? Are you an expert enough to know that you would everything? Would you have both field and field storage configuration?

Features in Drupal 8?

This is where Features come in play. Basic functionality is similar to the one we’re used to from Drupal 7. You can import and export configuration and detect changes. But there is also something new. First thing is called an Assignment plugin, a way to auto-create features based on certain rules.

For example, if you want content type based rules, the plugin will auto-detect content type, all the fields along with field storages, possible views that show the content of this type, image styles used in this content type etc. In Drupal 7, when you opened Features module, you had an empty screen. And it was hard, especially for newcomers, to start working with them. Now, when you open Features configuration page for the first time, you already have suggested features, and you can start working from there.

The other new thing is Bundles (also called namespaces). If you use features from different pages, you can namespace them, so you have them all nicely organized. It’s something similar to the Package field in Drupal 7, where you were able to organize your features in groups. Except now you are also able to select different assignment plugins for each bundle, so you can really configure the way you want your features to be generated.

 

Bundles

As I mentioned earlier, Features in Drupal 8 are essentially storing all the necessary YAML files you need for certain feature to work. One big advantage of using YAML files for storing configuration is that you don’t need Features on new site anymore. When the feature you created on one page is enabled on another page, it’ll take all the configuration from the install folder. And since the configuration in Drupal 8 is owned by the site and not by modules, all the configuration can be handled using CMI. That means you can even uninstall the feature module afterwards and it won’t affect the site configuration.

The only drawback about this is that you can’t update the site configuration if configuration in feature module changes. If you don’t have Features module enabled, the only way of achieving this is to uninstall and install module again. But if you are developing the site and you have Features module enabled, than you can easily import changes.

Other small differences

There are also some other small differences that need mentioning.

When you make a configuration change, status is not Overridden anymore, but it says Changed, which I think is more understandable.

Features also renamed their primary commands to import (previously revert) and export (previously update). So, instead of writing drush fr and drush fu, we now use drush fim and drush fex. Of course developers of the module were so kind to us that they made alias for previous commands as well, so you can still use them.

Bright future for Features

In conclusion, CMI is great and I think all the developers will use it for deployment. But I also see a bright future for Features module.

We will probably generate some of the features and throw them on Github, so our developers will be able to use them on new pages. It’s also a good way to create features for installation profiles. You can pick features from multiple sites, throw them all in an installation profile and install the site. You will get a new site with various functionalities in no time.