• 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.

Not used PHP versions removed, but Plesk reports missing versions

Azurel

Silver Pleskian
Username:

TITLE

Not used PHP versions removed, but Plesk reports missing versions

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.78 Update #3
AlmaLinux 8.10

PROBLEM DESCRIPTION

I uninstalled PHP 8.2 and PHP 8.3 because no domains on this server were using those PHP versions anymore.

However, under PHP Settings I now get the following warning:
Error: The following PHP version(s) are not installed: 8.3.31, 8.2.31. Install them or run plesk repair web -php-handlers to select another PHP version.
I'm not quite sure what ‘plesk repair web -php-handlers’ does here, or even what it changes.

After some investigation, I noticed that at least PHP 8.3 was still configured in one of my "Service Plan"s. For the plans "Default Domain" and "Default Simple", I could simply change the PHP version to PHP 8.5 and save the plan with "OK".

1. The problem is the "Unlimited" service plan. Plesk wants me to synchronize the plan with all subscriptions. I do not want to do that, and I assume I should not do it either, because the subscriptions may have individual PHP settings that differ from the service plan. Why is it not possible to simply save the service plan with a new default PHP version for future subscriptions only, similar to how unused settings can be changed without forcing a synchronization?

2. Also, how can I determine where PHP 8.2 is still being referenced? The warning correctly tells me that PHP 8.2.31 is still configured somewhere, but it does not provide any information about where to look. It would be very helpful if the error message included additional details, such as which service plan, subscription, or configuration is still referencing the removed PHP version.

Am I missing something, or is there a recommended way to identify these remaining references before removing old PHP versions?

STEPS TO REPRODUCE

See description

ACTUAL RESULT

See description

EXPECTED RESULT

1. Better error message.
2. The option to save the service plan without synchronisation, for future subscriptions.

ANY ADDITIONAL INFORMATION

I see this as a bug, as it seems to me that synchronisation overrides the PHP settings of the domains concerned, or even changes their mode (FPM application / Dedicated FPM application).

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Hi, @Azurel . How did you remove the mentioned PHP versions?

For PHP 8.3 I can confirm it is still used by Roundcube. When you attempt to remove the PHP version through the Plesk GUI you are prompted with the following message:

The following components depend on the components you are going to remove or conflict with components you are going to install:

Roundcube

I am unaware of a component that still uses PHP 8.2. However, if there are websites depending on the uninstalled PHP version, I am being prompted with the message shown on the screenshot and under PHP Settings I see the following message:

The following PHP version(s) are not installed: 8.2.31. PHP scripting for 1 domain(s) is unavailable. Install the missing PHP versions or follow the instructions from the KB article to repair PHP scripting.

If I manually change the PHP version of the subscription, the error matches the one reported by you, so I would assume that there are no websites that actually depend on the mentioned version - only the service plan.

EXPECTED RESULT

1. Better error message.
2. The option to save the service plan without synchronisation, for future subscriptions.

Regarding point 1, I am positive that will not qualify as a bug, but a feature request. Still, I will double-check with our team.
Regarding point 2, we already have previous reports. The matter was reviewed by our team. It has been qualified as expected behavior and consequently as a feature request:

I would recommend considering submitting a new idea on features.plesk.com about it.
 

Attachments

  • Screenshot 2026-06-01 162804.png
    Screenshot 2026-06-01 162804.png
    267.7 KB · Views: 2
How did you remove the mentioned PHP versions?
with "Add or Remove Components" => /installer/select_components.html

In my case, Roundcube is not installed, and no domain has been using PHP 8.2 or PHP 8.3 for a long time, as both PHP versions were disabled previously with 0 domains left. Only Service Plan with "Unlimited" use PHP 8.3. The reason for PHP 8.2 is unknown.
1780324835611.png
1780325792773.png

To summarize, there is an error message, but no clear way to resolve it because it is unclear what triggers the error in the first place. How can this not be considered a bug?

Yes, perhaps running plesk repair web -php-handlers would resolve the issue. However, I could not find any detailed explanation of what exactly this command does or which settings it may modify. From my perspective, it is essentially a black box. I am reluctant to run a repair command without understanding its impact, as I want to avoid introducing unexpected configuration changes on a production system.

======

Why is point 2 considered only a feature request? From my perspective, the current behavior can break existing configurations. If a domain is created with a specific setting (that include defaults as it is), that setting becomes part of the domain configuration and should be preserved. A forced synchronization from the service plan can overwrite these settings unexpectedly.

I would expect a way to save changes without triggering a synchronization. As far as I can tell, the required functionality already exists internally, the only missing part seems to be an option or button that allows saving changes while skipping the sync process. For this reason, I believe this is more than just a feature request; it affects configuration consistency and can lead to unintended changes.
 
Back
Top