DrupalDork.com was shut down on September 18, 2013. This is just a snapshot of the site as it appeared then.

Local Settings for Development Sites

Today I'd like to share a technique that we use on every site at Jackson River.

For most projects, we have multiple developers working on different aspects of the site, and each of us has our own local development setup and checkout of the git repository. The problem we ran into, as any Drupal shop will, is the site configuration details included in settings.php, and the way that those need to differ on our various development, staging, and production sites.

On some early sites, we used a switch statement in settings.php that would check the requested URL, and set variables like $db_url depending on that. When a new developer joined the project, they would add a new condition to the settings for whatever URL they were using (we each had our own local naming scheme, whether it was jacksonriver.com, jacksonriver.local, jr.dev, jrdev.local, and so on).

This was a terrible solution, and we stopped using it a long time ago. Instead, on every site we build, the settings file ends with an include:

@include('local.settings.php');

The @ at the beginning of the line ensures that PHP will not throw an error if the file does exist (details). This way, we can include it in the settings.php file that's committed to git—and used on the server—without it causing any errors, despite the fact that no local.settings.php file will be found on the production server.

Our git repositories are alwyas set to ignore the local.settings.php file. That way, each of us has our own copy with our own database credentials and other settings, and no one accidentally commits it.

There are a few other settings that I always include in mine. This is what a typical local.settings.php looks like on my machine:

$db_url = 'mysqli://root:rootpass@localhost/client_db_name';

// Make sure I can always run update.php
$update_free_access = true;

// Some sites use memcache, which overrides the cache include file from the core
// Since I don't have memcache running on my machine, I override it back to the
// default, and test caching on the staging server
$conf['cache_inc'] = './includes/cache.inc';

// Make sure I see all the errors I want to
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

I've found this technique so handy that I regularly add the local settings include on freelance clients as well.

Category:

Comments

Nice solution - we've adopted exactly the same approach (after a number of not-as-elegant solutions, including case statements for picking site details based on the URL used - this showed its failings when we first starting using drush a couple years back) - works a treat. Thanks for publishing these sorts of tips - I'm sure it'll help many avoid those standard traps for young players.

Thanks for the feedback!

Was in the dark about this kind of set up... now crystal clear.

Thanks for blogging this :) I am currently the only developer on a couple of Drupal projects, so I just use the regular multisite functionality to get different settings.php files, but I see how this solution comes in handy in a team. Bookmarked for future use :)

Add new comment