• The APS Catalog has been deprecated and removed from all Plesk Obsidian versions.
    Applications already installed from the APS Catalog will continue working. However, Plesk will no longer provide support for APS applications.
  • Please be aware: with the Plesk Obsidian 18.0.78 release, the support for the ngx_pagespeed.so module will be deprecated and removed from the sw-nginx package.

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

ScottGoddard

Basic Pleskian
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:
Code:
[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.)
 
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.
 
@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:

 
Back
Top