WooCommerce PHP 8.1 Requirement: What Changes in 11.5

The WooCommerce PHP 8.1 requirement now has a date on it: Woo has proposed raising its minimum PHP version to 8.1 starting with WooCommerce 11.5, currently targeted at January 2027. If your store runs PHP 7.4 or 8.0 when that lands, nothing breaks on the day — you simply stop being offered WooCommerce updates, which over a few months is the worse outcome of the two.

Woo published the proposal on 8 September 2026. Their own telemetry puts PHP 7.4 at roughly 7% of tracked stores and PHP 8.0 at roughly 2%, both declining, and they expect the two combined to be near 5% by the release date. That is a small share of stores and a large number of actual shops, and the ones most likely to be on it are the ones least likely to be reading release notes.

What the WooCommerce PHP 8.1 requirement actually says

One change: end support for PHP 7.4 and PHP 8.0 in WooCommerce 11.5 and later, making 8.1 the floor. It is a proposal rather than a shipped decision, and the target date can move. Treat it as a deadline anyway — the direction has never reversed, and WooCommerce’s last two PHP bumps both landed.

There is a gap here that confuses people, so it is worth stating plainly. WooCommerce ships two different numbers today. The plugin header on the current 11.1 release still says Requires PHP: 7.4, which is the version below which WordPress refuses to install it. The server recommendations page already asks for PHP 8.3 or greater, tested up to 8.4. The first number is a hard floor; the second is what Woo actually tests against. The proposal moves the floor closer to the recommendation, nothing more.

Check which PHP version your store is really on

Check it in more than one place, because a server can run several PHP versions at once and frequently does. The version serving your web requests and the version your cron jobs and WP-CLI use are separate settings on most hosts, and a migration that only moves one of them produces a store that works until the nightly job runs.

# The PHP your shell and cron jobs use
php -v

# The PHP WP-CLI is running under, plus the config it loaded
wp --info

# The PHP your web requests use, read through WordPress itself
wp eval 'echo PHP_VERSION;'

If php -v and the System Status screen disagree, you have two PHP installs and a support ticket to raise. On cPanel hosts this is usually the MultiPHP manager setting the web version while the shell keeps the system default; on managed hosts it is normally one setting and a non-issue. Our walkthrough on how to check and update PHP for a WordPress website safely covers the actual switching mechanics per host type.

Why waiting is more expensive than moving

The deadline in the proposal is not the real deadline. PHP 7.4 stopped receiving security patches from the PHP project in late 2022, and 8.0 in late 2023. Running either today already means your interpreter is unpatched; the WooCommerce change just removes the last reason you were getting away with it.

There is a second cost that shows up sooner. Extension authors set their own minimums, and they move ahead of Woo rather than behind it. Stores that sit on an old PHP version tend to discover the problem not at the WooCommerce release but three months earlier, when the payment gateway or the tax extension they depend on ships an update they can no longer install. At that point you are doing an emergency PHP upgrade during a trading week instead of a planned one in January.

And the thing most often cited as the reason to wait — “our site is too complicated to upgrade” — is the reason to start earlier, not later. A complicated store takes longer to test. It does not get simpler by November.

The upgrade path that does not break checkout

1. Write down where you are. PHP version for web and CLI, WooCommerce version, and the full active plugin list with each plugin’s own “Requires PHP” value. The plugin list is the work; everything else is a screenshot.
2. Clone to staging. Not a copy of the theme — a real clone with the database, so you can put test orders through it. If your host cannot give you one, that is a finding about your host, and it belongs in the same conversation as the PHP version.
3. Turn on logging before you switch. You want deprecations written to a file, not displayed to visitors.
4. Switch staging straight to 8.3. Do not step through 8.1 and 8.2 separately. You will test the same order flow three times and learn nothing extra — 8.3 is the recommendation, so make that the thing you test.
5. Walk a complete order lifecycle. Add to cart, apply a coupon, check out with a real gateway in test mode, trigger the confirmation email, refund it partially, export it to whatever you export to. The failures in a PHP upgrade cluster after checkout, not before it.
6. Read the log, then read it again after a day. Scheduled work — renewals, stock syncs, report imports — only runs on its own schedule, so an hour of clicking will not surface it.
7. Switch production in your quietest window, with the old version one dropdown away, and watch the error log for the first full day rather than the first ten minutes.

For step three, this is the configuration you want on staging — and specifically not on production:

// wp-config.php on STAGING only, above "That's all, stop editing!"
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // writes wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Then read it for the two patterns that matter, rather than scrolling the whole file:

# Fatals first — these are the ones that take a page down
grep -n "PHP Fatal error" wp-content/debug.log

# Then deprecations, grouped by the file that caused them
grep -o "Deprecated:.*in /[^ ]*" wp-content/debug.log | sort | uniq -c | sort -rn | head -30

That second command is the useful one. It turns forty thousand log lines into a ranked list of about a dozen files, and the file path tells you which plugin to update or replace. Enabling WordPress debugging and safely reading error logs goes into the logging setup in more detail, including why WP_DEBUG_DISPLAY must be false on anything public.

What actually breaks when you leave PHP 7.4

Core WordPress and core WooCommerce will be fine. The breakage is in third-party extensions and in whatever a developer added to functions.php in 2019. These are the categories worth grepping for before you switch, in rough order of how often they bite.

A plugin with no update in two years and deprecation notices in the log is telling you something about its future, not just its present. Price the replacement now while you have a staging site open. When the cause is not obvious from the log, the normal bisect still works — troubleshooting a WordPress plugin conflict step by step covers doing that without taking a store offline, and a fatal that reaches visitors usually surfaces as a 500 internal server error.

If you genuinely cannot upgrade before 11.5

Sometimes the blocker is real: a bespoke integration whose author is gone, or an ERP connector the business runs on. The honest options are all trade-offs, and the one thing not on the list is doing nothing quietly.

While you have staging open and a tested backup, it is also the cheapest moment to deal with any other deferred infrastructure work — the HPOS migration in particular, since it wants exactly the same staging-and-verify discipline and you are already paying the setup cost.

Frequently asked questions

Sources

• Proposed change: requiring PHP 8.1 or newer for WooCommerce 11.5 and beyond — the WooCommerce Developer Blog post this article is based on, and the source for the 11.5 target, the January 2027 date and the adoption percentages
• WooCommerce server recommendations — the PHP 8.3, MySQL 8.0 and MariaDB 10.6 figures quoted here
• WooCommerce on WordPress.org — the current release and its Requires PHP header value