Sometimes, my project can't get some configuration!

[wpjCode]

framework：YII2
php version：5.6
phpdotenv version：2.6

detail：
Sometimes, my project can't get some configuration!Return 'false'! Not every time！
Please Help Me!

[wpjCode]

My Code:
(new \Dotenv\Dotenv(dirname(DIR), '/.env'))->load();
$setting = [
'class' => 'yii\redis\Connection',
'hostname' => getenv('REDIS_HOST'),
'port' => getenv('REDIS_PORT'),
'database' => getenv('REDIS_DB')
];

I'm get：
[
'class' => 'yii\redis\Connection',
'hostname' => false,
'port' => false,
'database' => false,
]

[GrahamCampbell]

This is a known limitation of getenv: it doesn't work on multi-threaded environments (you will see that on a small number of requests, those calls return false), like php-fpm. You should replace all calls to getenv('REDIS_HOST') with $_SERVER['REDIS_HOST'] ?? false if you want to mimic exactly what getenv does.

[GrahamCampbell]

It's unfortunate that PHP has named things the way it is, but $_SERVER is the only place people should ever be looking for environment variables. getenv should never be used.

[wpjCode]

Oh, My god,,,Thank you, you mean is: use $_SERVER['xxxx'] is OK?

[GrahamCampbell]

Yes. Those global constants are thread safe.

[Bhoft]

Why was this issue closed and there still isn't anything mentioned in the readme?

@GrahamCampbell this isn't correct as in the RepositoryBuilder::defaultAdapters() you still use the PutenvAdapter.
And therefore use getenv() and putenv() are used in a normal load() with the code @wpj130 has posted. which could cause that also $_SERVER and $_ENV aren't set!

private static function defaultAdapters()
{
    return self::filterByAvailability([
        new ApacheAdapter(),
        new EnvConstAdapter(),
        new ServerConstAdapter(),
        new PutenvAdapter(),
    ]);
}

If the PutenvAdapter is disabled it is like you mentioned.
Or if you add your own readers + writers as you have in your example code https://github.com/vlucas/phpdotenv#immutability-and-repository-customization

Example of working code for $_SERVER and $_ENV:

$repository = Dotenv\Repository\RepositoryBuilder::create()
->withReaders([
    new Dotenv\Repository\Adapter\EnvConstAdapter(),
    new Dotenv\Repository\Adapter\ServerConstAdapter(),
    new Dotenv\Repository\Adapter\ArrayAdapter(),
])
->withWriters([
    new Dotenv\Repository\Adapter\EnvConstAdapter(),
    new Dotenv\Repository\Adapter\ServerConstAdapter(),
    new Dotenv\Repository\Adapter\ArrayAdapter(),
])
->immutable()
->make();

$dotenv = Dotenv\Dotenv::create($repository, __DIR__);
$environmentVariables = $dotenv->load();

But by default you add this PutenvAdapter, perhaps its better to remove it completely and only use $_ENV / $_SERVER.

Btw also Symfony Dotenv Classes are mentioning this in their code
Beware that 'putenv()' is not thread safe, that's why this setting defaults to false
https://github.com/symfony/symfony/blob/5.0/src/Symfony/Component/Dotenv/Dotenv.php#L42

don't check existence with getenv() because of thread safety issues
https://github.com/symfony/symfony/blob/5.0/src/Symfony/Component/Dotenv/Dotenv.php#L134

[GrahamCampbell]

Yeh, I am thinking about changing the defaults in v5, but there will be massive community backlash, and people may just mindlessly fork the project rather than fixing their code.

[GrahamCampbell]

This is pretty much what happened when I tried to change the defaults in laravel/framework.

[wpjCode]

@Bhoft
I use the latest version. Is OK.
index.php code:
Dotenv\Dotenv::createMutable(dirname(__DIR__), '.env')->load();
Use code:
$_SERVER['DB_DSN']

[GrahamCampbell]

The latest vesion still uses getenv and putenv under the hood though, by default. For example, we use getenv (as a fallback) when looking to resolve nested environment variables.

[Bhoft]

The only problem is the PutenvAdapter which is sadly enabled as default.
If you change your code that is only possible to enable by adding it manually to the reader / writer you are save.

Perhaps you could just mention that it could cause problems and is not thread safe.

You can't fix it if the users doesn't update their code or forks.
But at least for your repository you could fix this easily for the default and warn them to not use getenv() any more.

They will read the documentation if problems occur :)

@wpj130 depending of your amount of variables you read from your .env files.
I have created a script for myself to check the behaviour and i could have the possibility that $_SERVER / $_ENV isn't filled even if the file is loaded and i haven't used getenv() in my code.

Just create some index.php which redirects to itself and stops if the value isn't loaded.
open multiple tabs to the same file and you will get the result that it isn't safe.

[GrahamCampbell]

I'll have a think how I can achieve good defaults without making people not want to use the library. ;)

[Bhoft]

i have created my samples
some index.php
https://gist.github.com/Bhoft/8d3b22155a38f2ca624312b1a96e4369
and the .env file i used
https://gist.github.com/Bhoft/7cd50a4e072cb404e05d8c7acdacb85d

test=1 will use the code given from immutability-and-repository-customization
test=2 will use createImmutable
test=3 will use createMutable
test=4 the code from above which didn't use putenvadapter

then just call index.php?test=1 and call the same on several tabs.

At least on my Windows Wamp (apache 2.4.41, php 7.3.15 thread safe) this produces problems.
It`s also strange that always the same variables from the top aren't available in getenv().

[wpjCode]

@Bhoft
Sorry I haven't a advice...Because, We use this in some 'config file'! Can't use function get some configuration