LARAVEL_ENV setting overrides local env

[jonphipps]

As committed, the 'LARAVEL_ENV' variable is hardwired in public/index.php to 'staging', overriding the local env setting. Also many of the parameters in application/config/error.php are geared toward a staging or production server.

It would be helpful if there was an example of environment-specific configuration as part of this project. It would also be helpful if the defaults, as committed, conformed to a development environment.

I should say here that I recognize that this is a live project and express my deep appreciation that you chose to share this highly instructive code.

[sparksp]

I think there are three groups of people when it comes to settings:

• those who put their live settings as default, and override for development;
• those who put their development settings as default, and override for live; or
• those whose default settings are not appropriate anywhere and always override them.

Use of environments is covered in the Laravel documentation; but I guess it could be handy to know which settings the project recommends updating for different environments?

[jonphipps]

re: "it could be handy to know which settings the project recommends updating for different environments?"

That's sort of what I was thinking. I assume that laravel-bundles wasn't conceived as the (3.0) tutorial it has been for me, but just following the generally excellent installation and 'getting started' instructions I had a probably unrealistic expectation that this project would conform to them. Instead it used the method I normally use for introspecting the environment. Not that there's anything wrong with that! I was just a bit surprised -- using a host-specific env variable and env-specific config files is simple and elegant like much of laravel.

Most of my reports are related to the fact that I

1. read through the docs start to finish
2. forked and cloned the laravel-bundles repo
3. setup a new virtual host in my local Apache server, docroot at laravel-bundles/public
4. setup a new DB and adjusted the configs
5. Ran the migrations (got errors and fixed them)
6. loaded up the site in Chrome and got four 500 errors

At which point I started tracking down the specific environment settings and making some adjustments so i could see what was causing the 500 errors (write permissions in 'storage/'). Devil is in the details of course.

It was all very instructive but perhaps a bit more painful than it might have been.