env() Helper Post php artisan config:cache

[danjdewhurst]

• Laravel Version: >5.2.0
• PHP Version: N/A
• Database Driver & Version: N/A

Description:

It seems that after running config:cache, the env() helper is unavailable for use, as it will always return null. Apparently you're just supposed to make sure you only use the env() 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:

1. Create an env variable.
2. Run php artisan tinker.
3. Run dd(env('YOUR_VAR'));.
4. You should see your variable.
5. Now exit artisan tinker.
6. Run php artisan config:cache.
7. Re-do steps 2-3.

[Dylan-DPC-zz]

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

[danjdewhurst]

It seems very odd 'intended behavior' to return null values for variables with values.

[lkmadushan]

@danjdewhurst yeah.. seems odd. could be a bug, because env helper working fine with fascgi_params after config:cache but not for the variables in .env file. by the way as per the documentation it's better to use it within your config file until you have to work with dynamic environment variables.

[themsaid]

but surely this isn't really expected or correct behaviour

Why not? this is the recommended behaviour since 5.1 as far as I remember

[themsaid]

Closing since it's not a bug, but feel free to ping me or use the forum for discussion

[danjdewhurst]

To my understanding the env() helper doesn't even touch the cache? I really don't see how this isn't an issue.

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?

[Dylan-DPC-zz]

because they can give you different values? if you change the .env the changes won't be reflected in the cached version?

[mikemike]

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.

[danjdewhurst]

because they can give you different values? if you change the .env the changes won't be reflected in the cached version?

@Dylan-DPC

After running php artisan config:cache, I'm unable to pull out any values using env(). That's the issue.

[sisve]

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 env() (and getenv()) will not find the values you are attempting to read.

To repeat; env() DOES NOT read from .env, it's a helper for getenv() which reads proces-wide environment variables.

You should still be able to read env('PATH'), an environment variable you should already have without the dotenv or .env stuff.

ONLY use env inside your config files, and then you MUST use the cache command to setup the config files. Then there are ZERO env issues in production.

Source: vlucas/phpdotenv#76 (comment)

If you execute the config:cache command during your deployment process, you should be sure that you are only calling the env function from within your configuration files.

Source: https://laravel.com/docs/5.5/configuration#configuration-caching

[danjdewhurst]

@sisve

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 env() helper. That's all well and good until you cache the config and that helper now just returns null values.

[Dylan-DPC-zz]

If i'm not mistaken, it is mentioned in the docs to not use env. If a new dev doesn't read the docs,he can't blame the framework 😛

[danjdewhurst]

So it does
https://laravel.com/docs/5.5/configuration#configuration-caching

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?

https://laravel.com/docs/5.5/helpers#method-env

[sisve]

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.

[Dylan-DPC-zz]

You can submit a pr to the docs to have it included there as well

[IlCallo]

Maybe in the docs for helpers, it should be said that the command should only be used in configuration files?

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 env() description I didn't know either. In my case, the bug was due to SocialiteProviders trying to read from env files (in their documentation is encouraged to use only env variables, I'll signal this to them too).
I'll try a PR to the docs soon

[antongorodezkiy]

I'm agree with @danjdewhurst confusion.
Wow. This is the first thing in Laravel which seems totally illogical for me.

[devcircus]

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.

[vcats]

run php artisan config:clear if you don't want to use the config cache
else use run php artisan config:cache

[yannick-roeder]

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.

[sisve]

@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.

[SpinyMan]

A small hack for this problem:
https://stackoverflow.com/a/70871023/9731538

[materialsmoke]

we always should config function not env function. and in the config file we should get the value from env file with env() function.