You are here

Drupal 7 - Workflow improvement for settings.php

Error message

  • Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; views_display has a deprecated constructor in require_once() (line 3047 of /homepages/3/d267786686/htdocs/pangus/includes/
  • Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; views_many_to_one_helper has a deprecated constructor in require_once() (line 113 of /homepages/3/d267786686/htdocs/pangus/sites/all/modules/contrib/ctools/ctools.module).

Handling the multiple copies of Drupal's settings.php file needed for each site, between the development, staging, and live environments, can be a bit of a hassle. Database settings and other configurations almost always vary from environment to environment so having a simple way to manage these differences would be fantastic. Always on the look out for work-flow improvements, I had heard about this gem at DrupalCon Denver in March but had yet to implement it in any of my projects. Based on a discussion at I came across recently, the fire to get this improvement implemented was rekindled. The user chrisjlee posted a link to a great example which, with one modification, I am now using in all my Drupal projects.

The Method

Let's assume you are setting up a Drupal install for the first time. After you've got the installation setup in your development environment, make a copy of the settings.php file and name the copy local.settings.php. Crack open the settings.php file and go to the very bottom. After the very last line of code add the following snippet:

 * Settings.php file routing
# Localhost
if (file_exists(dirname(__FILE__) . '/local.settings.php')) {
  include dirname(__FILE__) . '/local.settings.php';
# Staging
if (file_exists(dirname(__FILE__) . '/staging.settings.php')) {
  include dirname(__FILE__) . '/staging.settings.php';

What this does is include an alternate settings file, if it exists, to over-write the existing set of settings. So you store the configurations needed for the live environment in settings.php and your development environment configurations go in local.settings.php. When your new site is ready for testing in the staging environment, simply exclude the local.settings.php file from the staging site and create a new staging.settings.php file to store the staging server's settings. Exclude both files from the live environment and you're golden.

The Benefits

There are really three main benefits that I can see:

  1. Forgetfulness factor eliminated – If you aren't using an automated method of building your sites to various environments, you no longer have to worry about accidentally over-writing the live site's configurations when copying files manually.
  2. Makes it easier for multiple developers to work on a site at the same time – Each developer can maintain their own copy of local.settings.php.
  3. Easier to maintain site in version control – Settings for the development and staging environments aren't usually needed once a project has finished development. By excluding the local.settings.php and staging.settings.php files from version control you only store the settings that matter.

Even if you've already got a site up a running in the wild you can still apply this technique the next time you sit down to work on it. Definitely makes life easier.