WooCommerce stores need a PHP upgrade plan

WooCommerce stores need more than an update button.

They need a PHP upgrade plan.

On September 8, 2026, the WooCommerce engineering team published a proposal to require PHP 8.1 or newer for WooCommerce 11.5 and beyond. The post says WooCommerce 11.5 is currently targeted for January 2027, and that the change would end support for PHP 7.4 and PHP 8.0 in future WooCommerce versions.

This is still a proposal, not a completed release. That distinction matters.

It also means there is time to act calmly.

For small and medium businesses, the issue is not simply whether the store can reach PHP 8.1. The better commercial question is whether the store is running on a modern, supported hosting stack with extensions, theme code, checkout, shipping, payments, emails and reporting all tested together.

That is why this is consequential.

WooCommerce is not usually a decorative part of a website. It is where revenue, stock, customer accounts, fulfilment and finance workflows meet. A platform requirement change can expose old hosting, abandoned extensions, custom snippets and fragile update habits that were already creating risk.

What changed

WooCommerce is proposing to raise its minimum PHP requirement from older versions to PHP 8.1 or newer, starting with WooCommerce 11.5.

The official post says PHP 7.4 and PHP 8.0 are no longer supported by the PHP project. It also says stores that do not meet the proposed PHP requirement would not be automatically upgraded to a WooCommerce version requiring PHP 8.1. WordPress would normally prevent the incompatible update from being offered, and the store would remain on the latest WooCommerce release compatible with its environment, subject to WooCommerce's support policy.

That sounds protective, and it is useful protection.

It should not be mistaken for a strategy.

If a store remains on older PHP, it may avoid one incompatible update today while slowly falling behind the current WooCommerce branch. That affects more than engineering tidiness. It can narrow the path for future security fixes, payment extension updates, shipping integrations, analytics plugins and support from hosting providers or developers.

There is another important detail.

The PHP project's supported versions page shows which PHP branches are actively supported, which are receiving security fixes only and which have reached end of life. As of September 14, 2026, that page lists PHP 8.2, 8.3, 8.4 and 8.5 as the currently supported branches. PHP 8.1 no longer appears in the currently supported table.

So the practical target should not be, "Can we barely satisfy WooCommerce 11.5?"

The practical target should be, "Can this store move to a currently supported PHP branch with confidence?"

WordPress's own requirements page also recommends PHP 8.3 or greater for a modern hosting environment, while noting that WordPress can still run on PHP 7.4 or newer. That difference between "can run" and "should run" is exactly where business risk tends to hide.

Why this matters commercially

An ecommerce store depends on many moving parts that are easy to underestimate.

There is WordPress core. There is WooCommerce. There is the theme. There are payment gateways, tax settings, shipping methods, product feeds, email delivery, subscriptions, memberships, discount plugins, fulfilment integrations, analytics tags and sometimes custom code written years ago.

PHP sits underneath all of that.

When PHP changes, the question is not only whether the homepage loads. The question is whether the store can still take money, calculate freight, apply the right tax, send order emails, sync with operations and let customers manage their accounts.

That makes the upgrade a commercial planning issue.

A business that discovers PHP incompatibility during a normal week can test, choose, schedule and document the change. A business that discovers it during a peak sales period, campaign launch, fulfilment push or security incident has fewer good options.

The cost of waiting is uncertainty.

Uncertainty shows up as nervous updates, delayed plugin changes, unclear hosting responsibility and avoidable downtime risk. It also creates a quiet dependency on whatever old stack happens to be working today.

For a store that materially contributes to revenue, that is not a healthy operating model.

Who is affected

The first group is any WooCommerce store still running PHP 7.4 or PHP 8.0.

The second group is stores already beyond those versions but not yet tested on a currently supported PHP branch. Passing the proposed minimum is not the same as having a clean upgrade path.

The third group is businesses with older WooCommerce customisation:

• custom themes with template overrides;
• snippets in theme files or plugin files;
• bespoke checkout, shipping or pricing logic;
• older payment, subscription, membership or booking extensions;
• custom integrations with accounting, fulfilment, CRM or stock systems;
• hosting accounts where PHP versions are controlled by a panel, agency or provider rather than the business.

Agencies and consultants maintaining WooCommerce sites should treat this as portfolio level work. The task is not only to update one store. It is to identify which clients are on older PHP, which stores are commercially sensitive and which extension combinations need staged testing before January 2027.

This also affects businesses that are planning a website redesign or ecommerce rebuild.

If a store is already due for serious improvement, PHP readiness should be part of the decision. Sometimes the right answer is a controlled upgrade. Sometimes it is a broader Website Development project because the store has outgrown its current theme, checkout flow or plugin architecture.

What businesses should do now

Start with a small inventory.

Record the current PHP version, WordPress version, WooCommerce version, active theme, active plugins, payment gateways, shipping methods, tax tools, key integrations and any custom code. Include who controls hosting and who can change the PHP version.

Then check the destination.

Ask the host which currently supported PHP versions are available, and whether the production account can run a staging environment on the target version first. Do not assume that because a host offers a newer PHP branch somewhere, this exact account can use it cleanly.

Then test the real store.

A useful WooCommerce upgrade test should include:

• product browsing and search;
• cart and checkout;
• payment authorisation and failed payment handling;
• shipping rates and tax calculations;
• coupon and promotion logic;
• order confirmation emails;
• customer account login and password reset;
• refunds, cancellations and status changes;
• subscriptions, memberships or bookings where relevant;
• analytics, pixels, product feeds and fulfilment integrations.

The test should also include the operational paths that staff use. Many store failures are discovered in the admin area after the front end appears fine.

Then remove what is no longer needed.

Old extensions increase the testing surface. If a plugin was installed for an old campaign, inactive feature or one time workaround, keeping it may make the PHP upgrade harder than it needs to be.

Then schedule the production change.

Choose a low risk trading window. Confirm backups. Confirm rollback steps. Confirm who is responsible for checking orders after the change. Confirm what will be considered a failure that requires rollback.

This is routine Website Growth & Care work when the site is treated as a live commercial system rather than a finished project.

Where technical judgement is required

The judgement is rarely in clicking the PHP selector.

It is in deciding what to do when the test is not clean.

If an extension fails on a supported PHP branch, should it be replaced, patched, isolated or temporarily held back? The answer depends on what the extension does, whether it affects revenue, whether the vendor is active and how close the business is to a peak trading period.

If a custom checkout rule fails, should the code be repaired inside the current store or should the workflow be simplified? That depends on whether the rule still reflects how the business operates.

If the host cannot provide a suitable PHP branch, should the store move host before the WooCommerce requirement arrives? That depends on data size, email setup, DNS control, CDN configuration, performance needs and acceptable downtime.

If the store passes PHP 8.1 but fails on a currently supported branch, should the business stop at the minimum? Sometimes a short holding position is reasonable. It should be recorded as a deliberate risk, not treated as the destination.

This is where a focused Website Audit can be valuable. The audit should separate immediate compatibility work from larger architectural decisions. It should tell the business which parts of the store are healthy, which parts are fragile and which decisions deserve investment before the next platform shift.

Why minimum requirements can reveal old decisions

Minimum requirement changes are useful because they force hidden assumptions into view.

A store may have been running on an older PHP version because nobody wanted to disturb a fragile checkout. It may depend on an extension that has not been seriously maintained. It may carry custom code that works only because the hosting environment has not changed. It may have a staging site that no longer resembles production.

None of those conditions are unusual.

They are common in stores that have grown incrementally.

The problem is not that the business made imperfect decisions in the past. The problem is letting those decisions remain invisible until an update, security advisory or payment provider change turns them into an urgent constraint.

A good upgrade plan turns the problem around.

It uses the WooCommerce PHP proposal as a reason to understand the store better. It improves the maintenance rhythm. It removes unnecessary plugins. It clarifies hosting responsibility. It gives the business a cleaner map of how revenue moves through the website.

That is more useful than treating the announcement as another technical chore.

The practical path

The practical path is straightforward, but it needs ownership.

1. Confirm whether the store is on PHP 7.4, PHP 8.0, PHP 8.1 or a currently supported branch.
2. Confirm the host can provide the target PHP version in staging and production.
3. Update WooCommerce, extensions and theme code in a controlled staging environment.
4. Test checkout, payments, shipping, tax, email, accounts, fulfilment and reporting.
5. Review old customisations and remove unnecessary plugins.
6. Schedule the production upgrade outside a high risk trading window.
7. Record the decision, the tested version, the checks completed and any deferred risks.

For some businesses, this is a tidy maintenance task. For others, it will reveal that the store needs deeper technical direction.

That deeper direction is often where a Fractional Technical Partner helps. The value is not only knowing which PHP version to select. It is understanding how the website, hosting, integrations and commercial workflow fit together, then choosing the smallest responsible path.

WooCommerce stores do not need to wait for the requirement to become urgent.

They need a clear view of where they are running today, a tested path to a supported stack and enough technical ownership that the next platform change does not arrive as a surprise.