WooCommerce Is Dropping PHP 7.4

Store owners on older hosting stacks have had a long run. WooCommerce has declared requires_php 7.4 for years, and a proposal published on the WooCommerce developer blog on 8 September 2026 would end that: PHP 8.1 or newer, starting from WooCommerce 11.5, targeted for January 2027.

What the proposal actually says

It is a proposal, not a decision, and the post is explicit about that. The engineering team writes that “we will review the feedback and usage data before confirming the target release and minimum PHP version”, so both the version and the date can still move.

The consequence for stores that cannot move is less dramatic than it sounds. WordPress reads the requires_php header and, in the post’s words, “would prevent the update from being offered to stores that do not meet that requirement”. A store below the floor does not break. It stays on its existing WooCommerce version and continues to receive dot releases on that branch. That is a security maintenance arrangement, not an upgrade path, and it is worse the longer it runs.

The support calendar behind the decision

The argument for the change is not really about WooCommerce. It is about what PHP itself still supports. The php.net supported versions page currently shows only PHP 8.4 and 8.5 in active support. PHP 8.3 and 8.2 receive security fixes only, and 8.2’s security support ends on 31 December 2026. PHP 8.1 and every 7.x release are already end of life.

Read that against the proposal and the shape of it becomes clear: WooCommerce is proposing a floor that is itself unsupported by upstream. That is a concession to the installed base, not an ambitious target. If you are planning the work anyway, plan it to 8.3 or 8.4 rather than to 8.1, because a jump to 8.1 in January 2027 is a jump to a version that has had no security fixes for over a year.

Where your store actually sits

WooCommerce published its own telemetry alongside the proposal. PHP 7.4 accounts for approximately 7% of tracked stores, and PHP 8.0 for approximately 2%. Among stores running a relatively recent WooCommerce version — within the last year — the combined figure is “closer to 6% and trending consistently downward”. The post is careful to note that usage tracking is opt-in, so these are a representative sample rather than a census.

Your own number is the only one that matters, and it takes a minute: Tools, then Site Health, then Info, then the Server panel. WooCommerce also surfaces it under WooCommerce, Status. If that reads 7.4 or 8.0, you have roughly a quarter to act, and the practical constraint is rarely PHP itself. It is a theme nobody has updated, a payment gateway from a vendor that stopped shipping, or a custom plugin written by somebody who has moved on.

What breaks on an 8.1 jump, in practice

The failure modes are consistent enough to check for directly rather than waiting for a fatal error.

• Deprecated dynamic properties. Assigning to an undeclared property on an object emits a deprecation notice from 8.2 and is slated to become an error. Old plugins do this constantly, and on a store with logging enabled it will fill the error log rather than take the site down.
• Passing null to non-nullable internal parameters. Deprecated in 8.1. Functions like trim(), str_replace() and htmlspecialchars() receiving a null from an unset meta value are the common source.
• Removed and abandoned extensions. Anything still reaching for mysql_* functions has been broken for a long time, but abandoned PECL extensions and unmaintained image or PDF libraries are the ones that surface late.
• Stricter type handling in comparisons and string-to-number conversion, which tends to show up as wrong prices or wrong stock counts rather than as an error, and is therefore the one worth testing with real orders.

A staged upgrade that does not take the store down

Clone to staging on the current PHP version first and confirm the clone is actually working, including a test checkout. Then switch staging to the target version with WP_DEBUG_LOG enabled and drive the store rather than browsing it: place an order, process a refund, run a variable product through checkout, trigger every transactional email, and run whatever cron and import jobs the store depends on. Fatal errors will announce themselves; deprecations accumulate in the log and are the real inventory of work.

Fix from that log, in order of severity, and re-run the same script. Only then switch production, out of trading hours, with the ability to roll the PHP version back at the host in one action. Checkout is where this bites hardest, for the same reason it is where checkout flows fail INP: it is the most plugin-dense template on the site. Take the opportunity to check the wider surface too — WooCommerce product page SEO and why large WordPress sites slow down both cover things a staging clone makes easy to measure and production does not.