Organizing Features

Features can play an important role in the configuration management of your site, and as the site grows it becomes increasingly critical to decide on a sensible organizational structure for features and stick to it. Otherwise, features can become entangled with one another, creating a messy web of dependencies and overlapping functionalities. This can be especially problematic in projects where several developers are working together.

There are many possible approaches to organizing features. You can create a feature for each content type, or you can create a single feature for all content types. You can create a feature that packages all of your views, or you can combine certain views with the appropriate content types into individual features. The bottom line is that just because you can do something a certain way does not always mean that you should.

This article provides a set of general best practices that are a good idea to follow. These practices include taking a “simple, intuitive, and maintainable” approach to feature creation, avoiding merge conflicts with the VCS, and building natural dependencies while preventing arbitrary dependencies.

Another common method is the “shared dependencies” method. Sometimes features share dependencies such as modules, reusable fields, and permissions. In this case, it can be helpful to identify shared dependencies ahead of time, package these shared dependencies into a separate feature, and make this separate module a dependency of the other features.

As their name suggests, features are meant to provide functionality to support a specific use case- the project page provides such examples as a site blog, a pressroom, a custom image gallery, or an e-commerce t-shirt store. This author recommends a modular approach to building and organizing features, creating features based around major content types or specific sections of the site.

Taking a modular approach entails identifying the desired packages of functionality and creating a feature to support each one. Some features like custom user roles and permissions might be designed for site-wide implementation rather than modularity. In order to decide which features should take a modular approach and which should be implemented site-wide, it’s important to think about the end goal and the purpose of the feature before building it.

Other Best Practices to Consider

Naming conventions: Taking a modular approach to feature development can lead to the creation of many small modules, so adopting a sensible naming convention is important. One good piece of advice is to add a site-specific prefix to your feature’s name, which will help avoid any naming conflicts with contributed modules that might have a similar name.

Folder Structure: Within the modules folder structure, all non-core modules are placed in the ‘sites/all/modules’ directory. It’s good practice to use multiple sub-directories to differentiate between contrib modules (downloaded from the drupal.org/project page) and custom modules. While you might want to have a separate ‘features’ directory within ‘sites/all/modules’, it is often easier and makes just as much sense to place features in the ‘custom’ directory.