Can You Still Run WordPress on PHP 7.4 in 2026?

The short answer is yes, you can. Millions of sites do, quietly, and most of their owners have no idea.

The interesting question is the second one — what it costs you — and the answer is not the one usually given, which is a vague warning about security. The real cost is more specific and more awkward, and it is worth understanding before you decide what to do about it.

I am writing this from inside the problem rather than above it. One of the sites I run is on PHP 7.4 today, in 2026, and it is not there through neglect.

First, what “unsupported” actually means

PHP 7.4 stopped receiving security fixes in November 2022. Not features — fixes. Any vulnerability found in the language itself since then remains open on your server permanently.

That is the standard warning, and it is true. It is also, on its own, slightly misleading, because it invites a comparison people get wrong. Most WordPress sites are compromised through plugins, themes and weak passwords rather than through PHP itself. Being on an old PHP version does not put you at the top of anyone’s list.

So if you are on 7.4 and nothing has happened, that is not luck exactly. It is simply that the risk is real, cumulative, and slow — which is the worst possible shape for a risk, because nothing ever forces the decision.

Why people are stuck, and it is not laziness

Here is the part missing from most articles telling you to upgrade.

PHP 8.0 did not just add things. It removed things. One removal in particular has stranded an enormous number of sites: a function called create_function(), which older code used to build small pieces of logic on the fly.

It was deprecated in 7.2 and deleted in 8.0. Any code still calling it does not degrade gracefully or produce a warning — it stops the page dead with a fatal error.

The problem is where that code lives. Not in your site: in a theme or a plugin you bought years ago, whose author has moved on, or whose update path requires a version of the framework your site cannot take.

That is why “just upgrade PHP” is not a task. It is a fatal error waiting for you to press the button. And you find out by taking the site down.

How to know before you break something

Check whether the removed function appears anywhere in your site’s code:

grep -rn "create_function" wp-content/ --include="*.php"

No results is a good sign, though not a guarantee. Any result tells you exactly which theme or plugin is holding you on the old version.

For a fuller picture, the PHP Compatibility Checker plugin scans your installation and reports which components will fail on a newer version. It produces false positives, but it turns an unknown into a list.

The most reliable method remains a staging copy on the newer version, clicked through properly. Not the homepage — the contact form, the checkout, the admin screens that only you ever see.

The cost nobody mentions: it is not only security

This is the part I did not expect, and it changed how I think about the whole question.

The same old, heavy theme that is holding a site on PHP 7.4 is usually also making that site expensive to run, every single day.

On my server I measured the memory used to build one page: 170 MB per request. A lean WordPress install sits around 40-60 MB. That difference is not an abstraction — it is the reason that server can handle roughly a third of the traffic its hardware should support, and the reason I have had to think about worker limits at all.

So the true cost of staying on 7.4 is usually threefold:

1. Security — a growing set of unpatched vulnerabilities in the language.
2. Performance — newer PHP versions are substantially faster at exactly the work WordPress

does, and you are declining that improvement for free.

1. Capacity — the heavy component that pins you to the old version is generally also

consuming several times the memory it should, so you are paying for a bigger server than your traffic requires.

The third one is the one that shows up on your invoice.

The decision, honestly framed

Once you accept that the real task is replacing the component rather than changing a version number, there are three genuine options.

Stay, deliberately and defensively. Legitimate if the site earns little and a rebuild is not justified. If you choose it, choose it properly: keep WordPress core, plugins and themes fully updated, run a security plugin with two-factor authentication on every administrator account, take backups you have actually tested restoring, and write down that this is a decision with an expiry date rather than a permanent state. What makes this dangerous is not the choice — it is making it by default and forgetting.

Rebuild on a modern theme. The only option that removes the problem rather than managing it, and by some distance the most expensive: rebuilding a content-heavy site built with a page builder is weeks, not days, because the content itself is entangled with the tool that created it. The compensation is real — a lean theme can cut per-request memory by two-thirds, which on a busy server is the equivalent of a hardware upgrade you do not have to buy.

Move to managed hosting. Worth considering precisely because it changes who owns the problem.

Managed WordPress hosts run current PHP as a matter of course and will generally tell you what breaks before you move, on a staging copy, as part of the service. It does not magically fix an incompatible theme — nothing does — but it converts an open-ended technical burden into a monthly cost, and for a site that earns money that trade is often obviously correct. Kinsta is the established option in that category; migrations and staging environments are included rather than sold separately, which is the part that matters here.

If you would rather keep control and simply need a machine with enough memory to survive a heavy theme while you plan the rebuild, Hostinger and Contabo sell VPS plans where the extra RAM costs less per month than a single hour of anyone’s time.

For transparency: my own sites run on neither of those, with an Italian provider I have used for years, which has no affiliate programme. The measurements above come from that machine, including the uncomfortable one.

What I actually did

I upgraded what could move and left one site on 7.4.

That site runs a commercial theme with a page builder, and the content is bound tightly enough to the builder that replacing it means rebuilding the site rather than reskinning it. I have priced that work and not yet committed to it.

What I did instead was make the choice explicit rather than accidental: two-factor authentication on every administrator account, brute-force blocking, tested backups, and a written note that this is temporary. I also measured what the theme costs in memory, which is what turned “I should get round to this” into a number I can compare against the cost of the rebuild.

That is not a solution and I am not presenting it as one. But there is a real difference between a risk you have measured and accepted, and one you have simply not looked at.

The short version

• PHP 7.4 has had no security fixes since November 2022.
• The usual blocker is create_function(), removed in PHP 8.0 — it lives in an old theme or plugin.
• Check with grep -rn "create_function" wp-content/ --include="*.php" before touching anything.
• The real task is replacing that component, not changing a version number.
• The hidden cost is memory: the component pinning you to 7.4 is often also making the site

three times more expensive to serve.

• Staying is defensible. Staying without knowing is not.