Skip to content Skip to navigation

Hard vs soft configuration: Designing your distribution

In this article we are going to talk about what hard and soft configuration is and how to decide between the two when creating a distribution.

At Stanford Web Services we have several products, or Drupal distributions, and we build them with contributed modules, installation profilesFeatures, and custom modules. When we design a product we have to make decisions on what should never change and what can, or will, change but should have a sensible default when the site is initially installed.

If you are a developer or site builder and are working with or creating a distribution, please read on.

What is hard vs. soft config?

  • Hard configuration are settings that should never change throughout the lifetime of the website. 
  • Soft configuration are settings that can change or be removed but provide a sensible default or starting point. 

The what

Using ordering a Classic Club sandwich off the menu at Quiznos as an example, we can say the sandwich is the product. The sandwich has hard configuration on what types of protein it comes with (ham, turkey, & bacon), and soft configuration on what types of toppings are included. Quiznos suggests that you should eat the Classic Club with cheddar cheese, tomatoes, lettuce, and mayo. As an end user you may not like tomatoes and would rather have olives and mustard added to the sandwich. 

Much like Quiznos, when we are designing our products we have to decide what things an adminstrator, or user can change, and what they cannot. For those items that a user can change we should provide them with an out of the box set of options that appeal to the majority of users. An example of hard configuration in our products would be our WYSIWYG and text formats configuration. We have established a set of options and formats that should be consistent throughout all of our products. An example of soft configuration would be user roles and permissions. We provide default out of the box configuration that makes sense for most websites, but administrators may want to change which content types their staff have access to and which they do not. 

The how

Ok, great. So now you understand what hard vs. soft configuration is, how do you get them into your product? Your first guess may be Features and you are right. Features is great for packaging up settings and putting them into code. Settings in code is a great way to store hard configuration. But wait, you can override features through the user interface. Shouldn't hard configuration be something that never changes? You are right again, hard configuration should be set in stone, so when working with Features you have to be very careful to not allow administrator users access to the sections where they may change your hard configuration. The good thing about Features is that if the configuration ever does change you can quickly revert back to the original state using Feature's revert functionality. Another way you can write hard configuration is directly into your custom modules. You may use custom modules to hard code items like, content types, entities,  and views.

If Features is good for hard configuration is it also good for soft configuration? The answer for this will differ based on who you ask but our opinion is not really. The answer depends on the development workflow or site building practices in use. Features can be overridden through the UI and therefore, has the ability to provide sensible defaults that users can change. If your site building practices include re-exporting and keeping the Feature modules up to date with the latest changes you may use them effectively and efficiently. When designing a distribution we have to keep in mind that not everyone will keep Features up to date when building out their website. We also do not want to pigeonhole our site builders into this process or to force them to try and abstract the parts of the feature they want to disable. A better option for soft configuration would be to write some input once only code. This would be code that is either in an installation profile install task, or in a custom module's hook_install(). By putting the soft configuration into one of these two areas we can safely provide out of the box settings that are usable and changeable by site administrators. If the site administrator decides later they want to put their new changes into a Feature they may without running into conflicts with other features. 

Kit compliance  is important for creating re-usable features and does a good job at determining the items that can, or should, go into a feature and which items that should not. Those items that should not are a good example of something that can be configured as soft configuration. For example, Kit compliance allows for user roles and permissions that are directly related to the feature itself, but does not allow for roles or permissions established by some other contributed modules. If you wanted to set the permissions that are not directly related to your feature you may do so in an installation profile install task. This task will run once during the installation of the site. By setting permissions in an installation task you lose the ability to revert the configuration through features, but you gain flexibility in that you can change this setting later without worry.

Please check out these resources for more information on how to create a distribution: