Snippets - Little bits of code to make you happy
An alternative to _ss_environment Files for easy 'Per Environment' Configuration
Tweet9 June 2011 | | | Supports v2.4, v2.3
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.
8 Comments
RSS feed for comments on this page RSS feed for all comments
Simon Erkelens
09/06/2011 11:17am (2 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 (2 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 (2 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 (2 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 (2 years ago)
This works a treat. Thanks!
Frank Mullenger
21/06/2011 10:52pm (2 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 (2 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 (1 year 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.