12

I installed fresh Laravel 5 copy.

My detectEnvironment function is defined this way:

$app->detectEnvironment(function() { return 'local'; return getenv('APP_ENV') ?: 'production'; });

In config\local I've created database.php file:

<?php return [ 'nothing' => 'new', ];

I run php artisan clear-compiled.

My index method of WelcomeController is defined this way:

public function index(Application $app) { echo $app->environment(); var_dump($app['config']['database']); //echo $app['config']['database']; return view('welcome'); }

Application was imported this way: use Illuminate\Foundation\Application;

The result I get is:

local array(1) { ["nothing"]=> string(3) "new" }

whereas I would expect Laravel to cascade config file with production one (with the default config\database.php file.

The strange thing is that even if I comment the line return 'local'; run again php artisan clear-compiled it shows:

production array(1) { ["nothing"]=> string(3) "new" }

so it seems it always loads database.php file content (this one from local folder) and overrides main database.php file. It works fine again when I change this file name to for example aaa.php.

Is it a bug or maybe environment configuration shouldn't be stored inside config directory? But if not, where should they be store? I don't know if it's a bug or a feature so if anyone knows more about it, please give me a clue.

Improve this question

4 Answers 4

Reset to default
13

Although in documentation for Laravel dev (5.0) there is info that configuration will cascade it's not true. I have tested it about 2 weeks ago and it seems at the moment the only way to have different values for environments is using ENV file where you put custom values for current environment. Putting settings in directories won't work as it used to work however it's possible it will change or maybe has been already changed for last 2 weeks.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

7

There's a package that brings the cascading config system back to Laravel 5.

Disclaimer: I am the author.

Improve this answer

6 Comments

Thank you. L5 is env handling is step backwards in my opinion. The point of specifying an "environment" is to be able to load correct settings for that environment without having to resort to a bunch of conditionals to....wait for it.....determine what environment I'm running in. L4 was much better in this respect - I'm "local" - OK then load the "local" configs. That's the only conditional I need.
I am totally agreed with ekeyser. This is really step backwards. Also the removed caching in the query builder is the same. And lots of other stuff. Flash messages also.
I've been using Laravel since v3. This v5 config setup is insane. It solves a handful of guys use cases at the expense of everybody else.
@An Phan I'm not a big fan of the config.envName approach, my app is deployed on 3 servers :) Why not have envName folders inside the config folder?
@junkystu Because that will trigger a fatal error by Laravel.
|
3

For me it looks like defect in Laravel 5 dev branch. I was able to work around by adding manual environment detection and configuration. This code does it.

'default' => $app->environment()=='testing'?'sqlite':'mysql',
Improve this answer

1 Comment

Quick tip: using $app->environment(testing') is similar to $app->environment()=='testing'
0

It is easy to configure Laravel 5 environment.

  1. Open your root application folder and find ".env.example",
  2. Copy and rename into ".env",
  3. Please fit ".env" file into your environment,
  4. If you use GIT, make sure you don't push this file to your GIT repository. For 'complete explanation', I write this configuration here.

Edited;

I quote from the developer in His github repository readme.md file;

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.

So, you need to create ".env" file per machine and don't use ".env" file in your production server.

Improve this answer

5 Comments

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes.
Edited my answer. I copied some of important note from my blog. But... why someone give me (-1) ? :(
I didn't give you the downvote so I can't be sure, but I think you probably got it because this doesn't actually answer the question. The question is "What's wrong with my configuration?" and your answer says "Do this to change your configuration...". It's related, but misses the point of the question. Look at the accepted answer and see how much more to the point it is, regarding the specific question.
A step backwards in my opinion. The point of specifying an "environment" is to be able to load correct settings for that environment without having to resort to a bunch of conditionals to....wait for it.....determine what environment I'm running in. L4 was much better in this respect - I'm "local" - OK load the "local" configs. That's the only conditional I need.
"It is easy to configure Laravel 5 environment." This is why you are being downvoted. I used to be able to set everything in my repository. Now I'm supposed to manually manage a bunch of stupid .env files outside of my repository, and I'm told this is somehow easier.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.