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.
 
Thank you for the update. Running plesk repair web -php-handlers does provide further clarification that there's a service plan remaining using the PHP version that's no longer present:

Code:
Checking the usage of PHP handlers


  1 service plans with unregistered PHP handlers were found ......... [ERROR]

Regarding not knowing what the command itself does, it can be easily checked through the command line:

Code:
plesk repair web --help

or through the documentation:


About the synchronization of the service plans I understand your point, however, this is how Plesk was originally designed to work. According to our developers this is expected and documented behavior, hence, is not recognized as a bug. There's an internal case to reevaluate the behavior and I will include your report, but at this point, this not something our team actively considers for implementation.
 
Thank you!

As feedback: running `plesk repair web -php-handlers` worked as a validation check, and selecting a new PHP version did not modify any existing settings. However, there is still something that seems odd.

I have three default Service Plans. Two of them have never been used, and I had already changed their PHP version from 8.3 to 8.5. Only the "Unlimited" plan was still configured to use PHP 8.3. How is it possible that the check still reports that two Service Plans are affected?

# plesk repair web -php-handlers

Checking the usage of PHP handlers

2 service plans with unregistered PHP handlers were found ......... [ERROR]
To see more details, run the command in the verbose mode: plesk repair web -verbose
Use the following PHP handler to fix the issue:
1. [ ] 8.5.6 (FastCGI application)
2. [ ] 8.4.21 (FPM application)
3. [ ] 8.4.21 (Dedicated FPM application)
4. [ ] 7.2.24 (CGI application)
5. [ ] 8.4.21 (FastCGI application)
6. [ ] 8.5.6 (CGI application)
7. [ ] 7.2.24 (FPM application)
8. [ ] 8.4.21 (CGI application)
9. [ ] 8.5.6 (FPM application)
10. [ ] 8.5.6 (Dedicated FPM application)
11. [ ] 7.2.24 (FastCGI application)
12. [ ] 7.2.24 (mod_php)
13. [ ] Disable PHP support
14. [*] Do not fix

Type the number of the necessary option: 9
Applying PHP handler 8.5.6 (FPM application) .................... [FIXED]

Error messages: 1; Warnings: 0; Errors resolved: 1

Error message in PHP Settings is now gone.
 
Back
Top