What to do when a WordPress or PHP version reaches end of support
PHP 7.4 hasn’t received any security patch since late November 2022. That doesn’t mean a site still running on it stops working overnight, but that any flaw found since then will never get fixed by the maintainers. The risk grows over time, silently, with no visible alert.
What "end of support" actually means
A PHP or WordPress version reaching end of life keeps working exactly as before: the code runs, pages render, orders go through. Nothing visibly changes on the day support stops. What changes is that from that date, the maintainer stops publishing security patches for that version. Any vulnerability found afterwards stays open indefinitely on installations that haven’t migrated.
PHP 7.4 illustrates this well: no security patch has been published for that version since late November 2022. WordPress technically still runs on PHP 7.4, but WordPress.org’s official recommendation is PHP 8.3 or higher. WordPress core itself remains usable beyond the minimum technically supported version, but staying on an old version deprives the site of the security fixes published for more recent ones.
The danger of this situation lies precisely in its lack of signal. An end-of-life site doesn’t crash, doesn’t show a warning, doesn’t slow down. It keeps working until the day an unpatched flaw gets exploited, at which point the cost of intervention is nowhere near that of a migration planned ahead of time.
How to spot an approaching or already-passed end of life
- PHP version shown in the admin or by the host lower than the version WordPress.org recommends
- Plugins or themes flagging incompatibility with recent PHP versions in their documentation
- A host notice announcing the end of availability of a PHP version on its infrastructure
- No recent security update on a WordPress or PHP version still in place
- No visible incident so far, which is exactly the sign that no check has taken place yet
Planning a move without waiting for an incident
-
Audit the version actually in use
I check the PHP version genuinely active at the host, not the one stated in general documentation: the two can diverge, particularly on older shared hosting.
-
List what blocks a version upgrade
I list plugins and the theme whose compatibility with a more recent PHP version isn’t confirmed, to know what needs updating or replacing before migrating.
-
Plan a test window
I test the version upgrade on a clone of the site before any production switch, with enough margin to fix what breaks without deadline pressure.
-
Schedule the migration before it’s urgent
I set a switch date outside any outage constraint, rather than waiting for a security incident or a host-side cutoff to force a rushed migration.
-
Switch over and monitor
The actual switch to the new version is the moment to watch closely: once the site is live on the new PHP version, reverting to the old one requires a full intervention rather than a simple setting change.
Related pages
-
Updating PHP under WordPress
The technical detail of the version upgrade: deprecated functions, incompatible plugins, testing method before switching.
-
Checking plugin compatibility before an update
How to know what blocks the migration before starting.
-
Duplicating a WordPress site into staging
The method for testing a PHP version upgrade on a copy before production.
-
Choosing e-commerce hosting
What sets apart a host that keeps its PHP versions current from one that doesn’t.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.