getenv and V5

[Racso]

Two questions:

• The docs mention V5, but the repository only seems to contain dotenv up to V4. Is "V5" a planned release, or something that exists in another repository?
• Why will getenv get disabled by default on V5? A lot of people (including myself) think it's preferable to use getenv rather than $_ENV.

Thanks!

[GrahamCampbell]

A lot of people (including myself) think it's preferable to use getenv rather than $_ENV.

Actually, the correct way to access environment variables is $_SERVER. PHP did a terrible job of naming things, and can't change it now because of BC. In particular, getenv and putenv are not threadsafe, so variables can leak between different websites running on the same server on php-fpm! One should avoid getenv.

The docs mention V5, but the repository only seems to contain dotenv up to V4. Is "V5" a planned release, or something that exists in another repository?

Yes, the master branch is for dotenv 5.0, and the 4.1 branch is for dotenv 4.1. There is no stable release of v5 yet. It is likely to happen in the next few weeks.

Why will getenv get disabled by default on V5?

It is actually not disabled by default as such. You have to explicitly choose if you want it or not. If you want it, you can call createUnsafe and if you don't want it, create. The docs for v5 are not quite ready yet, however things should be clear if you look at the source code, I hope. :)

---

I stress this again: getenv and putenv should never be used in threaded apps such as php-fpm deployments. It is not a stylistic choice, it is at worst a security problem and at best, will you will randomly see environment variables being unset when you ask for them with getenv. This is not just a theoretical thread safety issue. It genuinely happens. Laravel users were finding around 2/100 requests to their site where facing this issue!

[Racso]

Thanks a lot for the explanations! They clarify a lot of things.