WordPress PHP version compatibility and why keeping PHP updated matters

The WordPress PHP version on your server decides how quickly pages load, which plugins will install and whether the software underneath your website still receives security fixes. WordPress now recommends PHP 8.3 or greater, while every branch older than 8.2 has stopped receiving fixes from the PHP project. Organisations that rely on their website for enquiries and sales can hand the checks, testing and upgrades to a team offering PHP compatibility support for WordPress websites.

Running an outdated version of PHP is a bit like driving a car that has not been serviced in five years. It might still get you from A to B, but something will give eventually. When it does, performance drops, security weakens and plugins break in ways that are difficult to diagnose. WordPress and PHP both keep moving forward regardless of whether your website is ready, so staying behind means problems build up quickly.

What PHP does for your WordPress website

PHP is the server side language that runs WordPress, so every page request on your website depends on it. When someone visits a page, PHP queries the database, assembles the content with your theme and plugins and sends the finished page back to the visitor’s browser.

Themes need it, plugins cannot work without it and any custom code on the website relies on it completely. PHP is used by around 70% of websites whose server side language is known, according to W3Techs usage statistics. WordPress accounts for a large share of that use. A slow or unsupported PHP version therefore affects every page and every visitor, not one feature.

Which PHP version WordPress recommends

WordPress recommends PHP 8.3 or greater, according to the official WordPress requirements page. The same page says WordPress still works on PHP 7.4 and later in legacy environments, but warns that those versions have reached end of life and may expose a website to security vulnerabilities.

The gap between what WordPress tolerates and what it recommends is where most problems start. The WordPress core handbook shows WordPress 7.0 dropped support for PHP 7.2 and 7.3 and lists PHP 7.4 to 8.5 as compatible with current releases. The table below combines that list with the support dates on the PHP supported versions page.

Each PHP branch gets two years of active support followed by two years of security fixes only, after which it receives nothing. PHP 8.1 reached the end of its support on 31 December 2025 and PHP 7.4 on 28 November 2022, as the list of unsupported branches confirms.

A fuller walk through every branch, with what changed between them, is in PHP versions explained. For a WordPress website the practical answer is PHP 8.3 or 8.4 today, with 8.5 once the plugins you depend on have been tested against it.

Why older PHP versions cause real problems

Older PHP versions cause problems with speed, plugin support and security long before anything visibly breaks. Each PHP 8 branch has brought performance work over the version before it, so an old branch means slower page loads for a WooCommerce store or content website. Even a well run hosting environment cannot make up for the language that processes every request being years behind.

Plugin developers eventually stop supporting older PHP versions because maintaining the extra code paths becomes too much work. That leaves a frustrating choice when a plugin you need demands PHP 8.2 or later and the server still runs 7.4. You either keep an outdated plugin with known security holes or rush a server change without proper planning.

Vulnerabilities build up without anyone noticing. Your WordPress core might be fully up to date, but if the PHP runtime underneath has known security flaws, those application updates only go so far. Unsupported branches stay exposed to every flaw found after their end of life date, which is exactly what happened in October 2026.

What the October PHP security release means for WordPress

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can allow an attacker to run code on a web server without logging in. Advance notice went out on 20 October and the PHP security advisory covers patched releases in branches 8.2 to 8.5, while stating that 8.1 and older no longer receive updates from the project.

WordPress itself needed no update, because the flaws sit in PHP rather than in WordPress core or plugins. A fully updated WordPress install on an unpatched server was still exposed, which shows why the server layer needs the same attention as the CMS. The background to the incident and what it means for routine maintenance is covered in keeping PHP up to date after two critical flaws.

How to check which PHP version WordPress runs

The quickest PHP version check is inside WordPress itself, under Tools, then Site Health, then the Info tab, in the Server section. The Site Health screen documentation describes everything the Info tab lists. Any administrator can open it.

If the branch shown is lower than 8.3, WordPress treats the website as running below its recommended version. The dashboard may also show a “PHP Update Recommended” or “PHP Update Required” notice, which is the same check appearing on its own.

Most hosting control panels show the PHP version as well. cPanel, Plesk and managed hosting dashboards often let you switch branch from the same screen. Anyone with command line access to the server can run php -v, but that reports the command line version, which is not always the one serving web pages. Site Health shows the version WordPress is running under, so treat it as the answer.

Planning a PHP upgrade safely

A safe PHP upgrade starts with checking compatibility, then testing on a copy of the website before the live server changes. Rushing it causes outages, while putting it off leaves the website on a branch that is running out of support.

Check every plugin and your theme for PHP compatibility first and give any plugin that has not been updated in twelve months a hard look. Most reputable developers state their PHP requirements in the readme file and the WordPress plugin directory shows the minimum PHP version each plugin needs.

• Create a full backup of the website files and database before making any changes
• Set up a staging environment that mirrors the production server settings
• Switch the staging environment to the target PHP version and test every page and function
• Pay attention to contact forms, payment gateways, membership systems and any custom functionality
• Check the error logs after switching, as deprecation notices show code that works now but will break in a later PHP release
• Once everything works on staging, schedule the production switch for a quiet period

WooCommerce websites need extra attention, because payment processing, tax calculations and shipping integrations all rely on PHP functions that can behave differently across versions. Test the entire checkout from basket to confirmation email before going live. The full sequence of checks, from inventory to rollback plan, is set out in the PHP upgrade checklist.

Modern WordPress development assumes a current PHP branch. A hosting provider that still cannot offer PHP 8.3 or later is a warning sign about the rest of its infrastructure and a good reason to look at alternatives.

Common compatibility issues and how to resolve them

Most PHP upgrade problems follow a small number of patterns, so they are straightforward to fix once you know what to look for. The PHP project publishes a migration guide for each branch, such as the guide for moving from PHP 8.3 to 8.4, which lists every removed and changed feature.

Deprecated functions cause the biggest headaches. PHP warns about these for a version or two before removing them, so code that produced a warning on one branch can produce a fatal error on a later one. When that happens WordPress shows its critical error screen. The steps for fixing a WordPress critical error apply directly.

Stricter type handling catches out older code with each PHP 8 release. Code that passed strings where integers belonged worked on PHP 7.4 but throws errors on current branches. Themes and plugins written before PHP 8 existed are the most likely to be affected.

Plugins that override WordPress core functions can also break when core adopts newer PHP syntax such as named arguments or union types. In most cases the answer is to update the plugin or theme to a version that supports the target branch. Where no update exists, replace it with something actively maintained. Holding the whole server back for one abandoned plugin does not work for long.

Keeping PHP updated as part of ongoing maintenance

PHP updates belong in the same routine as WordPress core and plugin updates, not in a crisis. Build them into regular WordPress maintenance and security and problems are caught early. A quarterly version check takes five minutes and saves the build up of technical debt that makes later upgrades far harder.

The next deadline is close. PHP 8.2 stops receiving security fixes on 31 December 2026. The steps for websites still on it are covered in PHP 8.2 end of life. PHP 8.6 is due for general release on 19 November 2026 according to the PHP 8.6 release timetable, though there is no need to move to a brand new branch before your plugins have caught up.

Good managed WordPress hosts warn about end of life dates and make the switch easy. Some also test websites against newer branches before changing anything. A WordPress support retainer that includes PHP version upgrades takes the same job off your hands. What happens to websites that miss these dates altogether is set out in the risks of running an end of life PHP version.

Performance tools such as Google Lighthouse can flag slow server response times that point to a PHP problem. When response times rise after a WordPress update, check the PHP version and error logs before anything else.

Your server environment deserves the same attention as WordPress core and plugin updates. PHP version compatibility is not the most visible part of running a website, but it keeps everything else working. Staying on a supported branch protects the investment in the website and keeps it fast and secure for visitors and customers.