How to Update PHP on a WordPress Site

On 31 December 2026, PHP 8.2 stops receiving security fixes. Nothing will break that day, no warning will appear, and roughly a quarter of all WordPress sites will quietly cross from supported to not. Add the ones already past it and three in five WordPress sites start 2027 running a language version nobody is patching. The upgrade itself is a dropdown in your hosting panel. The part worth getting right is everything either side of it.

What happens on 31 December

PHP releases retire on a published schedule rather than when they stop working. Each version gets about two years of active support, then a year of security fixes only, then nothing. PHP 8.2 reaches the end of that line on the last day of 2026.

Here is where the versions stand today, from the official PHP release calendar.

Two dates fall on the same day, which causes some confusion. PHP 8.2 dies completely. PHP 8.4 merely moves from active support to security fixes only, which is a normal part of its life and not a reason to avoid it.

How many sites this affects

WordPress publishes what its own installs are running, and the picture is worth seeing before you decide this can wait.

37.2% of WordPress sites are already running an unsupported version. On 1 January that becomes 60.8%, because 8.2 joins them.

Nothing visible happens to any of those sites. That is precisely the problem: an end of life version runs exactly as it did the day before, and the only thing that changes is that a flaw found next year never gets fixed on your server.

Which upgrade are you actually doing?

The honest answer to "how hard is this" depends entirely on where you are starting, and the difference between the rows below is hours rather than minutes.

If you do not know which row is yours, our guide to checking your WordPress PHP version takes about thirty seconds and the answer is in Site Health.

The rest of this assumes the hardest case. If you are on 8.2 moving to 8.4, you can skip lightly over the testing and still be fine.

Find out what will break before you touch anything

The upgrade takes seconds. Finding out what it will break is the actual work, and there are four ways to do it, in increasing order of how much they tell you.

1. Look at what is stale

Start here because it costs nothing. Open Plugins, then Installed Plugins, and for each one check the WordPress.org listing for when it was last updated.

A plugin updated this year will almost certainly be fine on current PHP, because its author has been running it there. A plugin last touched in 2019 is the one that will break, and it will break whether you upgrade now or next year. The same applies to themes, and our guide to spotting an abandoned WordPress theme covers how to tell.

Anything custom gets the same scrutiny. Code written for your site specifically, whether in a child theme or a snippets plugin, has nobody maintaining it but you.

2. Turn on the debug log and read the deprecations

PHP warns before it removes. A function that disappears in 8.4 has usually been shouting about it since 8.1, and those warnings are written to a log you are probably not reading.

Add these three lines to wp-config.php, above the line that says to stop editing:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Errors go to wp-content/debug.log and are not shown to visitors, which is the combination you want on a live site. Leave it running for a few days, click through the admin, place a test order, submit a form, then read the file. WordPress's debugging documentation covers the options in full.

Lines containing Deprecated: are your shortlist. Each one names a file, so you can see immediately which plugin owns the problem.

Turn all three off when you are done. A debug log left running will fill the disk eventually, and one left displaying leaks file paths to anybody who triggers an error.

3. Query Monitor, for a live view

Query Monitor puts PHP warnings and deprecations in your admin bar as you browse, which is a far faster loop than reading a log file. It is actively maintained and it is the tool most developers reach for.

Install it, browse the site as an administrator, and watch for the warnings counter. Remove it when you are finished, since it is a diagnostic rather than something to leave running on a live site.

4. The plugin everybody recommends, and why not to rely on it

Search this subject and you will be told to install PHP Compatibility Checker. It scans your plugins and themes and produces a compatibility report, which sounds exactly like what you want.

Its own description now opens with a warning that it is no longer maintained, and that no further releases will be made, including security releases. It is also tested only against a WordPress version several major releases behind.

A scanner that has stopped learning about new PHP syntax cannot tell you about new PHP problems. A clean report from it is not evidence of anything, and the risk is that it talks you out of the testing that would have found the real issue.

The only test that actually counts

Staging. Most decent hosts include it, usually one button in the panel, and it gives you a copy of the site where breaking things costs nothing.

Switch the PHP version there, then click through the parts that matter rather than just loading the home page: checkout, contact forms, the login, anything with a payment gateway, anything with a booking calendar. Those are where the old code hides.

If your host offers no staging, make a full backup and do the upgrade at your quietest hour instead. It is not as good, and it is a great deal better than nothing.

How to update PHP in your hosting panel

You update PHP on the server, not in WordPress, so this happens in your hosting panel. There is no PHP update button in your dashboard and there never will be.

Our guide to cPanel covers finding it if that is what you are on.

Then, in order:

1. Update every plugin and theme first. This alone resolves most compatibility problems, because the fix is usually already shipped and sitting in an update you have not applied.
2. Take a backup you have actually tested. Not the one your host says exists.
3. Move one minor version at a time. From 7.4, go to 8.0, then 8.1, and up. Jumping straight to 8.4 works often enough, and when it does not you have no idea which step caused it.
4. Load the site logged out, in a private window, after each step. What you see logged in is not what a visitor sees.
5. Check the money paths. Add to basket, check out, submit the contact form, log in as a customer. A home page that loads proves very little.

Rolling back takes about a minute

This is the part that makes the whole exercise far less frightening than it sounds, and almost nobody says it plainly.

If the site breaks, change the dropdown back. The old PHP version is still installed on the server, selecting it again restores the site immediately, and nothing in your database or your files has been touched by the upgrade.

Which means the realistic worst case for a careful upgrade is a few minutes of a broken site followed by a successful rollback, not a disaster. That is a very different risk profile from a theme or plugin change, and it is why "we will do it later" is usually the wrong call.

One caveat worth knowing. If you updated plugins in the same sitting, rolling PHP back does not roll those back, so a problem that survives the rollback is probably a plugin update rather than the PHP change. Our guide on what to do when an update breaks your site covers unpicking that.

What actually breaks

In practice it is a short list, and the error message tells you which one you have.

The distinction that matters is between Deprecated and Fatal error. A deprecation is PHP telling you something will stop working in a future version, while the site carries on working now. A fatal error is the site down. Logs full of deprecations are worth fixing eventually and are not an emergency, though they do fill a disk quickly if nobody looks.

The PHP 8.2 deprecation list is the reference if you want to see exactly what changed and when.

What you actually gain

Everything above argues from risk, which is the honest reason to do this but a miserable one. There are three things you get back, and it is worth being straight about how big each one is.

Speed, though less than the marketing suggests. Newer PHP is faster, and your site will do more with the same server. The enormous leaps are historical: the jump from PHP 5 to PHP 7 roughly halved the work for a typical request, and that is the number quoted in most articles on this subject. Moving from 8.2 to 8.4 is a few per cent, not a transformation. Real, worth having, and not a reason on its own.

If speed is the actual problem you are trying to solve, PHP is rarely where it lives. Our guide to why WordPress sites run slowly covers the things that usually are.

Plugins that keep working. This is the one people underrate. Plugin authors drop support for old PHP, and when they do, your update button quietly stops offering you new versions. Sitting on 7.4 does not freeze your site in amber; it slowly cuts you off from the security updates of everything running on it. The longer you leave it, the more plugins are stuck at whatever version last supported you.

A site that passes a security review. Unsupported PHP is one of the first things any audit, insurer or enterprise client flags, and it is the easiest finding to close. It also shows up in WordPress's own Site Health screen as a recommendation, which is where most people first notice.

Which version should you move to?

WordPress recommends PHP 8.3 or greater. Beyond that minimum, the choice is about how long you want before doing this again.

• PHP 8.4 is the sensible default for most sites. Plugin support is broad by now, and it has security fixes until the end of 2028.
• PHP 8.5 if your host offers it and your plugins are current. It is the newest and it buys the most time, with support into 2029.
• PHP 8.3 is fine and is the floor rather than the target. It only runs to the end of 2027, so you would be doing this again in a year.

Going from 8.2 to 8.3 technically solves the December problem and gives you twelve months. Going to 8.4 or 8.5 solves it for two or three years, for the same ten minutes of work.

If your host has no current version to offer

Sometimes the panel simply stops at 8.1, and no amount of testing changes that.

That is a hosting problem wearing a PHP problem's clothes, and it is worth treating as one. A host that cannot offer a supported version of the language your site is written in, in the final quarter of 2026, is telling you something about how the rest of the stack is maintained. Our guide to choosing a WordPress host covers what to look for, and a move is a smaller job than most people expect.

The short version

Check which version you are on. If it starts 8.3, 8.4 or 8.5, you have nothing to do until next autumn.

If it starts 8.2, you have until 31 December. Upgrading PHP to 8.4 is about ten minutes on a site whose plugins are current.

If it starts with 7, or 8.0, or 8.1, you are already running unpatched software and the deadline is beside the point. Update your plugins, test on staging, and move up one version at a time.

And whichever applies, remember that the rollback is the same dropdown. That is what makes this one of the lower risk jobs on a WordPress site, despite being one of the most postponed.

Frequently asked questions