• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

PHP Version changed by Plesk on subdomain

netwa

New Pleskian
Hello,

I have following contruct:
primarydomain.de
- PHP 5.4
dev.primarydomain.de
- PHP 5.5

Sometimes, if I change something (not php-related) on primarydomain.de, the php version from this domain is set automatically to the subdomain. THis is not on every change. I don't know which action calls this behavior.

Plesk version 12.5.30 Update #23,

This is for Plesk on Linux, sorry I posted wrong. Maybe someone can move it?

Alex
 
We're seeing similar issues here with Plesk 12.5.30 Update #30 and CentOS 6.7

The specific issues are:

- When we changed the PHP version being used by monocle.[domain1], all other domains and subdomains changed their PHP version in that subscription. (A lot of them, so not something I did accidentally.)
- Second time, we changed php version on [domain2], and the php version and other custom cgi changes on accreditation.[domain2] were auto-set by Plesk to the same.

In both cases, any changes to the individual domain or subdomain afterward apply successfully and do not set the other domains/subdomains in the subscription.

It just seems to be PHP changes that cause this. When we enabled CGI and PERL on accreditation.[domain2], they were not enabled on [domain2], but when we changed to PHP 7 on [domain2], the php version was also changed on accreditation.[domain2] and CGI and PERL were disabled.
 
This issue also occurs when updating a service plan's PHP settings, which is a more serious problem since the owner of the site doesn't even know anything has changed. Steps were:

1. Update service plan's PHP settings defaults such that upload_max_size was changed from 8M to 32M
2. Notice that at next restart any domains that were using PHP-FPM via nginx have now reverted to PHP-FastCGI via apache. (which is the default)

They should definitely be keeping their custom settings.

This caused serious problems for websites that were using custom nginx rules, yet nginx + php-fpm processing was reverted to apache + php-fastcgi

This should really be looked into by devs soon.
 
Hello,

I have following contruct:
primarydomain.de
- PHP 5.4
dev.primarydomain.de
- PHP 5.5

Sometimes, if I change something (not php-related) on primarydomain.de, the php version from this domain is set automatically to the subdomain. THis is not on every change. I don't know which action calls this behavior.

Plesk version 12.5.30 Update #23,

This is for Plesk on Linux, sorry I posted wrong. Maybe someone can move it?

Alex
yes possible, tested already
 
According to https://talk.plesk.com/threads/php-...o-subscriptions-on-update.338309/#post-803130 Plesk does NOT change any PHP settings when the owner of a subscription has permissions to set PHP handler/version himself. However, if the owner of a subscription does not have that permission, changes to the plan can change PHP settings of the subscription.

I'm afraid that's not accurate. The service plan we were updating that affected our clients with this issue already had the "Hosting performance settings management" enabled / checked. So clients can indeed adjust their PHP settings however they wish. Regardless of this setting, a change to say, the memory limit, should not be changing the handler on live domains! It should only be changing that one setting.

This is particularly important because custom nginx settings set by an admin for caching systems like WP Rocket do not function well (or at all) when the PHP handler is set to run through Apache.
 
Back
Top