[RESOLVED] configuration.php and svn - how to manage local configs versus production configs?

sneakyimp

I'm working on a PHP project with multiple developers and we are using SVN for version control. In this project, the codebase has a configuration.php file which is currently checked into the webroot in our repository. The problem is that each developer needs a different local version of this file, we need one more version for the development server (dev.example.com) and still another for the production site (www.example.com).

I have suggested we remove configuration.php from version control and instead check in configuration-dev.php and configuration-production.php so that we will have the necessary credentials under version control and then we each add an ignore rule for configure.php and create our own local configuration.php as needed.

Has anyone dealt with this situation before? Can you recommend a good approach for dealing with this situation? This seems like it would be a common problem and I expect there might be some standard approach to it.

bradgrafelman

Out of curiosity, what type of things in that file need to be per-user (or per-server) based?

One approach I've used here at work is that such configurations utilize environment variables. Another is to do as you're suggesting - don't put the file in VCS. Perhaps a third option might be to make the file dynamic: have it check for the existence of "configuration.local.php" (which would NOT be in your VCS); use it if it's there, or continue using defaults specified within the main configuration.php file if not.

sneakyimp

This is not a comprehensive list, but these are some of the credentials that are likely to differ between systems:
database access credentials (db, user, password)
payment gateway credentials (e.g., paypal, authorize.net) Not only do we have production credentials and test credentials for www and dev, different devs might have different sandbox credentials they would use for development.
path to web root
path to special libraries and/or directories outside of web root (e.g., place to write sensitive log files which cannot live in the web root)
* domain used to access they website and generate links in emails that get sent, etc.

We've had problems in the past using environment variables. For example, references to $_SERVER["DOCUMENT_ROOT"] may work OK when you are dealing with a script accessed via apache, but it's not a good to reference this path in your include files. When you want to construct a cron job that needs access to your application environment, it won't be defined.

AFAIK, using environment variables probably won't help if you are talking about database credentials or payment gateway credentials.

I've seen the dynamic configuration file approach, but the configuration.php file is part of a framework and if we adjust it, we are deviating from the framework's codebase and will probably have to be extra careful when applying patches -- i.e., it makes the project harder to maintain when you customize it.

Derokorian

I think when bg said to use environment variables he meant at the OS level, which you can then call using [man]getenv/man or [man]$_ENV[/man]. For example, all our instances have a variable called INSTANCE_TYPE and its one of dev, pre-prod, local, or prod, and depending on this value it loads one of config.local config.dev config.preprod or config.prod (simplified for illustrative purposes). We then ignore config.local on our VCS fall back to dev if it doesn't exist.

sneakyimp

Derokorian, that sounds really interesting, but I'm wondering how one goes about setting ENV variables? When I run this via command-line, I get nothing:

$ php -r 'print_r($_ENV);'
Array
(
)

$ENV is also (mostly) empty when I create a trivial file like so:

print_r($_ENV);

It yields just one element:

Array ( [REMOTE_ADDR] => 127.0.0.1 )

I also expect that modifications to our configuration.php to sniff out the $_ENV values will result in a branch from the existing framework -- which means it will be harder to take advantage of any updates publishing by the maintainers.

Derokorian

I'm at my full time employer atm (working in .NET yuck) I will have to check how we take advantage of it when I get home as I don't remember off the top of my head. 🙂

bradgrafelman

sneakyimp;11018989 wrote:
Derokorian, that sounds really interesting, but I'm wondering how one goes about setting ENV variables? When I run this via command-line, I get nothing:
$ php -r 'print_r($_ENV);'
Array
(
)

Try doing:

$ php -d variables_order="EGPCS" -r 'print_r($ENV);'

(In other words, variables_order must include the "E" for PHP to populate that array.)

sneakyimp

bradgrafelman;11018997 wrote:
Try doing:
$ php -d variables_order="EGPCS" -r 'print_r($ENV);'
(In other words, variables_order must include the "E" for PHP to populate that array.)

Yessirree that definitely brought out some results. I recognize a couple from .bashrc so I'm guessing I could set them there when running scripts from the command line. How does one set them for Apache?

bradgrafelman

sneakyimp;11019001 wrote:
How does one set them for Apache?

That depends. Who is running the Apache daemon, and how is it getting kicked off?

The answer you'll probably end up with is that it'd be best/easiest to use Apache's SetEnv in a .conf or .htaccess file.

Derokorian

FWIW I just got home but it appears bg already let you in on the variables order.

sneakyimp

Thanks, guys, for the very helpful information. It's nice to know how enlightened devs deal with things.

As it turns out, we must keep our code tightly synced to that of our framework so we won't be able to alter any config files to branch based on ENV variables. I'm still glad to know how ENV vars can be set and used, though.

To solve our version control issue for my current dev team, we'll be following my original impulse for configuration files: add configuration.php to our ignore list and check in variations of the file that correspond to the shared dev server and production server as configuration-dev.php and configuration-www.php, respectively. This is apparently what is recommended in the Subversion FAQ:
http://subversion.apache.org/faq.html#ignore-commit

Ashley_Sheridan

I know this has already been marked as resolved, but thought I'd add in this, as it's what me and my co-workers do. The config stuff is set within a conditional that can check the domain being requested (any other check could work also). So something like this:

if(strpos($_SERVER['SERVER_NAME'], '.local')
  // local config
if(strpos($_SERVER['SERVER_NAME'], '.dev')
  // dev config
if(strpos($_SERVER['SERVER_NAME'], '.com')
  // live config

It could be tweaked a little to work for you and your team if each member needs a unique config.