Question Making site specific PHP Additional Configuration Directives survive subscription synchronization.

[ScottGoddard]

I use PHP Additional Configuration Directives (within the PHP settings page of the site) to set various environment variables that are unique to that site/domain/sub-domain.

As an example, I can use the following to set whether the site is dev, test, or prod, which allows me to keep one code base that behaves correctly for its environment:

[php-fpm-pool-settings]
env[APP_ENV] = prod

I can use this to securely set other site specific variables.

This works great...until you have to sync the subscription - at which point all PHP Additional Configuration Directives are removed. Even just changing the subscription expiry date then requires a resync, resulting in the loss of the environment variables.

I am aware I could set up a custom subscription or an 'add on' to achieve this (as pointed out here: Issue - Additional configuration directives in PHP Settings are overwritten during a service package synchronization) but doing this for every single domain and sub domain this seems ludicrously long winded and complicated way to achieve what should be simple.

Am I missing something obvious? Please don't suggest .env files as these can be a pain and are easily mishandled (yes, I know that `env[APP_ENV]` can also be mishandled and revealed if care is not taken, but I find them more secure, easier to work with, more robust and just all round better.)

 

[Sebahat.hadzhi]

Hi, @ScottGoddard . We have a registered bug identified with ID PPPM-5474 for that behavior. I will consult with our team further on the matter and try to provide an ETA for the fix.

 

[Sebahat.hadzhi]

@ScottGoddard apologies for the delayed response. I got more clarify from our team on this matter and it was determined that this is, in fact, expected behavior and it is very unlikely to be changed. There's a disclaimer in the following documentation:

• PHP Settings

 

[ScottGoddard]

It seems ridiculous that this would be expected behavior.

If that is the case, what is the point of the having this site specific Additional Directives feature at all?

Are the devs suggesting that the subscription should stay permanently locked, if these settings are used? That seems pointless.

Why does it not mention that this will be overwritten in the accompanying label?

Additional directives
You can define any PHP parameters by typing them into the field below. The directives will be included in the PHP configuration. Use the same syntax as you would for php.ini. For example, to automatically load the mSQL extension, add the line: extension=msql.so. To customize PHP-FPM pool settings, add the [php-fpm-pool-settings] separator and type the desired settings below.

I cannot see ANY valid reason for this to be the expected behavior.

Even the disclaimer note you linked to states the settings CAN be lost, not WILL be lost. See below (emphasis added)

Note
Administrator can set additional PHP directives to a particular subscription. In this case, the subscription does not get the Locked status. Therefore, the added directives and other changes in PHP settings can be lost when the subscription is synchronized with the service plan.