SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Wizard triexa's Avatar
    Join Date
    Dec 2002
    Location
    Canada
    Posts
    2,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Config for live/dev

    So I have a config.php file that has config variables like paths, username/passwords, db connection info, etc.

    (at least some of) this changes based on live or dev server. So I figure it's easy enough to add an IF condition and define the variables like so, rather than having to maintain two separate copies and worrying about having the wrong version/out of date/overwriting, etc.

    Problem is, I cannot always (obviously?) determine whether I am on dev or live. For example, scripts called through cron/CGI do not have the HTTP_HOST, SERVER_ADDR, etc.

    Any ideas?
    AskItOnline.com - Need answers? Ask it online.
    Create powerful online surveys with ease in minutes!
    Sign up for your FREE account today!
    Follow us on Twitter

  2. #2
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You could have config.dev.php and config.php, using file_exists() to determine which to include.

  3. #3
    SitePoint Wizard cranial-bore's Avatar
    Join Date
    Jan 2002
    Location
    Australia
    Posts
    2,634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm in the same situation. For a long time I used $_SERVER['SERVER_NAME'], in a switch statement. I set the default: option of the switch to configure for the live environment, so that when cron jobs ran live (and server name was missing), it would use the live settings. Problem was I couldn't test or use cron jobs easily once I found a way to run them on Windows.

    So I'm back to maintaining separate config files for each environment and remembering not to overwrite when I upload.

    If you use FileZilla (and probably many other programs) you can create a filter to avoid listing certain files. If your config file rarely changes you could filter it so it won't upload by default. Then just turn the filter off when you do want to overwrite it.

    Or if your dev/live servers are on different a OS you might be able to use PHP_OS to switch between them?

  4. #4
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't have universal solution, but if you want it just working, there are many ways.
    You can compare OS. Or check certain catalog in the file path (__FILE__ constant is very useful). If you don't have $_SERVER, there are always $_ENV to pick some server-specific value

  5. #5
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cranial-bore View Post
    So I'm back to maintaining separate config files for each environment and remembering not to overwrite when I upload.
    Might be missing something here, but if you have a config.dev.php and a config.php you wouldn't need to worry about overwriting, worst case is you upload the dev by accident, but app will crash and it should be fairly obvious why. Of course you have to maintain two sets of data, but that is the point of maintaining two sets of data :P

  6. #6
    SitePoint Member
    Join Date
    Nov 2009
    Location
    Lawrence, KS
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Using the Symfony framework, they deal with "environments" in the bootstrap file. They define the environment to execute under within the bootstrap configuration, and name the file accordingly.

    For example, if you want to access the "backend" of your application using the "dev" environment, you access all functionality through your public_html/backend_dev.php front controller:

    PHP Code:
    // /myproject/web/backend_dev.php
    <?php

    // this check prevents access to debug front controllers that are deployed by accident to production servers.
    // feel free to remove this, extend it or make something more sophisticated.
    if (!in_array(@$_SERVER['REMOTE_ADDR'], array('127.0.0.1''::1')))
    {
      die(
    'You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
    }

    require_once(
    dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

    $configuration ProjectConfiguration::getApplicationConfiguration('backend''dev'true);
    sfContext::createInstance($configuration)->dispatch();
    This explicitly defines your environment based on the file you are accessing, which is much safer than relying on any $_SERVER info.

    It is then your choice how you handle which config to load after establishing your environment to execute under. I would opt for a naming convention with each environment's config in a separate file, but the include call using the environment string to complete the include call, e.g. require_once /path/to/config.'.$environment.'.php';

    You can then publish all environment config files to your production server, and not worry about the application executing outside the production environment by only publishing production-environment front controllers.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •