• Halloween is coming! To celebrate the occasion, we dusted off a couple of old skins, and even created a brand new one (Pixel).
    To get into the festive spirit, install the Skins extension.
  • The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • The Plesk Mobile apps for iOS and Android and the Plesk Mobile Center extension have been deprecated, and are no longer available for new installations. In Plesk Obsidian 18.0.84, the Plesk Mobile Center extension will be removed from servers during the upgrade, and the Plesk Mobile apps will lose their server management features.
  • The Social Login extension has been deprecated and will be removed in Plesk Obsidian 18.0.84. After that, it will no longer be possible to log in to Plesk with a Google, Facebook, GitHub account, or with a passkey. Plesk usernames and passwords, as well as logging in with a WebPros Account, are not affected.

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