Throughout a development life-cycle code may move between various environments (e.g. Development -> Integration -> Staging -> Production), however we may not want every environment to have the exact same setup. An example of this might be that on Staging and Production we have CSS / JS aggregation enabled along with caching. On a Development environment we may want both of those disabled. The database connection is also going to be different on each environment.

Some of these configuration settings like the database connection are stored in the sites / default / settings.php file. Aggregation and caching can be configured through the admin UI but they can also be setup in the settings.php file with the $conf variable.  The following is a snippet from the settings.php file.

/**
 * Database settings:
 */
$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'local_drupal',
      'username' => 'local_drupal',
      'password' => 'local_drupal',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => false,
    ),
  ),
);

/** * CSS/JS aggregated file gzip compression: */$conf['css_gzip_compression'] = FALSE;$conf['js_gzip_compression'] = FALSE;

gitignore

Each environment has a unique settings.php file to accommodate the different settings.  If you use a version control system like git, the settings.php file is typically added to the .gitignore file. This works however you now lose any version control over your settings.php file(s).  While not catastrophic, it can be painful if you've heavily modified the settings.php file.

settings.[environment].php

If you want to move your settings.php file(s) into version control we can create a standard settings.php file used across all environments and have that file conditionally include a uniquely named settings.[environment].php file.  The trick is how you identify what environment code is being executed on.

We typically have subdomains setup for each environment. For production the URL would be mysite.com and staging it would be staging.mysite.com.  We can add a small piece of code to the end of the settings.php file to make this check and then look for a correlating settings.[environment].php file.

Here's the snippet of code that we added to the end of settings.php.

/**
* Override default settings.php with settings.[environment].php.
*
* Get the http host and then start removing pieces to eventually end up with
* an environment identifier. The default environment is 'production'.
*
* Examples:
*   mysite.com = production
*   www.mysite.com = production
*   stage.mysite.com = stage
*   local.mysite.com = local
*   local.mysite = local
*/
$host = $_SERVER['HTTP_HOST'];

$subdomain = str_replace('mysite.com', '', $host);
$subdomain = str_replace('mysite', '', $subdomain);
$subdomain = str_replace('www.', '', $subdomain);

$subfile = (strlen($subdomain) >= 1) ? $subdomain : 'production';
$subfile = trim($subfile, '.');

// Prefix configuration variables with 'pre_' to avoid any clashes.
$conf['pre_environment'] = ucfirst($subfile);
$conf['pre_settings_file'] = '/settings.' . $subfile . '.php';

// Check if the file exists prior to including it.
if (file_exists(dirname(__FILE__) . $conf['pre_settings_file'])) {
  include dirname(__FILE__) . $conf['pre_settings_file'];
}

What we're doing here is grabbing the HTTP_HOST and selectively removing parts of it. The remaining piece is then used as the [environment] component of the settings.[enviromment].php file. For example, staging.mysite.com would check to see if settings.staging.php exists, and if so, include it. 

We can now include the various settings file(s) in our git repository.  One caveat is that each developer would have their own unique settings.local.php file and we don't want those to overwrite each other.  So we did add settings.local.php to the .gitignore file and created a sample.settings.local.php file that we add to the repository.

Here's a sample of settings.local.php.

There are definitely other ways to tackle this and hopefully the code samples give you ideas on making your setup more efficient.  Good luck!

• drupal-planet
• tutorials