Configuration management

Drupal stores more than just content in its database; it stores configuration in the database as well. This makes Drupal powerful for users, as they can change how the site functions by simply changing options in the web interface. On the other hand, this causes problems for developers, specifically managing changes to this configuration, as versioning and cherry-picking from a database is difficult.

Note that this is not a huge problem when trying to replicate the production environment, as all is needed is a copy of the database, but it causes much bigger problems when working in teams, and pushing up to production.

Current Approach

Features

Some configurations are tracked using the Features modules. Currently, all content types, their fields, field groups, Views, Contexts, Menus (including Marketplace-related menu links), and Openlayers are under Features control.

Blocks settings can also be controlled by Features (Features Extra module), but only settings provided by Drupal core (page visibility, access permissions, etc.). There are some issues with Blocks weights - absolute values are different per environment; these get manually adjusted with each pull/push, so hope they will be all synced soon (careful).

Description of the specific Features and how to make new ones is at Configuration Features.

Non-managed

Configurations not managed by the features module are handled by documenting the necessary configuration changes, and reproducing them on production or whatever instance it is relevant to. For current deployment of Marketplace, see Deployment for that specific workflow.

Known configuration that is NOT controlled by Features, but could/should be:

• Region block is displayed in for each theme
• 3rd party modules-provided settings, like block classes.
• Custom blocks which don't have machine name entered
• CNR settings
• Theme settings
• Global site settings (site email, name, etc)

Hopefully

There are a couple methods to make this process more manageable.

• Extend the use of Features.
  • Strongarm: allows to export any site variables
• Drupal update hooks: Drupal has built in hooks for managing database migrations. This is a pre-Features approach but is necessary for modules that neither use exportable objects known to Features, or use Drupal variables.
• Drush Make: This manages the necessary parts of a site, such as modules and libraries. In theory we could re-create the site (minus content) with a single command.
• Install profiles: Provides logic when installing a site, so that specific modules are installed and other logic is performed.