Quick answer
As checked on September 13, 2026, WooCommerce has proposed requiring PHP 8.1 or newer starting with WooCommerce 11.5, currently targeted for January 2027. This is a proposal, not a finalized release requirement. Inventory your store and test a supported, compatible runtime now rather than switching production blindly to the minimum named in the announcement.
Separate the proposal from today's installation
The September 8 developer announcement asks for feedback before confirming the target release and minimum version. It says the proposed change would not upgrade PHP on the store's behalf or automatically deactivate the existing WooCommerce installation. Keep that distinction clear when explaining the work to a merchant.
Do not promise indefinite support for an old branch either. Record the installed WooCommerce version, PHP version, and current vendor support policy. Recheck the official announcement and final release notes before scheduling any requirement-driven change. A proposed future date is useful planning context, not proof that an update is blocked today.
Do not confuse minimum compatibility with a good target
A plugin's minimum PHP version describes a compatibility floor. It does not mean that version has the best remaining upstream support window. PHP's supported-versions page lists branch support periods separately from WordPress or WooCommerce compatibility. Check both before choosing a destination.
As of this review, PHP's current supported table lists 8.2 through 8.5, with different remaining support windows. Choose a version supported by the host and by the store's essential extensions, then prove it on staging. Do not downgrade a healthy supported environment simply to match the proposed minimum.
Inventory the components that can block the move
List the payment gateway, subscriptions, tax, shipping, accounting export, product customization, theme, must-use plugins, and custom snippets. For each, record the installed version, maintainer, compatibility evidence, and an actual test case. A plugin header alone is weaker evidence than a successful run of the store's critical workflow.
Include the web server runtime, command-line runtime, and scheduled-job runtime. A host control panel can change one without changing the others. Record required PHP extensions and relevant configuration as well. A missing extension or different execution environment can break an integration even when the major PHP version appears correct.
Build a staging checkout matrix
Use a recent staging copy with production secrets replaced or contained, gateway test mode, and outbound customer messages captured. Test guest and logged-in purchases, the main product types, shipping and tax calculations, coupon behavior, order confirmation, and the merchant's most important integration.
Where subscriptions or scheduled tasks matter, test those paths deliberately rather than waiting for the checkout screen to load. Verify the resulting order or subscription state, not just the browser success page. Include a failure case so declined payments and validation errors still produce the expected safe outcome.
- Purchase: correct totals, payment state, and confirmation.
- Refund or cancellation: expected record changes without duplicate actions.
- Scheduled work: correct runtime and one intended execution.
- Admin operations: product editing, exports, and order management still work.
Record failures in a way the vendor can use
For a failure, capture the component version, PHP version, exact action, expected result, and a redacted error trace. Separate fatal errors from warnings and deprecations, but do not ignore repeated warnings that indicate an unsupported dependency. Keep private payment and customer data out of tickets.
If an essential extension cannot support a suitable runtime, ask the maintainer for a supported release or migration path. The official proposal specifically invites concrete compatibility blockers. A reproducible staging case is more useful than a general statement that the site does not work on newer PHP.
Plan rollback around transactions
Before production change, confirm a restorable backup and the host's runtime rollback procedure. Decide how to preserve orders and payments created during the change window. Restoring an old database over new transactions is not an acceptable generic rollback plan.
Use a controlled change window and monitor checkout, logs, scheduled work, and integrations afterward. Keep the old runtime configuration and test evidence available. Close the change only after the business-critical flows pass, and recheck the WooCommerce proposal when the final release target is announced.
Illustrative diagnostic example, not customer measurements.When to bring in help
Ask for WooCommerce runtime compatibility help if the store depends on an extension that blocks a supported PHP version. Bring its version, vendor guidance, a staging error trace, and the affected purchase or renewal flow.
Related troubleshooting
Plan a supported PHP runtime for the whole WordPress site. Compare web and command-line PHP versions.
Helpful references
WooCommerce proposed PHP requirement. PHP supported versions.