views:

198

answers:

3

Hello,

let's say I develop locally and debug small things on live server.

Is it good idea to have something like this in my code? :

$is_local = (strpos($_SERVER['http_host'], 'localhost') !== false);
define ('DEBUG',$is_local);

And then use it through my code, when setting stuff?

$mysql_settings = (DEBUG) ? 
  array(/*localhost settings*/) : 
  array(/*live settings*/);

This way, I can use the same files live and on localhost, so I can sync without any fear of having wrong e.g. connection settings on live server.

Is it good or wrong idea?

+2  A: 

IMHO, what you're doing isn't that bad at all.

The only flaw is on the $is_local line:

$is_local = (strpos($_SERVER['http_host'], 'localhost') !== false);

This could evaluate to TRUE for a site like localhostIsAwesome.com.

Overall, though, the way you are doing it is actually pretty decent.

One other suggestion would be to use $_SERVER[ 'SERVER_NAME' ]

Jacob Relkin
@jacob - from my experience, I can say, that I never worked on ay site containing word "localhost" :). And if I did, I would probably replace that line with something like `$_SERVER['http_host'] === 'localhost'`, or something like that.
Adam Kiss
+1  A: 

it's not a bad idea, if

  1. you have only two environment, local and server
  2. you never have to turn on the debug mode for the server

so it does not address scenario like

  1. multiple environments like dev, test, production
  2. team of more than two developers

A practice I employ on a project is to have settings code files like conf.dev.php, conf.test.php, conf.prod.php for different environment settings, and one file for env switch flag like

$env = 'production';

then you can include file containing the env setings dynamically based on the $env switch, like:

require_once 'conf.'.$env.'.php';

remember to include the conf.dev.php file in git/hg/svn ignore file, so it will not mess up among team members, and conf.production.php in ignore file too for security reason.

just my two cents.

Zhang Yining
I was thinking about that too, the problem is, that I'm trying to come up with fully-automatedsolution, so files on test/dev/live are **exactly** the same, so when I forget to switch it somewhere... it will work.
Adam Kiss
+2  A: 

Nothing at all wrong with doing the way you're doing it.

Another strategy is to set up some environment variable on your development (or other, non-production) system.

Under apache, you could stick something like this:

SetEnv MYAPP_ENVIRONMENT development

in httpd.conf or a suitable .htaccess file

Then in your configuration code:

if (! getenv('MYAPP_ENVIRONMENT')){
  $env = 'production';
}else{
  $env = getenv('MYAPP_ENVIRONMENT"));
}

require_once 'conf/config.' . $env . '.php';

or something along those lines.

timdev
`defined('MYAPP_ENVIRONMENT') || define('MYAPP_ENVIRONMENT', getenv('MYAPP_ENVIRONMENT') ? getenv('MYAPP_ENVIRONMENT') : 'development');` then `if (MYAPP_ENVIRONMENT == 'development')` is the pattern they use in the `index.php` from Zend Framework..
gnarf
Yes, I picked up the pattern from ZF. I think it's safest to assume production unless something explicit is set, however. Further along those lines -- it's probably a good idea to set that environment variable in httpd.conf, and *not* in an .htaccess file -- that way there's less worry about the .htaccess file making it's way into production via version control, rsync, etc.
timdev
This is a great idea - only trouble I see in shared hosting - because if you're on shared hosting, you don't have access to httpd.conf. On the other hand, that can be understood as not defined, thus live.
Adam Kiss
If I actually combine this with my way, I could have `MYAPP_ENVIROMENT` set on localhost or fall back to HTTP_HOST to decide whether I'm on 'dev' (localhost with env), 'test' (resolved 'something' in HTTP_HOST) or 'live' (everything else).Hats off to you, sir.
Adam Kiss
1) on shared hosting just SetEnv in .htaccess 2) Yeah, you could do that.
timdev