This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.
PHP 8.2 stops receiving security patches on December 31, 2026 – confirmed on PHP.net’s own supported-versions page. That’s a few months out as I write this, and PHP 8.2 is still the version a large share of WordPress sites are quietly running, because nobody told them the clock was ticking. PHP 8.1 has already gone further: it’s fully end-of-life, off PHP.net’s supported list entirely, meaning it gets nothing at all, not even a critical security fix. And PHP 7.4 – still, right now, the minimum version WordPress core will technically install on – has been unsupported since November 2022.
None of that shows up as a banner in wp-admin. WordPress will run on an unsupported PHP version indefinitely and never say a word about it, which is exactly why so many sites end up there. I’ve covered updating WordPress core, themes, and plugins safely and, more recently, what changes with a major WordPress version specifically. PHP is a different layer again – it’s the language WordPress itself is written in, running on the server, not something WordPress updates on its own. Here’s how to check what you’re running, what it means if it’s outdated, and how to actually move to a current version without breaking the site in the process.
Check your current PHP version first
Don’t guess – WordPress will tell you exactly what you’re running. In wp-admin, go to Tools → Site Health → Info, then expand the Server section. The PHP version line is the actual number your site is executing on right now, not a cached or historical value.
If your PHP version is below what your theme or plugins list as their minimum requirement, Site Health’s own Status tab will usually flag it as a recommended improvement – but only if it’s bad enough to trip that specific check. A site quietly running on 8.1 or 8.2 with no obvious errors often shows a clean bill of health there, because “still receiving security patches” and “technically works” aren’t the same test.
Where every PHP branch actually stands, right now
PHP’s support model is fixed and public: two years of active support (bug fixes plus security fixes), followed by two more years of security-only support, then nothing. Here’s where each branch currently sits, pulled directly from PHP.net’s supported-versions page rather than assumed:
- PHP 7.4 and earlier – fully end-of-life. No security fixes since November 2022 (7.4 specifically). Still runs, still technically meets WordPress’s minimum, and is the least safe version you could be on.
- PHP 8.0 and 8.1 – also fully end-of-life, off the supported list entirely.
- PHP 8.2 – security-fixes-only. That window closes December 31, 2026.
- PHP 8.3 – security-fixes-only, supported through December 31, 2027.
- PHP 8.4 – currently in full active support (bug fixes and security fixes both), through December 31, 2026; security-only after that, through December 31, 2028.
- PHP 8.5 – the newest branch, released November 2025, in full active support through December 31, 2027.
WordPress’s own requirements page states this plainly: it recommends PHP 8.3 or greater, while acknowledging its technical floor of 7.4 is a version that’s “no longer receiving security updates and is thus considered insecure.” That’s WordPress’s own core team telling you the minimum they’ll accept isn’t the minimum you should actually run.
Why this matters more than a routine update
A plugin or theme falling behind is a WordPress-level risk – you can deactivate it, roll it back, or replace it, all from inside wp-admin. PHP is the language the entire site runs on. An unpatched PHP vulnerability isn’t scoped to one plugin; it’s a hole in the server-side code executing every request your site handles, WordPress included. It’s also not something malware scanners built for WordPress specifically are watching for – they check plugins, themes, and core files, not the PHP interpreter underneath all of it.
There’s a performance angle too, separate from security: each major PHP version has shipped meaningful speed improvements since 7.4, and a site still running an old branch is leaving that performance on the table for free, with no code changes required to claim it – unlike most performance work, which takes real effort.
How to actually change your PHP version
This is the part that’s genuinely host-specific – WordPress itself has no PHP-version setting anywhere in wp-admin, because PHP is the server layer WordPress runs on top of, not something it controls. The exact screen differs by host, but the pattern is consistent across nearly all of them:
On Hostinger (what both this site and Repairpicks actually run on)
In hPanel, under your website’s Advanced → PHP Configuration, there’s a version dropdown listing every currently-supported branch. Selecting a new version and saving applies it within seconds – no ticket, no downtime, no separate confirmation step. It’s the single easiest part of the whole process on this host, which is one of the reasons I’d point anyone evaluating Hostinger toward it specifically for a WordPress site: PHP version control being this direct means staying current is a two-click decision instead of a support request.
On cPanel-based hosting
Look for MultiPHP Manager in the cPanel dashboard. It lists every domain/subdomain on the account with its current PHP version next to it, and lets you select one or more domains and apply a new version in bulk.
On Plesk-based hosting
Under the domain’s Hosting & DNS settings, there’s a PHP Settings page with the version selector, usually alongside PHP-specific settings like memory limit and upload size.
On fully managed WordPress hosting
Some managed hosts handle PHP version upgrades on your behalf on their own schedule, sometimes without asking first – which is its own risk, covered below. If you’re on managed hosting and can’t find a PHP version control anywhere in your dashboard, that’s normal; contact support and ask directly what version you’re on and how upgrades are scheduled.
Test before you switch, not after
A version-switcher this easy is also easy to misuse – the risk with PHP isn’t in changing the setting, it’s in what your specific plugins and theme do with the new version once it’s live. Before switching your production site:
- Spin up a staging copy first. If your host offers one-click staging, use it; otherwise see how to create a WordPress staging site. Switch PHP version on the staging copy, not the live one.
- Check each active plugin’s “Requires PHP” field against the version you’re moving to, listed on its WordPress.org plugin page or its own changelog. A plugin that hasn’t stated a PHP requirement recently, or hasn’t been updated in over a year, is the one most likely to break.
- Run the site’s admin and front end on staging – load the homepage, a post, the checkout flow if it’s an ecommerce site, and wp-admin itself. A PHP-version break usually shows up immediately as a fatal error or a blank white screen, not as something subtle you’d only catch days later.
- Only then apply the same version change to production, ideally right after a fresh backup – see the backup step in the safe-update process if that’s not already a routine part of your workflow.
What actually breaks, and what it looks like
The WP Rocket incident I wrote about in the WordPress major-version post was triggered by a WordPress core change, but the failure pattern is identical to what a PHP version jump can cause: old code calling a function in a way a newer version no longer accepts, throwing a fatal error the moment that code path runs. With PHP specifically, the most common cause is a plugin or theme calling a function that a newer PHP version has deprecated or outright removed – something like passing the wrong argument type to a built-in string function, which is precisely the class of error the WP Rocket bug was.
The practical symptom is usually one of two things: a full white screen with nothing rendering (PHP fatal errors are often suppressed from display by default, so the page just goes blank), or a specific error banner naming a function and a file path if debug output is enabled. Either way, the fix is almost always the same – switch the affected domain back to its previous PHP version immediately from the same dashboard screen used to change it, then update or replace whichever plugin threw the error before trying again.
If you can’t upgrade right away
Sometimes a specific plugin genuinely isn’t ready for a newer PHP version yet, and switching would break something you can’t afford to have down. If that’s the actual situation, the honest move is to treat it as a deadline, not a decision to postpone indefinitely: note which PHP version you’re stuck on and why, check back on that specific plugin’s compatibility every few weeks, and set your own reminder for whichever security-support end date from the table above applies to your current version. Staying on an outdated PHP version because you haven’t gotten to it yet, versus staying on it because of one identified, tracked blocker, are very different situations – only the second one is actually manageable.
The version to land on
Given where each branch currently stands, PHP 8.3 or 8.4 is the sensible target for most WordPress sites today – both are still receiving active or security support well into 2027 and beyond, and both are old enough that plugin compatibility issues have mostly already surfaced and been fixed upstream. PHP 8.5, released only in November 2025, is safe from a support-timeline standpoint but is new enough that some plugins may not have caught up yet – worth checking plugin compatibility notes specifically before jumping straight to it. Whichever you land on, the version itself matters less than actually knowing what you’re running and whether its clock is still running too.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.