Features for Drupal 8

A great session by Mike Potter (maintainer of Features module) in Drupal Con Barcelona on the role of features in Drupal 8.

Mike started his session with a quote that set the tone for the whole session:

“Who has wasted more than 1000 hours with feature module”

Gone

Problem Solved

A famous core developer regarding CMI in drupal 8

 I have personally encountered such experiences with features. Some of the scary examples I can recall are:

• There is one feature for the complete site configuration. When it comes to update, you never know what configurations will remain intact after reverting your features.
• Client makes frequent changes which get overrides with dev feature update.
• Poor feature architecture leading to feature conflict.

The one reason I see behind these issues is that we forget why feature module was ever created.

   Feature is not meant to help your deployment process across different instances.

Feature was developed to cover the important aspect to get configuration in code. It is the thoughtful picking of configurations, not random ones to get the maximum in the code.

 As a thumb rule, I follow few things to make my features clean

1. See your feature as any other module, turning it on and off should toggle a specific functionality on the site, which makes feature clean and independent.
2. Less is More. I keep only those configurations which are not supposed to be changed by client and only those which I have configured. Example, for a content type if I have not configured commenting system, there is no point to get the default configuration in code.

In Drupal Camp Hyderabad I ended my session with half cooked answer on the question Role of Feature in Drupal. Well now we have full-fledged answer by the feature module maintainer himself.

Here is my take away from the session.

Before we reach to conclusion role of feature in D8, let’s try to understand Role of features irrespective of Drupal version.

Why Features:-

• Features help us in getting configurations in the code, and hence allow them under version management, which helps you in tracking if there is a configuration change.
• For the reason that configuration are part of the code, it automatically makes the deployment process.
• Features help in bundle up functionalities and allow them to reuse. An example would be an image gallery. We build a content type for image gallery, an image style, a view and some other checkbox configurations. Building a feature to hold all these will allow you to reuse them on different projects.

But Drupal 7 Features were trying to do what code is not intended for.

• That is PHP code holding configurations, so at times configurations are complex views object, nested arrays which are ideally not supposed to handle by php. But Features was the only way out till then.

Then comes Configuration Management Drupal8 initiative to the rescue.

How:

• Configurations and content are now decoupled.
•  They introduced use of .yml files which is widely used way of storing configurations outside Drupal world.
•  .yml files have built in import and export functionality.
•  And now no more modules are allowed to alter configuration via hooks, which in times of Drupal 7 was an issue. It means there is no chance that you install a module and can alter existing configuration.

So the catch is that features module is extending configuration management system, and allows to pull configuration in .yml files.

Let's see the comparison between Features and Drupal 8

Let's see why bundling up configuration is not easy with just CMI

• Going back to our image gallery feature example, if we need one standalone module like feature with CMI we would have Copy/Paste following files in module configuration folder.

             my-content-type.yml file.

             my-fields.storage.yml file.

             my-image-style.yml file.

             my-image-view.yml file.

• For any site builder, it’s not an easy and a quick way to find the needed files and bundle them in a custom module.
• Any update to configuration once module installed is a cumbersome process. It will require module to implement hook_update to tell drupal there is a configuration change suggestion by a module, only just changing configuration files will not reflect the changes.
• Uninstalling a module does not remove all configurations of that module, which is to take care of the fact that uninstalling a module should not cause your data loss. But problem comes when you try to re-install a module which has some configuration left over after un-installation. In that Drupal will not allow you to install that module. So a module which is not a feature would not be able to install if it tries to override existing configuration. Features module has extended the CM system to tell drupal if it's a feature. Let it get installed, irrespective of configuration match.
• On that ground, we still need Features in Drupal 8 to re-use/ bundle configuration targeting a specific functionality.

Changes in Features in Drupal 8

• Architecture change of import/export of configuration. Now features extend core configuration system to get configuration in .yml files.
• Features has introduced assignment plugin for auto packaging.

 Few examples of autoplugin 

             - Existing:- This plugin suggests what configurations are supposed to go in existing features.

             - Base Type:- You can define base type of features, so a feature can be built around a content type which includes content type configuration, field setting, views built around that content type or you can define base type as views so to have a feature holding all views.

• You can categorise your feature under bundles. So there can be a bundle having all the features which are build around content types and there can be features under another bundle built over views.
• Bundle also help in namespace for your features. So they do not conflict by modules.
• Features UI can be disabled by just turning off features UI module.
• Drush 7 support.
• Changes in terminology

Drush Commands for Features in Drupal 8

drush fd  <feature_name> 

• See difference in configuration

drush fim <feature_name>

• Import a feature which override configurations as per current feature .yml files.

drush fex <feature_name>

• Export a feature which update feature .yml files with the current configurations

drush fc

• List components that can be added to a feature.

drush fa <feature_name> <feature_component_name>

Add mentioned component to given feature module.