In short: The safest way to disable old PHP versions is in three phases: identify usage, block the version and observe, and only then uninstall. In Plesk, a handler can first be deactivated so that it can no longer be selected, and later removed under Updates and Components. Every version you remove is one less that you have to patch and restart at the next vulnerability like PHP2Shell.
Why clean up right now?
The week after PHP2Shell showed many admins how many PHP versions are installed on their servers. Each of them had to be checked, each needed an update or interim measures, each service a restart. For PHP 8.1 and older there are only minimal source backports, and support for PHP 8.2 ends on 31 December 2026.
With this experience fresh in mind, now is the right moment to clean up. How to find all installations in the first place is described in the article Multiple PHP versions on one server. This article covers the next step: controlled shutdown.
Phase 1: Identify usage
Before you switch anything off, you need to know who uses a version. Websites are the obvious part. Less visible are subdomains, test installations, cron jobs, scripts and panel components.
In Plesk, the command plesk bin php_handler --list lists all registered handlers. With --get-usage, according to the documentation, Plesk shows which domains use a particular handler. Neither command changes anything.
# Plesk: all handlers and the domains that use a handler
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# General: cron jobs that call a specific PHP version
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Also check the access logs of the websites concerned: a test installation that has not received a request for months is a candidate for removal, not for migration. For each old version, note who uses it and why.
Also ask the people who work with the websites. Editorial teams, agencies and departments often know processes that appear on no list: the annual export for accounting, the form for a trade fair, the interface to the merchandise management system. Whatever depends on an old version there is otherwise noticed only when it is missing.
Phase 2: Block and observe
The intermediate step prevents a version from being newly assigned without deleting it right away. In Plesk, individual handlers can be deactivated for this purpose. According to the Plesk documentation, a deactivated handler can no longer be selected in a website's PHP settings; the version stays installed. On the command line, this is done with plesk bin php_handler --disable -id <handler-id>.
Domains that still use the old version are first switched to a supported version, in coordination with those responsible. How this looks from the website operator's point of view is described in the article Changing the PHP version in the hosting customer area. Choosing the right handler is explained in the article Plesk: understanding PHP handlers.
During the observation period, watch for error messages in the logs, missing cron job results and feedback from users. In other panels the functions have different names; check the vendor documentation there.
Set the end of the observation period as a date and name who approves the uninstallation afterward. Otherwise the intermediate step becomes a permanent state, and the old version stays on the server after all.
Phase 3: Uninstall
Only when the observation period has passed without incident do you remove the version completely. In Plesk, according to the documentation, this is done under Tools & Settings, Updates, Add/Remove Components, in the Web hosting area at the PHP interpreter versions. Installed versions are marked there and can be selected for removal.
On servers without a panel, the package manager does this job. Back up the version's configuration beforehand, for example /etc/php/7.4/ on Debian and Ubuntu, so that in an emergency you can trace which settings applied.
# Back up configuration, then remove packages of one branch (example Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
A check is worthwhile after removal. In Plesk, the documentation recommends plesk bin php_handler --reread to re-read handler information after changes to PHP binaries. Also check whether service plans still point to the removed version.
Typical stumbling blocks
| Stumbling block | How to recognize it | What helps |
|---|---|---|
| Panel component depends on the version | The panel reports a dependency on removal | Switch the component first or keep the version |
| Service plan points to the old version | New websites get the old version or an error message | Adjust the plan, then remove the version |
| Cron job calls a fixed path | Script fails after removal | Change the path to a supported version |
| Application does not run on the new version | Error in the error log after switching | Update or migrate the application |
If an application cannot be moved to a supported version, switching off the old version is no longer a configuration matter but a migration project. The risks of outdated branches are described in the guide PHP end of life: risks of outdated versions.
The next candidate is already set
Cleaning up is not a one-off action. On 31 December 2026, PHP 8.2 drops out of support by the PHP project. Anyone removing versions up to 8.1 now should decide in the same step what happens with 8.2. Otherwise the same game starts over in a few weeks.
A simple rule for the server has proven itself: only branches that the PHP project supports are offered. When set up, each branch gets a date on which it is reviewed again, based on the end of support on php.net. Background on this cycle is explained on the page PHP versions and release cycle.
Hosters or agencies with customers on the server should inform them early. An announcement with a date, a request to switch and an offer of support prevent websites from failing on the deadline. Customers whose application does not keep up thus recognize in time that an update or migration is due, and can plan for it.
How does PHP SOS help?
- We determine which websites, cron jobs and panel components use which PHP version.
- In coordination with you, we switch domains to supported versions and block old handlers.
- After the observation period, we remove old versions in a controlled way and check the result.
- Where applications do not keep up, we plan the migration from PHP 8.1 and older.
Frequently asked questions
Why should I remove unused PHP versions?
Every installed version must be checked, updated and restarted with every vulnerability. Old branches such as PHP 8.1 and older no longer receive updates from the PHP project. Unused versions bring only risk and effort.
What is the difference between disabling and uninstalling?
When you disable a version, it stays installed but can no longer be newly selected. When you uninstall it, it is removed from the server. Disabling is the safe intermediate step to see whether anything is missing.
Can removing a PHP version disturb panel functions?
Yes. Some components of a panel, such as webmail or administration tools, depend on a particular PHP version. Clarify such dependencies before removing; the panel usually points them out.
How long should the observation period last?
Long enough that all regular processes have run at least once, including monthly cron jobs and exports. Set the duration together with the departments involved.