Confirmed requirement: September 30, 2026
WooCommerce has confirmed PHP 8.1 or newer for WooCommerce 11.6, planned for February 2027. Its September 29, 2026 advisory replaces the earlier 11.5 proposal. A planned 11.3 notice warns stores on PHP 7.4 or 8.0 about the future requirement; it does not make those runtimes incompatible with 11.3.
WooCommerce recommends PHP 8.3 or newer for an updated environment. The minimum is not a recommendation to choose an unsupported runtime. Read the confirmed requirement advisory, then select a currently supported version that your host and essential extensions can run.
What the future notice changes
The advisory identifies 11.5 as the last planned compatible release for PHP 7.4 and 8.0. This is a preparation window, not a reason to postpone all maintenance or assume permanent security coverage. The requirement does not automatically deactivate an existing installation or upgrade the host runtime. This page keeps its original URL so earlier links continue to reach the corrected guidance.
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.
Check PHP's live supported-version table and the host's available runtimes before choosing a destination. 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 compatibility 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. Give the maintainer a concrete compatibility blocker. 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 release notes before the planned 11.6 upgrade.
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 confirmed PHP requirement. PHP supported versions.