Skip to content
loading...

re: Building deploy ready PHP apps VIEW POST

FULL DISCUSSION
 

I dislike this approach as it is vulnerable for following situations:

  1. when your application requires CLI commands (such as some CRON-related cleanups) the .htaccess file is unavailable, so the variables will not be correct
  2. when your server hosts more than one application or hosts two instances of the same application (like "test" and "production") setting system-wide environment variables is not accurate

I'd recommend having separate PHP file such as config/environment.php:

<?php
return 'PRODUCTION';

and exclude it from VCS so it will not be distributed over instances of the application. Instead, in VCS provide an example/dummy of that file, like config/example.environment.php:

<?php
// Please copy this file to `environment.php` when you are
// setting application up for the first time.
// Possible values are: `DEVELOPMENT`, `TESTING`, `STAGING`, `PRODUCTION`
return 'DEVELOPMENT';

Then include the config/environment.php in application bootstrap, as soon as possible.

Of course the environment.php file can hold more data, like:

<?php
return [
    'mode' => 'DEVELOPMENT',
    'db_user' => 'foo',
    'db_pass' => 'bar',
    'db_host' => '123.456.789.012',
    'google_account' => 'blahblahblah',
];
 

You are correct on

  1. When your application requires CLI commands (such as some CRON-related cleanups) the .htaccess file is unavailable, so the variables will not be correct

You can run those cli commands if your are not on a shared hosting environment. In the post i have stated that .htaccess is for those with a shared hosting plan (like the godaddy ones).

You wouldn't use .htaccess if you owned the server where the app is deployed. You would go with the second option i have provided. Set the evironnment variables on the system level. That way if your application requires CLI commands the variables would still be correct.

code of conduct - report abuse