in version 4.x it was possible to run Laravel without having to change any config files, it would automatically detect if it runs local or in production mode.
With Laravel 5.x it seems I have to take the following approach:
On my local machine a .env file in the root directory with "APP_ENV=local" and other config stuff to run locally
On my server the same thing with "APP_ENV=production" and the related settings
So if I deploy my site, I have to watch that I don't overwrite the .env file on the server with my local version.
Is this all correct or am I missing something there?
This seems like a step back from the 4.x approach where I could have everything configured and done, no need to have two different files with the same name and watch that I don't mix them up or something.
Your .env file is listed in the gitignore file by default. So you should be fine.
If you are "copy and pasting" the entire folder over then it might be a problem.
Hard coded in the various config files.
https://github.com/vlucas/phpdotenv
Edit:
phpdotenv is made for development environments, and generally should not be used in production.
OP: yes you must have multiple env files as these contain your crucial data. Just set it up first time and you usually don't have to care about it anymore as long as you ignore it from git.
@jlrdw Yes, like I said in my first post: How do I handle the different environments. What would be the solution to keep all the config data out of version control if they are hard coded all over multiple files?
@EmilMoe Actually @jldrw is not wrong. Having an .env file creates an massive overhead, every setting has to be looked up. The creator recommends to avoid using it in production. So who knows how @TaylorOtwell thinks this is supposed to be done.
I am getting the feeling that this .env approach is the wrong decision to handle this issue. It would be much better just to have a .php file with two arrays that contain the data for production and development. This way it would be extremely fast and could be kept out of version control.
Maybe @JeffreyWay can say if it has an impact on his performance at Laracasts.com if he uses .env files. That would be an relevant example to measure against.
phpdotenv is made for development environments, and generally should not be used in production. In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request. This can be achieved via an automated deployment process with tools like Vagrant, chef, or Puppet, or can be set manually with cloud hosts like Pagodabox and Heroku.
I haven't actually bothered with this as the performance impact is minimal but the recommended way is to set actual environment variables in your virtual hosts. This can be a pain without some sort of automated tool though. Easiest solution might be to use forge.