I have recently taken to converting my websites files into ones that work on any path. I am working on using Virtual Hosts to be able to maintain the same .htaccess file as on the main production server. My initialize file that includes all my models is written dynamically to find out the exact system file path and update the website accordingly so I can upload the whole website anywhere.
The trouble lies in the config file. Depending on whether I am on dev or on prod, I connect to a differert database. Therefore I have a small check first to see if I am running a local server. I do this by storing my naming conventions for my dev in an array and by looping through the array to see if the HTTP_HOST matches a value.
Example:
$dev_names = array('localhost','.dev');
However, when I mentioned this on Chat the other day, a respected user told me that he never does this. Instead he has 2 config files and includes the right one at the right time? I didn't get though what was wrong with my approach?
Can you point out to me the flaws in my plan to help me understand the experts?
(PS. For a bonus you can give me a quick run down on how a bootstrap works, heard that word being thrown around, not sure if it is written in PHP or whatever.)
I dont see anything wrong with your approach, and I cannot think of a good reason not to do it.
Personally I do this in my php file;
if ($_SERVER['SERVER_NAME'] == 'localhost')
{
define('ENVIRONMENT', 'development');
}
else
{
define('ENVIRONMENT', 'production');
}
And then all my configs hang off that. Works extremely well - means I literally have zero config changes when moving between Dev & production
I suspect what he was getting at is that your attempt to make your site portable isn't in fact all that portable. If you move it to a new server you'll have to edit your configuration file.
Specifically this becomes an issue when you're checking the config file into some sort of version control system and will be affecting someone else. Ideally, you'll use something like this:
<?php // global config file which is checked into VCS
$SETTING = "FOO";
@include "config/local_settings.php"; // overrides go here
?>
You put all your local setting overrides in the local file, and don't commit it to the VCS. It's perfectly common to commit something like local_settings_example.php though, to give other users a heads-up as to what they need to customise. You can fill it with commented examples if you're feeling generous.
I can only throw in my 2 cents on a setup I prefer. Mainly to avoid undesired version control overwrites or conflicts. To my point of view, it is the server that should decide if it's a production or development server, not a variable in a script that should be changed. An approach like the example below make it even possible to set an environment for an individual on a complete different development setup.
Starting by setting the variable
$_SERVER['SERVER_ADMIN'];
to check for production or development environments. Locally to your own name with a dummy domain like @dev.elop.loc (e.g. dbf@dev.elop.loc) that would never exist for real. A function like so
// environment development check
function __env_dev($check) {
return substr($_SERVER['SERVER_ADMIN'], -(strlen($check))) === $check;
}
// false = production
// true = development
__env_dev("@dev.elop.loc");
can determine the environment. To my experience, production servers always have a SERVER_ADMIN variable set (if not, they really should, even if it has to be the default you@example.com) to a real address, avoiding default you@example.com. If the support for the live server is in your own service/maintenance, it's not a big deal changing it to a real address to distinguish it from a development server ;)