Skip to content

[Dotenv] getenv return false instead of the value in the file .env #53461

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

Closed
makraz opened this issue Jan 8, 2024 · 10 comments
Closed

[Dotenv] getenv return false instead of the value in the file .env #53461

makraz opened this issue Jan 8, 2024 · 10 comments

Comments

@makraz
Copy link
Contributor

makraz commented Jan 8, 2024

Symfony version(s) affected

6.4.2

Description

after migrating a Symfony project from 6.3.* to 6.4.2 I discovered that the function getenv always return false instead of the value in the file .env
also, I was able to have the same behavior with a new project (Symfony 6.4.2)

How to reproduce

Create a new project Symfony 6.4.2
create a function in a controller that call dd(getenv('APP_ENV')); for example
Observe the results (screenshot)
image

Possible Solution

No response

Additional Context

tested in below PHP versions:

PHP 8.3.1 (cli) (built: Dec 20 2023 12:44:38) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.1, Copyright (c) Zend Technologies
with Zend OPcache v8.3.1, Copyright (c), by Zend Technologies


/usr/src/app # php --version
Cannot load Xdebug - it was already loaded
PHP 8.2.7 (cli) (built: Jun 15 2023 01:00:47) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.7, Copyright (c) Zend Technologies
with Zend OPcache v8.2.7, Copyright (c), by Zend Technologies
with Xdebug v3.2.1, Copyright (c) 2002-2023, by Derick Rethans

@stof
Copy link
Member

stof commented Jan 8, 2024

See

/**
* @param bool $usePutenv If `putenv()` should be used to define environment variables or not.
* Beware that `putenv()` is not thread safe, that's why it's not enabled by default
*
* @return $this
*/
public function usePutenv(bool $usePutenv = true): static
{
$this->usePutenv = $usePutenv;
return $this;
}

@xabbuh
Copy link
Member

xabbuh commented Jan 9, 2024

closing as explained

@xabbuh xabbuh closed this as not planned Won't fix, can't repro, duplicate, stale Jan 9, 2024
@makraz
Copy link
Contributor Author

makraz commented Jan 9, 2024

thank you @stof, my question is that the change was in the version 5.0.0, however, we didn't observe this behavior in Symfony 6.3, so I'm wondering if I've missed something or if I still don't fully understand it.
if the change was introduced in Symfony 6.4., wouldn't it be considered a BC breaking change? If so, wouldn't it have been more appropriate to include it in Symfony 7. instead of 6.4?"

thank you

CC: @derrabus @xabbuh

@derrabus
Copy link
Member

derrabus commented Jan 9, 2024

The behavior change happened with #31957 in 5.0.0.

Can you produce a reproducer app for your issue, where we can observe the change of behavior you've described?

@xabbuh
Copy link
Member

xabbuh commented Jan 9, 2024

@makraz Did you by chance also update the recipes so that you now have other bootstrapping code in the front controller than you had before?

@makraz
Copy link
Contributor Author

makraz commented Jan 9, 2024

Yes, I updated the recipes, and all looks good in this part. I will share a reproducer app for the issue with more context 👌🏻

@xabbuh
Copy link
Member

xabbuh commented Jan 9, 2024

Can you share how your index.php file looked before you updated and how it is now?

@makraz
Copy link
Contributor Author

makraz commented Jan 9, 2024

Before (Symfony 6.3.2)

<?php

use App\Kernel;
use Symfony\Component\ErrorHandler\Debug;
use Symfony\Component\HttpFoundation\Request;

require dirname(__DIR__).'/config/bootstrap.php';

if ($_SERVER['APP_DEBUG']) {
    umask(0000);

    Debug::enable();
}

if ($trustedProxies = $_SERVER['TRUSTED_PROXIES'] ?? false) {
    Request::setTrustedProxies(explode(',', $trustedProxies), Request::HEADER_X_FORWARDED_FOR | Request::HEADER_X_FORWARDED_PORT | Request::HEADER_X_FORWARDED_PROTO);
}

if ($trustedHosts = $_SERVER['TRUSTED_HOSTS'] ?? false) {
    Request::setTrustedHosts([$trustedHosts]);
}

$kernel = new Kernel($_SERVER['APP_ENV'], (bool) $_SERVER['APP_DEBUG']);
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);

Now (Symfony 6.4.2)

<?php

use App\Kernel;

require_once dirname(__DIR__).'/vendor/autoload_runtime.php';

return function (array $context) {
    return new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']);
};

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Jan 9, 2024

That's why: recipes are opt-in piece of code that are on your side of responsibility: you don't have to adopt their updates, and adopting them means possibly changing some behavior (as in: reconfiguring some defaults of your app).
Closing therefor.

@makraz
Copy link
Contributor Author

makraz commented Jan 9, 2024

thank you all 🙏🏼
I'm guessing that the last time we updated Symfony to 5.X or 6.X, we didn't update the recipes 😅, but now I updated them too.

Before:

"symfony/framework-bundle": {
        "version": "4.4",

After:

    "symfony/framework-bundle": {
        "version": "6.4",

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants