WooCommerce PHP upgrade audit

WooCommerce PHP upgrades are not ordinary WordPress maintenance. A brochure site can break visibly. A store can break quietly: checkout still loads, but a payment callback fails; subscriptions renew twice; tax rules change; order emails stop; a custom shipping plugin throws warnings only for one country.

Source facts last checked May 3, 2026: WordPress hosting requirements and WordPress PHP compatibility notes. WordPress currently recommends PHP 8.3 or greater, while still noting that older minimums may work but are EOL and may expose sites to vulnerabilities.

The risk is not only WordPress core. It is the store-specific stack: WooCommerce version, payment gateways, shipping rules, tax plugins, subscriptions, custom theme code, snippets, and the host’s PHP switcher.

1. Map the store before touching PHP

The first audit pass should create a store inventory.

• current PHP version used by web and cron
• WordPress core version
• WooCommerce version
• theme and child theme
• payment gateways
• shipping and tax extensions
• subscription, booking, membership, or multilingual extensions
• custom plugins and snippets
• cron events and action scheduler load
• database size and order volume
• hosting plan and rollback options

For agencies, this is the difference between “we can update PHP” and “we can protect checkout while updating PHP.”

2. Separate core compatibility from ecosystem compatibility

WordPress core compatibility does not guarantee store compatibility.

Check each plugin and theme for:

• declared PHP support
• recent releases
• support forum or changelog signals
• known PHP 8.2/8.3/8.4 issues
• abandoned premium licenses
• custom overrides of WooCommerce templates
• direct calls to deprecated PHP behavior

Custom themes are a common source of failure because they often override WooCommerce templates from years ago. A PHP upgrade can expose old template assumptions that no plugin scanner will fully understand.

3. Build a checkout-first smoke suite

The minimum useful smoke suite for WooCommerce is not “homepage loads.”

Test:

• product page add-to-cart
• cart update
• coupon application
• guest checkout
• logged-in checkout
• payment success callback
• payment failure path
• refund path if used
• order confirmation email
• admin order edit
• subscription renewal or booking workflow if applicable
• tax and shipping calculation for the main regions

Run the suite on the old PHP version first, then on the target PHP version. If a test already fails before the upgrade, it is not an upgrade regression. It is existing risk that needs its own decision.

4. Treat Action Scheduler as production-critical

WooCommerce relies heavily on background tasks. Stores with subscriptions, email automation, stock sync, fulfillment, or marketplace integrations often depend on Action Scheduler running cleanly.

Before upgrading PHP:

• inspect pending and failed actions
• check cron reliability
• confirm the real PHP binary used by WP-Cron or server cron
• run a staging copy with scheduled actions disabled or isolated
• test the queue after the PHP switch

Many WooCommerce failures do not appear during manual checkout testing. They appear hours later when queued actions run under the new runtime.

5. Plan rollback around orders

Rollback for a store is different because the database changes every minute.

Define:

• whether maintenance mode is needed
• how orders are paused or reconciled
• final backup point before the switch
• plugin/theme rollback method
• PHP version rollback method
• payment gateway webhook behavior during rollback
• how failed orders are identified and repaired

For high-volume stores, use a staging rehearsal and a low-traffic cutover window. For smaller stores, a short, explicit checkout freeze can be safer than accepting live orders during a risky switch.

6. Keep the agency conversation commercial

The useful deliverable for an agency is a quoteable risk register:

• blockers before PHP can move
• plugins that need replacement
• custom theme fixes
• checkout smoke tests
• rollback plan
• estimated upgrade sequence
• clear “do now” versus “do later” actions

That is why a white-label WordPress audit usually comes before the upgrade quote. It gives the agency a defensible plan without making them guess in front of the client.

When to audit first

Start with an audit when the store has subscriptions, custom checkout code, old payment plugins, heavy plugin count, no staging, untested backups, or a host notice forcing a PHP version change.

The audit should answer a narrow question: what must be true before this store can move to a supported PHP version without risking checkout, orders, and payment callbacks?