Support dynamic values for domain local php.ini in subscriptions
I suggest adding support for dynamic values like %domainname% in the subscription php settings. This allows admins to keep domain subscriptions in sync when needing domain specific php values that can be easily generated by Plesk.
Why add this to Plesk panel instead of the current domain template files? Domain template files are hard to handle and only work for php values when using php as an apache module. Moving a bunch of these dynamic values into the subscription php management allows administrators to apply values to php as CGI, Fast-CGI, PHP FPM and apache module without loosing sync with the subscription.
Because lets face it: how many people still run php as an apache module since Plesk 11.5 and currently in Plesk 12?
I basically want the same customisation features for PHP through cgi, fast-cgi and PHP FPM as PHP as an Apache module currently has through Plesk's domain templates. I'll explain my reasoning for this feature below:
I use New Relic PHP monitoring to monitor all subscriptions separately. This allows me to view errors and loads on a per domain basis. To use this function I need to add a simple php value on a per domain basis that identifies the PHP for that domain to New Relic.
If you're running PHP as an apache module you can modify the domain templates inside Plesk to use the domain name as identifier for that php value, allowing you to dynamically populate php values on a per domain basis.
When running CGI, Fast-CGI or PHP-FPM you need to address the local php.ini for that domain. Plesk manages the local php.ini through the panel, which works great for these kind of php values, but has two deal breaking flaws:
- Does not support dynamic values (something like php_value = %domainname%).
- Disables subscription syncing in the panel for that domain.
I would love to see the ability to (dynamically) add values to the local php.ini while keeping the subscription synced by gaining access to dynamic values in the php settings on a subscription level.
Unfortunately, we have to close your request, because over the years it has not become quite popular for further implementation.
—
IG