WooCommerce Is Dropping PHP 7.4 and 8.0: What Store Owners Need to Do

If your store still runs on PHP 7.4 or 8.0, a quiet post on the WooCommerce developer blog has just started a clock. On 8 September 2026, WooCommerce engineer Brian Coords published a proposal to raise WooCommerce’s minimum PHP requirement to PHP 8.1 or newer, beginning with WooCommerce 11.5 — currently targeted for January 2027. Nothing breaks the day it ships. But from that release onward, stores on older PHP simply stop being offered new WooCommerce versions, and that includes the security and compatibility work that lands in them.

This guide covers what is actually being proposed, how to tell in about sixty seconds whether your store is affected, and — the part most coverage is missing — why upgrading to PHP 8.1 itself would be close to a wasted afternoon.

Quick answer

• What is changing: WooCommerce proposes requiring PHP 8.1+ from version 11.5 onward, ending support for PHP 7.4 and 8.0.
• When: WooCommerce 11.5 is targeted for January 2027. This is still a proposal open to feedback, not a confirmed release requirement.
• Who is affected: Roughly 9% of WooCommerce stores in the project’s own opt-in telemetry — but WordPress.org’s automatic stats suggest the real figure across WordPress is far higher.
• What happens if you do nothing: Your store keeps running. WordPress will simply stop offering the WooCommerce 11.5 update, and you stay on your current branch.
• What to actually do: Do not upgrade to PHP 8.1 — it reached end of life on 31 December 2025. Go to PHP 8.3 or 8.4.

What WooCommerce is actually proposing

The proposal is narrow and specific. WooCommerce 11.5 would declare Requires PHP: 8.1 in its plugin header. WordPress reads that header and, by default, refuses to offer an update to any site that does not meet it. The practical consequences are worth stating plainly, because the announcement is less dramatic than the headline suggests.

A store on PHP 7.4 or 8.0 will not be force-upgraded, will not be deactivated, and will not break. It continues running whatever WooCommerce version it has, and it continues to receive dot releases on that branch. What it loses is the forward path: no 11.5, and nothing after it, until PHP is upgraded.

WooCommerce has done this before. Version 8.2 raised the minimum to PHP 7.4 using the same mechanism and the same advance-notice approach. The stated reasons this time are familiar: PHP 7.4 and 8.0 no longer receive security fixes from the PHP project, modern language features (union types, attributes, null-safe operators, match, named arguments) are unavailable while the floor stays low, newer and more secure dependency packages have already dropped those versions, and every extra PHP version in the test matrix slows continuous integration and releases.

One point deserves emphasis because it is easy to misread: WooCommerce’s minimum has never been tied to WordPress’s. WordPress core still runs on PHP 7.4 and recommends 8.3 or greater. WooCommerce has historically sat ahead of core, on the reasoning that an ecommerce application carries dependencies and performance requirements a content platform does not.

How many stores are actually affected?

This is where the proposal gets genuinely contested, and where store owners should pay attention rather than skim.

WooCommerce’s own figures come from opt-in usage tracking: approximately 7% of tracked stores on PHP 7.4 and approximately 2% on PHP 8.0. Among stores that have updated WooCommerce within the past year, the combined figure drops to roughly 6% and is trending down. The post is candid that opt-in tracking is a sample, not a census.

WordPress.org publishes a different kind of number. Its statistics come from non-identifying telemetry sent automatically whenever a site checks for updates — no opt-in required. At the time of writing, those stats show PHP 7.4 at 17.27% and PHP 8.0 at 4.13% of all WordPress installs. That is 21.4% combined, more than double WooCommerce’s sampled figure.

Both numbers can be true at once. WooCommerce stores skew toward commerce-grade hosting, which tends to keep PHP current, and the stores most likely to enable usage tracking are the ones most likely to be actively maintained. That is precisely the selection bias critics raised in the post’s comments. The honest reading is that the affected population is somewhere between 6% and 21%, and that the lower bound describes well-maintained stores while the upper bound describes the long tail of neglected ones. If you are reading an article about PHP requirements, you are probably not in the long tail — but the client site you inherited two years ago might be.

The catch nobody mentions: PHP 8.1 is already end of life

Here is the detail that should change what you actually do. PHP 8.1 reached end of life on 31 December 2025. By the time WooCommerce 11.5 ships in January 2027, the proposed new minimum will have been unsupported for roughly thirteen months.

It gets tighter. PHP 8.2’s security support ends on 31 December 2026 — the month before 11.5’s target date. So of the versions that would satisfy the new requirement, two are already dead or dying on arrival. Several commenters on the original proposal made exactly this point, and a WooCommerce engineer replying in the thread confirmed the approach: minimums are set by usage data rather than by upstream support dates, PHP 8.1 currently sits around 11% usage, and a bump to 8.2 would be considered once 8.1 drops toward 5%. The same reply restated that WooCommerce officially recommends at least PHP 8.3.

Treat 8.1 as a compliance floor, not a target. Here is the full support picture as published by the PHP project:

If you are going to schedule downtime, test extensions and coordinate with a host, do it once and land on 8.3 or 8.4. Upgrading to 8.1 buys you compliance with a requirement that has not been finalised, and commits you to repeating the entire exercise within a year.

How to check your store’s PHP version

You do not need a plugin or shell access. WordPress reports this natively.

1. In your WordPress admin, go to Tools → Site Health → Info.
2. Expand the Server panel.
3. Read the PHP version row. That is the number that matters.
4. While you are there, check WooCommerce → Status for the PHP version WooCommerce itself detects, plus your current WooCommerce version and any extensions flagged as outdated.

If Site Health shows 8.3 or higher, you can close this article — you are already clear, and no action is required. If it shows 7.4 or 8.0, you have roughly four months of comfortable lead time before the target release, and that is more than enough if you start now rather than in January.

How to upgrade PHP without breaking your store

The PHP switch itself is usually a dropdown in your hosting control panel and takes under a minute. The work is everything around it. Our walkthrough on how to update the PHP version in WordPress covers the mechanics for most hosts; the sequence below is the store-specific version.

1. Inventory your extensions first. List every paid and custom plugin, then check each developer’s stated PHP compatibility. Abandoned premium extensions are the single most common blocker, and the one with the longest lead time to resolve.
2. Clone to staging. Never test a PHP jump on production. If your host does not offer one-click staging, our guide to setting up a WordPress staging site covers three approaches.
3. Raise PHP on staging and enable error logging. Set WP_DEBUG_LOG to true. PHP 8 converts many previously silent notices into fatal errors, so a clean-looking front page is not proof of success.
4. Exercise the money paths. Add to cart, apply a coupon, run a test checkout on every active gateway, trigger an order email, process a refund, and run any subscription or booking renewal you depend on. Admin-side, test order editing, bulk actions and your reports.
5. Read the log, not the screen. Deprecation warnings are survivable; fatals are not. Fix or replace whatever throws fatals before going near production.
6. Schedule production for your quietest hour, take a full backup first, and keep the previous PHP version selectable so you can roll back in seconds.

Once PHP is current, the WooCommerce update itself follows the usual discipline — our guide on updating WooCommerce safely without breaking your store covers the order of operations.

Common mistakes

• Upgrading to exactly 8.1. Covered above, and worth repeating because it is the most likely error this announcement will cause.
• Testing only the storefront. Most PHP 8 fatals in WooCommerce stores surface in checkout, gateway callbacks and admin order screens — not on the shop page.
• Upgrading during BFCM. Several commenters flagged January as awkwardly close to peak season. Either move well before Black Friday or wait until trading calms in late January.
• Assuming your host already handled it. Many hosts upgrade the PHP available to you without changing the version your site is pinned to.
• Treating a proposal as final. The target release and minimum version are explicitly still under review.

Advanced considerations

The LTS backport argument

One objection raised in the comments is that PHP 7.4 still receives backported security fixes in some long-term-support distributions — Ubuntu’s extended maintenance offerings being the usual example. That is accurate, and it means “7.4 is unpatched” is too blunt a claim for every environment. It does not change the outcome, though: WooCommerce reads the version string, not your distribution’s support contract. A backported 7.4 still reports 7.4 and will still be gated out of 11.5.

For agencies and extension developers

If you maintain extensions, the practical question is whether to branch. Targeting WooCommerce 11.5+ lets you use the full 8.1 feature set and drop compatibility shims; continuing to support older WooCommerce versions means maintaining separate code paths or conditional loading. The proposal explicitly invites this feedback, and the comment thread is where hosting providers and agencies are supplying usage data that may move the final number.

For agencies running fleets, the useful move is an audit now rather than a migration now: record PHP version, WooCommerce version and blocking extensions per site, then sort by difficulty. The sites that need a replacement for an abandoned premium plugin are the ones that need four months, not four hours.

Security framing

Running an unsupported PHP version is not an abstract risk for a store that processes card data and holds customer records. Unsupported runtimes accumulate unpatched vulnerabilities indefinitely, and no amount of plugin-level hardening compensates for the layer underneath — a point we have made before about why antivirus alone will not protect your website. If your host cannot offer PHP 8.3 or newer, that is a hosting problem rather than a WooCommerce problem, and worth weighing against fully managed WordPress hosting options that keep the stack current for you.

Frequently asked questions

Will my store stop working in January 2027?

No. Nothing deactivates, and no update is forced. You stay on your current WooCommerce version and keep receiving dot releases for that branch. You simply will not be offered 11.5.

Is this definitely happening?

Not yet. It is a published proposal with an open feedback period. WooCommerce has said it will review feedback and usage data before confirming both the target release and the minimum version. The direction is not seriously in doubt; the exact version and date are.

Should I jump straight to PHP 8.4 or 8.5?

8.4 is the best default for most stores — actively supported until the end of 2028, with broad extension compatibility. 8.5 is fine if your extensions confirm support, but it is new enough that some commercial plugins have not certified it. 8.3 is the conservative floor.

Does WordPress itself require PHP 8.1 now?

No. WordPress core still runs on PHP 7.4 and recommends 8.3 or greater. WooCommerce’s minimum is set independently and has historically been higher.

How long does the upgrade actually take?

The switch is a dropdown and takes seconds. Testing is the real cost: budget an hour for a simple store with mainstream plugins, and anywhere from a day to several weeks if you rely on custom code or abandoned premium extensions.

What to do this week

Open Tools → Site Health → Info → Server and read your PHP version. If it starts with 8.3 or higher, you are done. If it does not, put ninety minutes in the calendar this month to inventory your extensions and clone to staging — that single step converts a January emergency into a routine maintenance task. And whatever you do, skip 8.1 and land on 8.3 or 8.4.

If you maintain client stores, the comment thread on the original proposal is still open, and hosting providers with real usage data are the participants most likely to influence where the minimum finally lands.

Sources

• Proposed change: Requiring PHP 8.1 or newer for WooCommerce 11.5 and beyond — WooCommerce Developer Blog, 8 September 2026 (including the public comment thread)
• PHP: Supported Versions and PHP: Unsupported Branches — the PHP Group
• WordPress.org Statistics — PHP version distribution across WordPress installs
• WordPress Requirements — current minimum and recommended PHP versions

Verified 17 September 2026. PHP support dates, WordPress.org usage statistics and the status of the WooCommerce 11.5 proposal all change over time — the proposal in particular is open to feedback and its target release and minimum version have not been finalised. Check the linked sources before acting on specific dates or percentages.