php.ini: set variables_order to EGPCS

[verfriemelt-dot-org]

heyho,

during development i encountered some issues with $_ENV and cli scripts invoked like this:

$ CONFIG_TARGET=qa composer symlinks

which was odd, because on my debian box this worked fine but on a macos install via homebrew it was not working. we noticed that variables_order was set to GPCS and thus ommitting the $_ENV superglobal i required to have the CONFIG_TARGET set.

after some digging around, i found the formular for php on homebrew with its source for the default configuration:

https://github.com/Homebrew/homebrew-core/blob/56299f3dac37eaf9fe0b1e187b889f559a74be26/Formula/php.rb#L219

    config_files = {
      "php.ini-development"   => "php.ini",
      "php.ini-production"    => "php.ini-production",
      "sapi/fpm/php-fpm.conf" => "php-fpm.conf",
      "sapi/fpm/www.conf"     => "php-fpm.d/www.conf",
    }

the default for the variables_order is defined as ECPGS in the documentation but both the php.ini-production and php.ini-development had those set to GPCS which contradicts the docs.

the current dockerhub image also uses EGPCS as a sane default

$ docker run --pull=always -it --rm php php -i 2>/dev/null | grep variables_order
variables_order => EGPCS => EGPCS

so i figured the right thing to do is to update both php.ini files according to the documentation.

[cmb69]

There is a comment in the ini files:

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.

So it makes sense to me to not include E.

If you still want to change it, please target the "master" branch, and send email to the internals mailing list for discussion.

[verfriemelt-dot-org]

👍 i sent a mail to the mailing list to discuss this. lets see.
i wonder if the performance impact is still relevant?

[cmb69]

i wonder if the performance impact is still relevant?

If not, we should remove that comment. :)

By the way, I'm not pressing "approve and run", since this change wouldn't be checked anyway. The commit message could have been started with [ci skip].

[verfriemelt-dot-org]

which php.ini is used for the tests? i noticed, that some tests override this setting to include E ?

[cmb69]

which php.ini is used for the tests?

That depends on the environment; I don't think our CI uses any particular php.ini files (except for AppVeyor, but that only declares some extensions, and a few OPcache related settings).

[ramsey]

because ENV is not as commonly used as the others

This is a strange part of the comment, and I doubt this is the case anymore, since we build applications differently that we did 13 years ago. It's now a common practice to inject ENV vars into your application instead of using local config files for production. Additionally, getenv() and putenv() are not thread safe, so they're discouraged against by libraries such as vlucas/phpdotenv.

[krakjoe]

I have changed the target and updated the comments to more honestly reflect reality.

This looks like a reasonable change to make to me, if no objections are raised in the next few days I'll merge into master only.

[TimWolla]

if no objections are raised in the next few days I'll merge into master only.

This needs RM approval as per: https://externals.io/message/128453

[TimWolla]

Similarly these lines should be removed.

[krakjoe]

Other close by and related settings declare here their defaults, ini and production values, so it seems fine to follow that pattern.

[TimWolla]

They only do that when any of them differ from the built-in default.

[krakjoe]

if no objections are raised in the next few days I'll merge into master only.

This needs RM approval as per: https://externals.io/message/128453

No it does not, the feature freeze has no impact on bug fixes. This is a bug fix, the original issue stated the documentation and code were out of alignment, aligning them cannot be considered a feature under normal circumstances.

[TimWolla]

This is a bug fix, the original issue stated the documentation and code were out of alignment

They were not. The built-in default is EGPCS and that is also what the documentation correctly indicates. What differs is the values in the example php.ini files and that also clearly was documented inside of them.

This is changing the behavior for anyone who uses the supplied php.ini-production config as the basis for their own configuration (e.g. Linux distros) and therefore is a feature.

[krakjoe]

This is a bug fix, the original issue stated the documentation and code were out of alignment

They were not. The built-in default is EGPCS and that is also what the documentation correctly indicates. What differs is the values in the example php.ini files and that also clearly was documented inside of them.

This is changing the behavior for anyone who uses the supplied php.ini-production config as the basis for their own configuration (e.g. Linux distros) and therefore is a feature.

Example ini files occupy a strange space, somewhere between documentation and code, but not really either documentation or code. Whatever fixing them so they correctly reflect documentation and internal defaults is, it cannot be a feature, nothing is added.

[TimWolla]

if no objections are raised in the next few days I'll merge into master only.

I am hereby formally objecting to the merge of this PR and given the previous description of:

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.

I am requesting an RFC to discuss whether this performance penalty still exists, still is relevant, and if ENV should continue not to be recommended on production servers.