PHP Versions and WordPress: Why Upgrade

Every WordPress site is a PHP application wearing a friendly admin interface. The database queries, the theme rendering, the plugin logic — all of it is PHP code executed by a PHP interpreter, and that interpreter has a version number with an expiry date printed on it. Most site owners never look at that date. The site loads, so everything must be fine.

It is fine, right up until it isn't. Running an end-of-life PHP version is one of the few genuinely non-negotiable items in WordPress maintenance, and unlike a lot of advice in this space, the reasoning has nothing to do with vague best-practice hand-waving. It comes down to a support calendar published by the PHP project itself, and to what quietly stops happening once your version falls off it.

How PHP versions live and die

The PHP project runs on a predictable release train. A new minor version (8.2, 8.3, 8.4 and so on) ships roughly once a year, in late November. From the moment it ships, each version moves through three phases:

  1. Active support. Bug fixes and security fixes. This is the healthy phase, and it lasts about two years.
  2. Security-only support. No more bug fixes. Only security vulnerabilities get patched. Under the current policy this phase also lasts about two years, so a version gets roughly four years of life in total.
  3. End of life (EOL). Nothing. If a vulnerability is discovered in an EOL version, the PHP project does not fix it. Ever. The fix lands in supported versions only, and the changelog describing that fix doubles as a public map to the hole in yours.

That last sentence is the whole argument, so it is worth sitting with. Security researchers and attackers both read release notes. When PHP 8.x patches a vulnerability in, say, its handling of malformed multipart requests, everyone now knows that older, unpatched versions likely contain the same flaw — permanently. An EOL PHP version is not a stable old workhorse. It is a growing collection of publicly documented, never-to-be-fixed vulnerabilities.

What EOL actually means in practice

There are a few standard objections at this point, and they deserve honest answers.

'My host patches things for me'

Sometimes true. Some operating system vendors and managed hosts backport security fixes to EOL PHP versions for their own customers. But this puts you in an awkward position: your security now depends on an unofficial patch stream you cannot audit, with no published support commitment, applied at someone else's discretion. If your host does this well, great — but you generally can't verify it, and 'trust me' is a weak foundation for the thing your business runs on. A supported PHP version gives you a public, verifiable guarantee instead.

'Nothing has broken so far'

Correct, and irrelevant. The failure mode of running EOL software is not that the site slowly degrades. It is that it works perfectly until the day someone exploits it, at which point you have a compromised database, a blocklisted domain, and a weekend gone. Absence of symptoms is not evidence of safety; it is just how the time before an incident feels.

'WordPress still supports old PHP, so it must be OK'

This one deserves its own section, because the reasoning error is subtle.

Why WordPress will not force your hand

WordPress core is famously conservative about minimum requirements. It keeps compatibility with PHP versions that the PHP project abandoned years ago, because the WordPress project's priority is that a core update never bricks a site — including the millions of neglected sites on ancient hosting. The stated minimum requirement and the stated recommended version are very different numbers, and only the second one is advice.

Read it this way: the minimum requirement is WordPress promising not to crash on old PHP. It is not WordPress promising that old PHP is safe. Those are different promises, and only one of them is WordPress's job to make. The Site Health screen (under Tools → Site Health) will nag you about outdated PHP precisely because the core developers want you on a modern version even though the software technically tolerates an old one.

Plugins are less patient. Major plugins — commerce, SEO, form builders — regularly raise their own PHP floors, because their developers do not want to write and test code for interpreters from a previous era. Stay on EOL PHP long enough and you stop receiving plugin updates too, which means you are now missing their security fixes as well. The rot compounds.

The performance argument (which is real, but secondary)

Upgrading PHP is one of the rare performance wins that costs nothing and requires no plugin. The PHP 7 series was dramatically faster than PHP 5, and the PHP 8 series brought further real gains — for a typical WordPress workload, moving up a couple of modern minor versions often yields a noticeable improvement in server response time. Treat that as a rule of thumb, not a lab result: your exact gain depends on your theme, your plugins, and how much of your traffic is served from cache anyway.

One honest caveat: you may have heard about the JIT compiler introduced in PHP 8.0. For WordPress it barely matters. JIT shines on long-running, computation-heavy code; WordPress requests are short bursts of I/O-heavy work — database queries, file includes, string assembly. The speedups you actually feel come from years of engine and opcache improvements, not JIT. Upgrade for the engine, not the buzzword.

Know what you are actually running

Before planning anything, establish facts. Three ways to check your PHP version:

  • Site Health: Tools → Site Health → Info → Server. No terminal needed.
  • WP-CLI: wp cli info shows the PHP version WP-CLI runs under. Be aware this can differ from the version serving web requests, so also run wp eval 'echo PHP_VERSION;' and compare with what Site Health reports.
  • Hosting dashboard: nearly every host has a PHP version selector per site.

Then inventory what depends on it. The moving parts that care about PHP versions are your theme, your plugins, and any custom code in your child theme or a mu-plugin. wp plugin list --fields=name,version,update_version gives you the plugin picture in one command; anything abandoned for years is your top compatibility suspect.

What actually breaks when you upgrade

Fear of breakage is the honest reason most sites stay on old PHP, so let's be specific about what breaks. PHP's backwards-compatibility record within a major series is good; the pain concentrates in a handful of well-known removals and behavior changes:

  • Removed functions. create_function() and each() — both common in old plugin code — were deprecated in the 7.x era and removed in PHP 8.0. Code calling them fatals immediately.
  • Stricter type handling. PHP 8 turned many silent oddities into real errors: passing nonsense strings to arithmetic, calling methods on null, wrong argument types to internal functions. Sloppy old code that 'worked' by accident starts throwing.
  • Deprecation notices as canaries. PHP 8.1 started deprecating passing null to non-nullable parameters of internal functions; PHP 8.2 deprecated creating undeclared object properties on the fly (dynamic properties). Deprecations don't break anything yet — they are the engine telling you what breaks next major version. A log full of deprecation notices is a to-do list, not an emergency.
  • The long tail. Curly-brace string offsets ($str{0}), optional-before-required parameter signatures, and similar removed syntax show up almost exclusively in plugins that haven't been updated since the previous decade. If a plugin trips on these, the real finding is that the plugin is abandoned.

Notice the pattern: modern, maintained code sails through PHP upgrades. It is unmaintained code that breaks — and unmaintained code was already your biggest security liability. The PHP upgrade doesn't create that problem; it surfaces it while you're paying attention, which is the best possible time.

A safe upgrade playbook

Here is the sequence that turns 'scary infrastructure change' into a boring afternoon task.

1. Upgrade one step at a time, but do upgrade

If you are several versions behind, you don't need to test every intermediate version — jump to a current, actively supported one. The compatibility work is the same whether you land on it directly or crawl there.

2. Scan before you switch

The PHPCompatibility ruleset for PHP_CodeSniffer can statically scan your theme and plugin code and flag syntax that fails on your target version. It produces false positives and misses runtime-only issues, but it reliably catches the fatal stuff — removed functions, removed syntax — before any user does. Ten minutes of scanning beats an hour of production firefighting.

3. Test on a staging copy

Clone the site, switch the clone's PHP version, then click through the flows that make you money: homepage, key landing pages, search, forms, checkout if you have one, and — the one everyone forgets — the admin screens of your major plugins. Front-end pages can render fine while an admin settings page fatals.

4. Turn the lights on

On staging, enable logging: set WP_DEBUG and WP_DEBUG_LOG to true so warnings, deprecations, and fatals land in wp-content/debug.log. Browse the site, then read the log. Deprecation notices get triaged (update the offending plugin, or note it for later); fatals get fixed before you proceed. On production after the switch, keep an eye on the server's PHP error log for the first day or two.

5. Switch production during a quiet hour, keep the exit open

The actual switch is usually one dropdown in your hosting panel and takes effect in seconds. Its saving grace: it is just as instantly reversible. If something unexpected surfaces, switch back, fix the offender on staging, and try again. This is not a one-way door — which is exactly why there's no excuse to avoid walking through it.

6. Make it a calendar event, not a crisis

Since PHP versions ship every November and live about four years, you can schedule this. A once-a-year check — 'what version am I on, when does it die, what is current?' — keeps you permanently in the safe zone with minimal effort. Sites get into trouble not because upgrading is hard, but because nobody owns the question.

The decision rule

If you want the entire article as one rule: run a PHP version that is still receiving security fixes from the PHP project, and plan your next move before the current version enters its security-only phase. Everything else — performance gains, plugin compatibility, Site Health approval — comes along for free.

And if your host doesn't offer any currently supported PHP version? That is not a PHP problem. That is your host telling you, in their own quiet way, that it is time to leave.

The short version

PHP versions get about two years of full support and two more of security fixes, then nothing — forever. WordPress tolerates old PHP but does not endorse it, and its own tooling actively warns you about it. Upgrades mostly break abandoned code, which needed replacing anyway. Scan, stage, watch the logs, flip the switch, keep the rollback handy. It is a solved, boring, reversible procedure — and the alternative is running your business on software with publicly documented holes nobody will ever patch. Boring wins.

Photo: Daniil Komov on Pexels