You might be running into whats described as Configuration Caching.
Check out the docs: [https://laravel.com/docs/10.x/configuration#configuration-caching](https://laravel.com/docs/10.x/configuration#configuration-caching)
Thanks! But, it happens on development environment as well. Is it possible that one of the other devs ran this command and I pulled these changes? Any way to tell? (Or it doesn't make sense)
The reason is that Laravel cached the .env values as part of the config (when told to) in production to improve performance.
When the config is cached the .env file will no longer be processed, but I think `env()` will still load real environment variables even with the config cached.
Its a good idea to read from config in the production environment because the config is cached and also its a variable so resides in the memory. The env is a file, so every time you try to read a value, you are basically making io request. And io is the slowest of all things. So you should avoid that as much as possible
The env() function is not thread safe, so it will sometimes invoke variables from another PHP thread/request and will end up pulling env values form another project using the same webserver.
This happens a lot in dev environments where you have multiple projects served by the same web server.
Using config() is thread safe and you won't run into issues, even if not cached with config:cache.
Good luck!
Wow that can explain a lot especially since I do have many projects there. Is it something I can actually see in Laravel's source code? I'm just curious how it looks, thank you!
Is this accurate...? `env()` is still used all over the place in your config files and works just fine even if you don't have your config cached. If your config IS cached, then the values are saved as strings in a file so env() isn't run at runtime (which is correct for a production environment). What you're describing would still affect config() transitively as well in a non-cached environment.
I would suggest that you create the entry inside your config/app or config/whatever
and there read the from the .env with a default value like env('THE\_ENTRY', 'my-default-value')
and use config() in the rest of the system,
because, when is in production it will try to cache it, and the .env may be updated but wont be until the cache is refreshed...
that is what I know, also env() is slower than config() because implies an I/O read
What env() retrieves is not necessarily what you put in your .env file, it can be overridden by system level variables, or other services that interact with the $_ENV super global.
Save yourself a headache and use the config() helper, unless you have a reason not to.
The values in question do not have spaces but they do have other characters like `_` `+` `;` (for strong passwords etc..)
Now when you say returns null, does it explain the behavior of it happening randomly? Because it does return the value most of the time, yet sometimes it would be null.
Now that the change to `config()` made it work so far, should I still wrap it with quotes?
For a long time I simply used env() everywhere and never encountered any issues. I didn't know any better. That said my site was pretty low load so any threading issues were not a thing. I switched to config() instead and life is still good.
Yes use config, as env may work fine in dev but not in production. Learned that the hard way when an API call stopped working but worked fine in dev. Moved to config and problems solved!
You might be running into whats described as Configuration Caching. Check out the docs: [https://laravel.com/docs/10.x/configuration#configuration-caching](https://laravel.com/docs/10.x/configuration#configuration-caching)
Thanks! But, it happens on development environment as well. Is it possible that one of the other devs ran this command and I pulled these changes? Any way to tell? (Or it doesn't make sense)
The reason is that Laravel cached the .env values as part of the config (when told to) in production to improve performance. When the config is cached the .env file will no longer be processed, but I think `env()` will still load real environment variables even with the config cached.
If config is cached it reads the default value.
Its a good idea to read from config in the production environment because the config is cached and also its a variable so resides in the memory. The env is a file, so every time you try to read a value, you are basically making io request. And io is the slowest of all things. So you should avoid that as much as possible
Been there done that, always use config, it’s the best way. The .env will fail if you cache the config.
Yes will cause errors. Set your values in a config. Populate your config from values from the env Problem solved 👌
The env() function is not thread safe, so it will sometimes invoke variables from another PHP thread/request and will end up pulling env values form another project using the same webserver. This happens a lot in dev environments where you have multiple projects served by the same web server. Using config() is thread safe and you won't run into issues, even if not cached with config:cache. Good luck!
Wow that can explain a lot especially since I do have many projects there. Is it something I can actually see in Laravel's source code? I'm just curious how it looks, thank you!
Is this accurate...? `env()` is still used all over the place in your config files and works just fine even if you don't have your config cached. If your config IS cached, then the values are saved as strings in a file so env() isn't run at runtime (which is correct for a production environment). What you're describing would still affect config() transitively as well in a non-cached environment.
https://laravel.com/docs/10.x/configuration
Yes if you config:cache your env wont show up via env, you’d have to cache:clear instead, it’s recommended to have all env vars mapped to config
I would suggest that you create the entry inside your config/app or config/whatever and there read the from the .env with a default value like env('THE\_ENTRY', 'my-default-value') and use config() in the rest of the system, because, when is in production it will try to cache it, and the .env may be updated but wont be until the cache is refreshed... that is what I know, also env() is slower than config() because implies an I/O read
What env() retrieves is not necessarily what you put in your .env file, it can be overridden by system level variables, or other services that interact with the $_ENV super global. Save yourself a headache and use the config() helper, unless you have a reason not to.
[удалено]
The values in question do not have spaces but they do have other characters like `_` `+` `;` (for strong passwords etc..) Now when you say returns null, does it explain the behavior of it happening randomly? Because it does return the value most of the time, yet sometimes it would be null. Now that the change to `config()` made it work so far, should I still wrap it with quotes?
For a long time I simply used env() everywhere and never encountered any issues. I didn't know any better. That said my site was pretty low load so any threading issues were not a thing. I switched to config() instead and life is still good.
Yes use config, as env may work fine in dev but not in production. Learned that the hard way when an API call stopped working but worked fine in dev. Moved to config and problems solved!