-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
env() Helper Post php artisan config:cache #21727
Comments
Yeah this is intended behaviour and not a bug. This repo is for bug tracking so this issue can be closed. If you wish to make any proposal to improve this functionality you can open an issue on the laravel/internals repo |
It seems very odd 'intended behavior' to return null values for variables with values. |
@danjdewhurst yeah.. seems odd. could be a bug, because |
Why not? this is the recommended behaviour since 5.1 as far as I remember |
Closing since it's not a bug, but feel free to ping me or use the forum for discussion |
To my understanding the It works just fine until you cache your configs. Why should caching your configs stop the environment helper from being able to pull values from your environment file? |
because they can give you different values? if you change the |
I think that's the point. When you cache the values, they aren't available at all. This might be by design but it's confusing, and there are pieces of the docs that show env() helper calls in views - such as Cashier placing Stripe credentials in views for the JavaScript. If you can't use env() in a view then it shouldn't be documented as such. It's pretty confusing that caching configs would remove values too - it might be intended but it's extremely unexpected in my opinion. |
After running |
You are supposed to only read environment variables in your config files, and never from any other place. Once you cache the configuration files dotenv will no longer be invoked, the .env file will never be read and the environment variables aren't set. This means that To repeat; You should still be able to read
Source: vlucas/phpdotenv#76 (comment)
Source: https://laravel.com/docs/5.5/configuration#configuration-caching |
Thanks for your comment. I do now fully understand what's going on, I just don't think it's very clear, if anything. And I'd still say it was odd, default behaviour. If you were new to Laravel, and you were trying to pull out environment variables, you may not know about using configs, so you'd probably find yourself using the |
If i'm not mistaken, it is mentioned in the docs to not use |
So it does Still think it's strange. Maybe in the docs for helpers, it should be said that the command should only be used in configuration files? |
The functionality of the helper doesn't change at all when you have a cached configuration, it still reads from environment variables as stated. The information about side effects about a cached configuration should be in the configuration docs. Also, we cannot change the docs for the builtin getenv() that works very similar to the helper function. The helper only adds some type casting for special string values to proper types. |
You can submit a pr to the docs to have it included there as well |
Same scenario @danjdewhurst had, in my case the deployment process is managed by another person: the message on config section is not very clear, and not being on the |
I'm agree with @danjdewhurst confusion. |
Discussion here on the package repo. See this comment by the package author. Maybe it could be made more clear in the docs, but this is just basic php. |
run php artisan config:clear if you don't want to use the config cache |
I'm having a very weird bug here, where sometimes if you reload the page before it has finished loading the env() function doesn't work in a local environment when config files are not cached (executed php artisan config:clear before). Can anyone reproduce that problem? It's a bigger project running on laravel 5.6.7. |
@navadon28 That sounds like something that happens on Apache on Windows. It's a problem where multiple concurrent requests are executed within the same process and share the same environment variables. This will also share environment variables between different sites (main side that calls api site on same Apache installation). The workaround is to either use a cached configuration (and thus not use environment variables), use nginx+fpm, or use another Apache mpm. I'm not sure which mpm or configuration that would be. |
parameters from .env is only read at boot stage - then, configuration files are used. laravel/framework#21727
parameters from .env is only read at boot stage - then, configuration files are used. laravel/framework#21727
parameters from .env is only read at boot stage - then, configuration files are used. laravel/framework#21727
parameters from .env is only read at boot stage - then, configuration files are used. laravel/framework#21727
A small hack for this problem: |
we always should |
Description:
It seems that after running
config:cache
, theenv()
helper is unavailable for use, as it will always return null. Apparently you're just supposed to make sure you only use theenv()
helper from inside your configuration files, but surely this isn't really expected or correct behaviour.The upgrade notes from 5.1 to 5.2 state:
If you are using the config:cache command during deployment, you must make sure that you are only calling the env function from within your configuration files, and not from anywhere else in your application.
If you are calling env from within your application, it is strongly recommended you add proper configuration values to your configuration files and call env from that location instead, allowing you to convert your env calls to config calls.
Steps To Reproduce:
php artisan tinker
.dd(env('YOUR_VAR'));
.php artisan config:cache
.The text was updated successfully, but these errors were encountered: