Available for projects & agency overflow · Quick reply, from the person who does the work

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.

Describe my issue Send a message

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

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

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

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

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

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

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

origine
catalogue
extensions-premium (facultatif)
conserver (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

My site still runs on PHP 7.4 and works fine, do I really need to migrate?
Yes, even if nothing breaks today. Since late November 2022, no flaw found on PHP 7.4 gets fixed. Current functioning says nothing about the accumulated security risk.
Which PHP version does WordPress recommend today?
WordPress.org officially recommends PHP 8.3 or higher, even though WordPress core technically remains compatible with older versions.
How do I know if my host already offers a recent PHP version?
I check the active version in the hosting control panel or via a WordPress diagnostic plugin, rather than trusting the general documentation for the plan subscribed to, which can differ from the version actually provisioned.
Should I wait for a plugin to flag an incompatibility before acting?
No, that’s exactly the opposite of the goal: waiting for the incident means losing the room to manoeuvre that planning ahead provides. The audit happens before the problem arises.
Does WordPress itself reach end of life the same way PHP does?
The principle is similar: beyond a certain version, security patches stop. The difference is that WordPress publishes security updates on older major branches for longer than PHP does on its outdated versions, which doesn’t remove the need to plan a regular version upgrade.