On December 31, 2026, PHP 8.2 will stop receiving security fixes. About one WordPress site in four runs on it today. In late September 2026, WooCommerce set its own deadline: from February 2027, the store plugin will require at least PHP 8.1, while WordPress itself still accepts PHP 7.4.
The PHP version is the engine under the hood of every WordPress site. Nobody sees it, which is exactly why it ages in silence. A site can run for years on a version nobody patches anymore, until the day a plugin update refuses to install.
The short answer fits in one line: in October 2026, aim for PHP 8.3 or 8.4. PHP 7.4 still works with WordPress, but it has not received a single fix in almost four years.
This guide follows a simple method: know the calendar, test compatibility, then switch through a staging copy.
The short answer: which PHP version in October 2026
Minimum, recommendation, and the Hosting Handbook’s 8.4
WordPress has required at least PHP 7.4 since version 7.0, released on May 20, 2026. The official requirements page recommends PHP 8.3 or greater, and notes that WordPress still works with PHP 7.4.
The handbook written for hosts, maintained by the project’s Hosting team, goes further: it recommends PHP 8.4 or later for production environments. The two recommendations coexist without really contradicting each other. The first sets a comfortable floor, the second aims for the longest lifespan.
For a site you manage yourself, PHP 8.3 is a safe choice, and PHP 8.4 a choice that stays supported longer. PHP 8.5 is now fully supported by WordPress 6.9 and later.
What “supported” means at php.net
Each PHP branch lives four years. For two years, it receives every bug fix. For two more years, it only receives critical security fixes. Then it stops.
Since a 2024 decision, these periods all end on December 31, which makes the calendar easy to remember. The same reform added a year of security fixes to every branch still alive, and PHP 8.1 benefited from it until the end of 2025.
A stopped version keeps working. Nothing breaks on January 1. But any flaw discovered afterwards stays open, except at hosts that offer extended support.
The PHP calendar to keep in view
The branches still alive
PHP 8.2 only receives security fixes, until December 31, 2026. It is the next branch to go, in three months.
PHP 8.3 moved to security-only on December 31, 2025, and stays there until December 31, 2027. PHP 8.4 receives every fix until the end of 2026, then security fixes only until the end of 2028. PHP 8.5, released in November 2025, is fully maintained until the end of 2027, then patched for security until the end of 2029.
PHP 8.6 is in the release candidate phase, with release planned for November 19, 2026. No announcement says yet whether WordPress 7.2, expected in early December, will document it as compatible.
The branches that have stopped
PHP 8.1 has received nothing since December 31, 2025. PHP 8.0 stopped in November 2023, PHP 7.4 in November 2022. A site on PHP 7.4 has therefore been running for almost four years on an engine its authors no longer patch.
The API WordPress queries to judge the site’s PHP version still considers PHP 8.1 “secure”. The absence of a red alert in the Site Health screen therefore does not prove your version receives fixes: only php.net’s calendar counts.
What WordPress core supports
The compatibility table
The core handbook publishes a compatibility table, updated in August 2026. WordPress 7.0 and 7.1 are compatible with PHP 7.4 to 8.5. WordPress 6.9 accepts PHP 7.2 to 8.5. Versions 6.7 and 6.8 stop at PHP 8.4.
Until spring 2026, recent PHP versions carried a “beta” support label. In May 2026, the core team removed it, including for past versions, because it made some site owners and hosts reluctant to upgrade. WordPress 6.9 and 7.0 are now documented as fully supporting PHP 8.5.
Sites still on PHP 7.2 or 7.3
A site on PHP 7.2 or 7.3 cannot install WordPress 7.x. It stays on the 6.9 branch, which received version 6.9.9 on September 22, 2026. These backported fixes remain a courtesy: officially, only the latest branch is maintained.
Since WordPress 7.0, the dashboard warning shown to sites on PHP 7.4 adds that this version will soon no longer be supported by WordPress, and a code comment says the minimum will rise to at least PHP 8.0, with no date. Our overview of what changed in WordPress 7 covers this new floor.
Where WordPress sites really stand
The wordpress.org statistics
WordPress.org publishes the PHP version breakdown of sites that query its update servers. On October 1, 2026, PHP 8.3 and PHP 8.2 each hold about a quarter of sites. PHP 7.4 keeps about a sixth, down from more than a fifth in January.
The overall picture is less flattering. More than one site in three runs on a branch php.net no longer patches, and barely more than one in three reaches the recommended version. The branches still fully maintained, 8.4 and 8.5, do not exceed one site in eight.
At WordCamp US in August 2026, core contributors acknowledged that adoption was stalling, while pointing out that WordPress.com already runs on PHP 8.4.
The 5% rule
The project does not raise its minimum on a fixed schedule. By tradition, it waits for a PHP version to fall below 5% of sites before dropping it. That is what happened to PHP 7.2 and 7.3 in early 2026.
This rule protects small sites, but it has a side effect: WordPress’s floor is set by the sites that lag furthest behind. The official minimum tells you what still works, and only php.net’s calendar tells you what is still patched.
The real case: WooCommerce sets PHP 8.1 for February 2027
While WordPress waits for its 5%, WooCommerce has moved first. The story spans three weeks of September 2026, documented by the WooCommerce developer blog, its comments and its code repository. It shows something compatibility tables do not say: the PHP version your site needs is set by its most demanding component.
A precedent in 2023
WooCommerce had taken this step before. In June 2023, the team announced that WooCommerce 8.2, due in October, would require PHP 7.4. At the time, about 97% of recently updated stores already ran PHP 7.4 or newer. The others could keep WooCommerce 8.1, without going further.
The September 8 proposal
On September 8, 2026, Brian Coords published a proposal on the developer blog: require PHP 8.1 from WooCommerce 11.5, in January 2027, and drop PHP 7.4 and 8.0. The figures come from stores that share their data voluntarily: about 7% on PHP 7.4, 2% on PHP 8.0, and a share falling steadily.
The post also details what would happen to a store left on PHP 7.4. WooCommerce 11.5 would declare PHP 8.1 in its header, WordPress would therefore not offer the update, and the store would keep its version, with the minor fixes of its branch. Nothing would be deactivated.
The debate in the comments
Twenty-eight comments followed. Some asked to keep PHP 7.4 as long as WordPress does, pointing out that more than one WordPress site in six still uses it. A commenter who maintains a few sites on PHP 7.4 explained that, at their last audit, a few paid WooCommerce plugins did not yet handle PHP 8.1. Others asked instead for a floor at 8.3 or 8.4, since PHP 8.1 is no longer maintained.
Néstor Soriano, an engineer at Automattic, answered with data: PHP 7.4 and 8.0 together account for about 9% of tracked stores, and should approach 5% at release. Only about 20% of stores run PHP 8.4 or 8.5. When PHP 8.1 in turn nears 5%, the team will consider moving to 8.2.
Another commenter, Clifton Griffin, asked for a warning that does not scare people: most merchants probably do not realize that changing PHP version takes a few minutes in their host’s control panel.
The September 29 decision
On September 29, the decision came, with an adjustment. The requirement moved to WooCommerce 11.6, planned for February 2027, to give stores time to test and upgrade after the peak year-end selling season. Stores on PHP 7.4 or 8.0 can keep updating up to version 11.5.
The next day, the code followed. A pull request adding a dismissible admin notice to WooCommerce 11.3 was merged on September 30. The team also analyzed the 1,357 plugins sold on its marketplace: 0.22% showed potential issues with PHP 8.1, to be checked by hand. The post warns that this kind of analysis cannot guarantee that every plugin or custom code will work.
What WooCommerce asks merchants to do
The published steps are concrete. Check your version under WooCommerce, Status, Server environment. Ask your host for PHP 8.3 or newer: 8.1 meets WooCommerce 11.6’s minimum, but 8.3 is its current recommendation. Back up, test on a copy, then switch production.
The tests requested go well beyond the home page: checkout and payment methods, shipping and taxes, order management, scheduled jobs, the theme, plugins and custom code.
What to take away
A store can run WordPress 7.1 on PHP 7.4 today, and find itself stuck on an old WooCommerce version in February 2027. Staying on 11.5 is only a stopgap: WooCommerce’s security policy only backports fixes for the most severe flaws, rated 9 or more out of 10, to older versions.
The final outcome is unknown today, even though the decision and its calendar are settled. But the lesson applies to every site. Identify the most demanding component of your installation, and take its date as your deadline.
Testing compatibility before switching
PHPCompatibilityWP, with the right target version
The reference tool for analyzing code is PHPCompatibility, a ruleset for PHP_CodeSniffer, and its PHPCompatibilityWP variant, which avoids false alarms on functions WordPress provides itself. WordPress core uses it in its own tests.
Beware of the version trap: PHPCompatibility’s latest stable release dates from December 2019. Detection of PHP 8 changes, up to 8.5, lives in the pre-releases of the 10.0 series. The PHPCompatibilityWP repository documents installation with Composer.
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/phpcompatibility-wp:"^3.0@dev"
vendor/bin/phpcs -p wp-content/plugins/my-plugin --standard=PHPCompatibilityWP --extensions=php --runtime-set testVersion 8.3-The testVersion parameter sets the target: 8.3- checks that the code works on PHP 8.3 and above. Without it, the tool only reports deprecated or removed PHP features.
What static analysis does not see
A scan without warnings guarantees nothing. WordPress VIP’s documentation says so plainly: some changes only show up at runtime, and the scanner is not designed to catch them. VIP recommends adding PHPStan or Psalm, with their WordPress extensions, to catch type errors.
Those errors are precisely the ones PHP 8 made stricter. PHP 8.0 removed create_function() and each(), and changed how strings and numbers compare. PHP 8.1 deprecated passing null to built-in functions that do not accept it. PHP 8.2 did the same for dynamic properties. PHP 8.4 deprecated implicitly nullable parameters, whose nullable type should now be written explicitly.
Be wary too of WP Engine’s PHP Compatibility Checker plugin, which wordpress.org’s help page still recommends. Its own listing states that it is no longer maintained, that it only checks compatibility up to PHP 8.0, and that it skips code not hosted on wordpress.org.
Logs and Query Monitor on the staging copy
The most reliable test is still running the code. On the staging copy, turn on WordPress’s debug log, as its documentation recommends, writing errors to a file without showing them to visitors.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Errors then land in wp-content/debug.log. The free Query Monitor plugin also shows them page by page, along with deprecation notices, and tells you which plugin or theme triggers them. The documentation specifies that these settings are meant for a local or staging environment, not production.
If you work on the command line, remember that WP-CLI’s PHP version can differ from the one serving the site. The wp cli info command shows the version used on the command line, and the Info tab of the Site Health screen the web server’s. Our selection of essential WP-CLI commands covers this tool in detail.
The upgrade procedure, step by step
Back up, clone, label the copy
Start with a full backup, files and database, that you know how to restore. Then create a staging copy: most managed hosts offer one, and plugins such as WP STAGING or Duplicator can clone a site. Our comparison of the best WordPress backup plugins helps you choose.
On the copy, declare the environment type. Since WordPress 5.5, this constant lets plugins know they are not in production, for example to pause outgoing emails or real payments.
define( 'WP_ENVIRONMENT_TYPE', 'staging' );Switch the copy, test, then production
Change the PHP version of the copy only, in the host’s control panel. Walk through the journeys that matter: login, forms, search, and for a store the full checkout with a test payment method. Then read the debug log, and fix or replace whatever breaks.
When the copy is clean, switch production, ideally at an off-peak hour. Repeat the critical journeys, check the Site Health screen, and keep the old PHP version at hand: most panels let you roll back in a few clicks.
One last piece of advice: do not change everything on the same day. Updating PHP, WordPress and ten plugins at once makes any incident impossible to attribute.
How a host does it at scale
In 2024, SiteGround described its own move from PHP 7.4 to PHP 8.2. Each site was first tested in isolation to check that it loaded on PHP 8.2. Sites without problems were notified a week before the switch.
The rollout started with five servers, then fifty, two hundred and fifty, and finally five hundred shared servers a week. After 88 days, nearly 93% of sites had passed the check without issues. The remaining 7% or so were left on PHP 7.4, and their owners contacted. The method, isolated testing then a gradual ramp-up, is the same as for a single site.
Changing versions in your hosting panel
cPanel, Plesk, OVHcloud and hPanel
In cPanel, the MultiPHP Manager tool lists your domains: tick the domain, pick the version in the menu, then apply. In Plesk, the version is set in each domain’s PHP tab, with a warning that PHP versions are not fully compatible with each other.
At OVHcloud, on shared hosting, the php.ini file cannot be edited: the version is chosen in the control panel, or in the .ovhconfig file at the root of the hosting, through the app.engine.version key. At Hostinger, the setting is in the PHP configuration of the site’s dashboard, and new sites start on PHP 8.3.
Hosts that upgrade for you
Some managed hosts change the version for you. At Kinsta, automatic PHP updates are on by default, and a site on a stopped version moves to the latest supported one. SiteGround applies the same principle with its Managed PHP option, on by default, as long as you have not picked a version by hand.
WordPress VIP imposes a yearly update on its customers: production will move to PHP 8.3 on December 7, 2026, before PHP 8.2 ends. If your host runs such switches, ask for the date and test your site before it.
Paid extended support
Keeping an old version now has a price. At the time of writing, in October 2026, DreamHost charges for its PHP extended support from $5 a month for one site, noting that it does not improve performance. IONOS’s US page lists $15.62 a month for PHP 7.4 or 8.0. With cPanel and Plesk, stopped versions go through a paid TuxCare support license. These offers buy time, without solving the problem.
OPcache and JIT: what really speeds up PHP
OPcache, the cache that matters
On every request, PHP has to read and compile WordPress’s files. OPcache keeps that compiled code in memory and avoids the work. It differs from the object cache, such as Redis, which keeps the results of database queries: our guide to the Redis object cache explains the difference.
Since WordPress 7.0, the Site Health screen checks that OPcache is on and flags it if not. Since PHP 8.5, OPcache is part of PHP itself, always loaded, and all you have to do is not disable it.
The Hosting Handbook advises tuning its memory and file count, and clearing the cache on every deployment if file timestamp checks are turned off. WordPress invalidates the files it updates itself, since version 5.5.
JIT, rarely useful for WordPress
The JIT compiler, introduced with PHP 8.0, turns part of the code into machine instructions. PHP 8.0’s own release page said typical applications perform on par with PHP 7.4: JIT mostly helps intensive computation and long-running processes. It has never been active by default: before PHP 8.4 its buffer size defaulted to zero, and since PHP 8.4 the opcache.jit setting defaults to “disable”.
What a recent version delivers
Speed gains exist, but they are modest. Kinsta measured a default WordPress install: about 6.6% more requests per second between PHP 7.4 and PHP 8.5. On a WooCommerce product listing page, PHP 8.2 served about 23% more requests than PHP 7.4.
The same test shows a much bigger jump on PHP 8.5, but with a page about 38% smaller (53.5 KB vs. 86.8 KB), which Kinsta attributes to changes in output structure. That figure therefore does not measure the engine. Changing PHP version is first about staying patched, and speed comes as a bonus.
Summary table
| PHP version | Status at php.net | WordPress 7.1 | WooCommerce 11.6 | Verdict |
|---|---|---|---|---|
| 7.4 and 8.0 | Stopped | Compatible | No | Leave without delay |
| 8.1 | Stopped end of 2025 | Compatible | Minimum | Leave |
| 8.2 | Security until end of 2026 | Compatible | Yes | Plan the upgrade |
| 8.3 | Security until end of 2027 | Recommended | Recommended | Safe choice |
| 8.4 | Active, security until end of 2028 | Recommended | Yes | Best production choice |
| 8.5 | Active, security until end of 2029 | Recommended | Yes | Possible, after testing plugins |
Frequently asked questions
Can I stay on PHP 7.4?
WordPress 7.1 still accepts it, but PHP 7.4 has received no fixes since November 2022, WordPress already warns that it will soon stop supporting it, and WooCommerce drops it in February 2027. Staying on 7.4 postpones a migration that will only get harder.
Is PHP 8.5 safe for WordPress?
Core fully supports it since WordPress 6.9, and the beta label disappeared in May 2026. The risk comes from plugins and themes: test them on a copy before switching.
Does moving to PHP 8 speed up my site?
A little. Published measurements show a few percent on a standard install, more on some WooCommerce pages. For speed, check OPcache, page caching and object caching first.
Can my host change the version without asking me?
Yes, at some managed hosts, including Kinsta and SiteGround, when the option is on. SiteGround and WordPress VIP announced their switches in advance. Ask for their policy, and test your site before the announced date.
What should I do if a plugin breaks after the switch?
Go back to the old PHP version in the panel, read the debug log to identify the plugin, then look for an update or a replacement. Also check when it was last updated: a plugin that no longer keeps up with PHP versions deserves to be replaced.
Should I enable JIT?
For a WordPress site, rarely. JIT helps intensive computation, not ordinary web pages, and it is not active by default. Check instead that OPcache is on and properly sized.
Conclusion
The right PHP version is the most recent one your plugins support, within php.net’s calendar, well above WordPress’s minimum. In October 2026, that means PHP 8.3 at least, PHP 8.4 preferably, and an upgrade planned before PHP 8.2 ends.
The method does not change from one version to the next: identify the most demanding component, test on a copy with the journeys that matter, switch, monitor. Add the PHP check to your WordPress maintenance checklist, at least once a year.
Sources
- WordPress.org (May 7, 2026). Requirements
- Make WordPress Core Handbook (August 2026). PHP Compatibility and WordPress Versions
- PHP Group. Supported Versions
- PHP Group. Unsupported Branches
- WordPress.org. Stats
- Make WordPress Core, John Blackbourn (January 9, 2026). Dropping support for PHP 7.2 and 7.3
- Make WordPress Core (May 22, 2026). PHP support clarification, spring 2026 edition
- Make WordPress Core (September 3, 2026). WordCamp US 2026: PHP conversation
- Make WordPress Hosting Handbook (September 2026). Server Environment
- Make WordPress Hosting Handbook (September 2026). Performance
- WordPress.org. Get a faster, more secure website: update your PHP today
- GitHub, WordPress (February 11, 2026). Site Health: Add test and debug data for Opcode Cache
- PHP Wiki, Jakub Zelenka and Derick Rethans (2024). RFC: Release cycle update
- PHP Wiki. PHP 8.6 release timetable
- PHP Group (November 2025). PHP 8.5 Release
- PHP Group (November 2020). PHP 8.0 Release
- PHP Manual. OPcache runtime configuration
- PHP Manual. Migrating to PHP 8.5: backward incompatible changes
- GitHub, PHPCompatibility. PHPCompatibilityWP
- WordPress.org Plugins. PHP Compatibility Checker
- WordPress VIP Documentation. PHPCS scans for PHP version compatibility
- WordPress VIP Documentation. Static analysis
- WordPress Developer Resources. Debugging in WordPress
- WP-CLI. wp cli info
- WordPress.org Plugins. Query Monitor
- WooCommerce Developer Blog (June 5, 2023). New Requirement for WooCommerce 8.2: PHP 7.4+
- WooCommerce Developer Blog, Brian Coords (September 8, 2026). Proposed change: Requiring PHP 8.1 or newer for WooCommerce 11.5 and beyond
- WooCommerce Developer Blog, Brian Coords (September 29, 2026). New Requirement for WooCommerce 11.6: PHP 8.1+
- GitHub, WooCommerce (September 30, 2026). Add an admin notice about the upcoming change in PHP requirements (PHP 8.1)
- WooCommerce Developer Docs. Security Patch Support Policy
- SiteGround, Daniel Kanchev (November 5, 2024). Seamless Update for Millions of Sites to PHP 8.2
- SiteGround Knowledge Base. What Is Managed PHP Service and How to Enable It?
- WordPress VIP, Amanda Podgorny (January 21, 2026). Planning your 2026 PHP 8.3 Update
- cPanel Documentation. MultiPHP Manager for cPanel
- Plesk Obsidian Documentation. PHP Settings
- OVHcloud (July 2026). Hébergement web – Environnement, version PHP, « .ovhconfig »
- Hostinger Help Center. How to change the PHP version of your Hostinger hosting plan
- Kinsta Docs. MyKinsta Tools
- DreamHost. PHP Extended Support
- IONOS. PHP Extended Support
- Kinsta, Joel Olawanle (December 2025). PHP 8.5 benchmarks
- cPanel Documentation. MultiPHP Manager for WHM
- Plesk Obsidian Documentation. Securing Outdated PHP Versions
- WordPress.org. Releases
- Make WordPress Core (September 18, 2026). Roadmap to 7.2
- WordPress Developer Resources. wp_get_environment_type()
- WordPress Developer Resources. wp_opcache_invalidate()
- PHP Manual. Migrating to PHP 8.0: backward incompatible changes
- PHP Manual. Migrating to PHP 8.1: deprecated features
- PHP Manual. Migrating to PHP 8.2: deprecated features
- PHP Manual. Migrating to PHP 8.4: deprecated features
LaFactory designs, builds and maintains WordPress and WooCommerce sites, and develops its own plugins. Talk to us about your WordPress project.