You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a performance penalty paid for the registration of these arrays and because ENV is not as commonly used as the others, ENV is not recommended on productions servers. You can still get access to the environment variables through getenv() should you need to.
There have been some issues raised because $_ENV["EXAMPLE_SECRET"] isn't working. Since this is very PHP specific, it's commonly assumed that Lagoon isn't passing the variables correctly for some reason. It's not very common, but it does cost time investigating because some users assume that $_ENV is available.
I'm not sure if there is any reason besides the "performance penalty" to keep it disabled? I also can't recall at the moment if $_ENV is typically available in the wider PHP hosting ecosystem? Just grepping the vendor folder of a Drupal project I can see a number of packages that use it.
Options:
Keep the recommended setting. Users should understand how PHP and superglobals work, and getenv() will always work instead of $_ENV.
Enable $_ENV for both fpm and cli images. Assuming that $_ENV is enabled in the wider PHP hosting ecosystem, this puts us in line and provides a better default PHP configuration.
Do nothing, but document it somewhere on docs.lagoon.sh to try and avoid user confusion in the future.
The text was updated successfully, but these errors were encountered:
PHP has a number of superglobals (e.g.,
$_POST
,$_SESSION
, etc) which can be enabled/disabled via configuration.Lagoon ships with the production version of php.ini, which means that the
$_ENV
superglobal is NOT available. From the php.ini coments:There have been some issues raised because
$_ENV["EXAMPLE_SECRET"]
isn't working. Since this is very PHP specific, it's commonly assumed that Lagoon isn't passing the variables correctly for some reason. It's not very common, but it does cost time investigating because some users assume that$_ENV
is available.I'm not sure if there is any reason besides the "performance penalty" to keep it disabled? I also can't recall at the moment if
$_ENV
is typically available in the wider PHP hosting ecosystem? Just grepping thevendor
folder of a Drupal project I can see a number of packages that use it.Options:
getenv()
will always work instead of$_ENV
.$_ENV
for bothfpm
andcli
images. Assuming that$_ENV
is enabled in the wider PHP hosting ecosystem, this puts us in line and provides a better default PHP configuration.The text was updated successfully, but these errors were encountered: