What is the Features module?
The Features module does have a purpose.. But what exactly, do you need it, what is the structure? All valid questions surrounding Drupal’s module. The primary purpose of the module is to copy configuration setups from one Drupal site to another. The Features module offers a well-known method of bundling configuration in a new module that can be installed on other sites–a feature. See the full Drupal 8 configuration setup.
The Features module is an important tool to use on any Drupal 7 or prior projects. To put it simply, Features allows for configurations to be packaged as a reusable component from one environment to another. It might seem like a hassle to add yet another module to your development process, but you will find Features very handy and rewarding as your site grows in size.
Do I need it?
The main advantage of using Features is being able to have configurations in code so it can be tracked under version control. Since everything in Drupal 7 is stored in the database, configurations changes such as Content Types or Views needs to be moved upstream some way. Creating those changes manually is not such a big issue when your site is small and there’s only one developer working on it. However, when there are several developers working at once on a large scaled site, having to manually create config changes on all the environments is extremely inefficient and time consuming not to mention the possibility of human error. Using Features decreases the amount of inconsistencies across the board. By having configurations in files, the deployment process is also simplified.
Features Structural Organization
There are many different ways to organize the components within Features. You can categorize them based on the kind of Drupal entities (Views, Content Types, Blocks, etc). The downside to that is you might end up with a very long list of Features that makes it hard to keep track of, or Features that are not broken down specific enough and resulting in merge conflicts every time changes occur. One approach is to group feature around Content Types and Pages. It’s much easier to identify what Feature to export if you know that a certain Block for staffs will be under the staff profile Content Type. There may also be components that does not necessarily fit into one place. For example, fields that are used in several different Content Types can be moved to a feature for shared components.
Other Tips
Make sure to revert Features once your code has been pushed up. Also, you should go and double check everything is at the state you want. I have encountered times when Features did not import something properly even though all the correct components were selected. It is also wise to name your features with something identifiable to your project as the base name and place them all in a Features folder in modules for easy access.
Drupal 8 comes with content management system in core so there won’t be a need for Features in the future. However, Drupal 7 is here to stay for awhile and it is definitely an essential module for development.
