SSbits - Home page
Site by Carbon Crayon
Submit a Post >

Snippets - Little bits of code to make you happy

An alternative to _ss_environment Files for easy 'Per Environment' Configuration

Although Silverstripe has a mechanism for alternative configuration per environment, using the ConfigureFromEnv() method in your mysite/_config.php file, it has its limitations and I have often read people complaining about it. Here is a simple yet powerful alternative to using SilverStripe environment files.

You can read more about the 'Official' method here: http://doc.silverstripe.org/sapphire/en/topics/environment-management.

Instead of using that method, I have found it useful to add the following line to the bottom of /mysite/_config.php file instead:

@include '_live-config.php';

This attempts to include the _live-settings.php file and fails silently if it is not there.  In the development environment we just ignore this file and everything is configured as normal in the _config.php file.

On the live machine we add this new file to mysite/ and in it we can override any of the settings in the standard _config.php file.  In particular you can do things like provide live database connection values, override the mailer and email addresses, modify caching and so on. Your _live-config.php might look something like this:

<?php
 
$databaseConfig = array(
    "type" => "MySQLDatabase",
    "server" => "localhost", 
    "username" => "username", 
    "password" => "Password", 
    "database" => "database_live",
);
 
Security::setDefaultAdmin('admin','ABetterPassword');

This method gives us a very simple but highly expressive environment specific configuration.  What is more, since we don't have any of the live database settings in our _config.php we don't have to worry about storing it in a configuration management system like Subversion or Git since our sensitive data is only stored on the live server.

  • Simon Erkelens
    09/06/2011 11:17am (3 years ago)

    Since it happens often, the dev (or more often, somebody else, we devs only do good things), overwrite's the _config with the database information, I've taken on the habit of adding the live-config in a comment.

    On my live site, if I accidentally overwrite the database-settings somehow, I just uncomment it from the config, in stead of panicking where to find the db-info again.

    Your solution is better though :)

  • John Learn
    09/06/2011 12:52pm (3 years ago)

    I like this a lot. It's a lot cleaner than my solution. Normally, I use a conditional based on the hostname to switch configurations, e.g:

    if (preg_match('/www\\.logicbrush\\.com$/', $_SERVER['HTTP_HOST']) != 0) {
    // production configuration
    } else if (preg_match('/staging\\.logicbrush\\.com$/', $_SERVER['HTTP_HOST']) != 0) {
    // staging configuration
    } else {
    // development configuration
    }

    but that does expose the production db information to the developers (and it's a bit muddy). Still, it does give me the flexibility to maintain multiple configuration types (prod, stage, dev). I'm also not sure that keeping configuration files in subversion is actually a bad idea. I mitigate that somewhat by managing my deployments with beanstalk so the devs never need to know the FTP details.

  • Pete Bacon Darwin
    09/06/2011 1:07pm (3 years ago)

    I would be interested to know what you put in these different configurations that would benefit from being version controlled. I only put stuff related to the deployment, such as DB connection and email servers.

    These things don't tend to change unless you change host, in which case the previous versions are unlikely to be important.

    If you really wanted you could keep a selection of deployment files such as _live-config.php, _test-config.php, _stage-config.php, which you can version control. In your _config.php you have a line like @include '_local-config.php'. Then you can upload all the files to all the environments, remembering to do a rename fo the relevant file for each environment if it has changed.

  • moloko_man
    09/06/2011 4:54pm (3 years ago)

    I was also doing what Simon was doing, but I really like your solution, I've already implemented it and loving it. Thanks.

    I also added my Director::set_environment_type("dev") into each of those files so I can easily switch between dev, testing and live modes.

  • Shea
    12/06/2011 11:51pm (3 years ago)

    This works a treat. Thanks!

  • Frank Mullenger
    21/06/2011 10:52pm (3 years ago)

    Nice method, I like its simplicity! @John Learn you can also use Director::set_dev_servers() instead of preg_match()

  • Todd
    07/09/2011 6:05pm (3 years ago)

    This is a great approach! I was working to set up something similar, but my solution was more complicated. I love the elegant simplicity of this. Clever!

  • Nobrainer Web
    19/01/2012 3:17pm (2 years ago)

    Very simple and very elegant solution, i will start using this as soon as i get my local dev machine up and running again :o)
    Thanks

Post a comment ...

You cannot post comments until you have logged in. Login Here.

Advertisement

Site of the Month

Find SSbits on

Top Contributers

Rank Avatar Name
1 article image Aram Balakjian
2 article image Daniel Hensby
3 article image Marcus Dalgren
4 article image Hamish Campbell
5 article image Ty Barho
6 article image njorndare
7 article image Martijn van Nieuwenhoven
8 article image Darren-Lee
9 article image Roman Schmid
10 article image Matt Clegg

View full leaderboard


Advertisement