Forwarded to devs PHP micro update removes individual subscription php ini settings

[Bitpalast]

TITLE:

PHP micro update removes individual subscription php ini settings​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

CentOS 7.3, Onyx 17.5.3, latest MU, 64-Bit​

PROBLEM DESCRIPTION:

With MU #17 the individual PHP INI settings for PHP 7.0 were reset to the subscripton template settings (service plan settings). An additional setting
max_input_vars = 10000
was removed. The customer's shop went offline due to it, because the number of max_input_vars was now the "low" default fo 1000 again.​

STEPS TO REPRODUCE:

Update PHP 7.0.21 to 7.0.22 by MU #17.​

ACTUAL RESULT:

Additional PHP ini directives that are not part of the subscription template (service plan) are removed.​

EXPECTED RESULT:

Keep all individual PHP ini directives.​

ANY ADDITIONAL INFORMATION:

​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[IgorG]

From developer:

Need clarification, where exactly additional directives were set.
If it is "additional PHP directives" set via Plesk, they are located in <vhost_root>/system/<domain>/etc/php.ini, and can not be affected by installation scripts of PHP 7.0.22 package.
This behavior can not be reproduced in the test environment also.
The most probable reason for this is the synchronization with the Service Plan or web server reconfiguration, e.g. using httpdmng or phpinimng.

 

[Bitpalast]

Tab "Websites & Domains" -> Icon "PHP" -> Section "Additional configuration directives".
There was no web server reconfiguration done, only the update was auto installed during the nightly maintenance window. The "additonal configuration directives" were replaced by the subscription's default.

 

[IgorG]

In this case the additional directives are stored in the "PhpSettingsCustom" table of 'psa' database. And the database also can not be affected by the micro-update, since mysql was not updated recently.
I suggest to look for the "Update domain template" records in Plesk action log (Tools&Settings > Action Log) since the service plan synchronization is still the most probable reason for the mentioned issue.