WooCommerce 11.3 Upgrade Checks: Checkout Sessions, Analytics Backfills, and Cart Counts

Prerelease guidance, checked October 31, 2026. WooCommerce’s October 26 announcement makes 11.3 available for beta testing and targets the week of November 9 for release. The results here concern 11.3.0-beta.1; they are not final-release compatibility certification.

Use a disposable or staging store with dummy data. Record WordPress, WooCommerce, PHP, theme and extension versions before changing anything. Keep a stable control so a broken lab route or an existing warning cannot be mistaken for a beta regression. Retest the actual stable package before a production rollout.

The official advisory says a logged-in customer’s is_vat_exempt and calculated_shipping session values persist after account saves in 11.3. Custom exemption logic must explicitly clear an exemption when eligibility changes, rather than relying on an account save to reset it.

For a store with custom tax logic, ask its developer to compare eligible and ineligible test customers on staging. Change an address or another relevant eligibility input, save it, and compare tax and shipping results. Exercise both the checkout type used by the store and any retry flow supported by its gateway’s sandbox. Record expected values before the test; retained session data is not itself proof that the totals are correct.

Coverage limit: Cobalt’s October 31 checks did not exercise an authenticated declined-payment/VAT retry. Do not interpret our local diagnostic results as validation of that payment journey. If investigating an order awaiting payment, use the separate Pending payment checklist and reconcile gateway evidence before requesting another payment.

WooCommerce 11.3 adds payment-method reporting to Analytics Orders. Its wc_order_stats backfill uses Action Scheduler in batches of 500 orders. New payment-method values may remain empty until the background work runs.

On staging, note the relevant action hooks, pending and failed counts, oldest due times, and whether completed work increases between observations. Investigate repeated failures or a queue that stops advancing. Do not delete migration actions simply to remove a warning. For a large store, plan an upgrade window and a database backup/restore procedure with the host.

What our lab observed: the upgrade ran wc_update_1130_backfill_order_stats_payment_method. Cobalt Checkout Diagnostics moved from warning to fail while work was overdue, then returned to pass after the queue progressed. That finding describes backlog state; it does not establish why an individual checkout failed. CacheSafe’s upgrade checks also observed the migration and a successful subsequent scan.

Keep the before/after queue evidence with your upgrade record. If a warning clears after normal processing, report the recovery rather than presenting a transient backlog as a permanent compatibility failure.

The October 27 cart relationship advisory introduces the read-only Store API field parent_item_key and filter woocommerce_store_api_cart_item_parent_item_key. Extensions can identify child items so Product Button counts exclude them. Repeated product lines are aggregated. A missing or invalid parent gives a null relationship.

If the store uses bundles or another extension that adds companion products, compare the product button, complete cart contents and payable totals. Test removing the parent and adding the same product independently. Ask the extension maintainer about adoption of the new relationship filter; do not add a guessed relationship based only on a product ID.

What our lab observed: CacheSafe accepted both null and a non-null parent relationship created with a synthetic fixture using the official filter. This was not a commercial bundle-extension compatibility test. Cobalt Checkout Diagnostics’ totals interpreter tolerated the new field; its non-null parent-cart scenario remained untested. Neither result proves every bundle’s pricing or display is correct.

Each plugin had its own isolated installation and four-cell matrix on PHP 8.3.36: WordPress 7.1.4 with WooCommerce 11.2.1; WordPress 7.2-beta2 with 11.2.1; WordPress 7.1.4 with 11.3.0-beta.1; and WordPress 7.2-beta2 with 11.3.0-beta.1. The initial packaged tests used TranslateGuard 1.0.10, Cobalt Checkout Diagnostics 0.1.5 and CacheSafe 1.0.5.

No beta-specific plugin regression was reported against the stable controls. TranslateGuard’s scans and lifecycle checks passed with Polylang 3.9.1; Polylang for WooCommerce was absent. Checkout Diagnostics passed its local checks and browser run/settings/history flow. CacheSafe’s cart-session probes passed after a disposable rewrite correction.

The work also found a separate CacheSafe 1.0.5 cancellation defect on the stable control with WP-Cron disabled. The 1.0.6 correction passed packaged upgrades on the stable and combined-beta stacks, recovery of a stuck scan, CLI cancellation, and real Live-browser cancellation/completion on pinned Beta 2. This was a cross-version fix, not evidence of an 11.3 regression.

PHP 8.4 runtime coverage was unavailable. TranslateGuard did not have full browser-console capture. CacheSafe’s JavaScript checks were unexecuted because the host had Node 26 while its tooling requires an older supported runtime; the patch changed no shipped JavaScript. A drifted CacheSafe browser attempt was excluded and replaced with a pinned Beta 2 retest. All conclusions remain limited to the recorded fixtures and paths.

• Cobalt Checkout Diagnostics inspects local configuration, rendering evidence, Store API totals and scheduler health. Use its findings to narrow the investigation, then verify the actual customer journey separately.
• CacheSafe runs controlled anonymous-cart probes and provides sanitized evidence about tested session/cache paths. A clean scan does not guarantee every CDN route or customer session is safe.
• TranslateGuard checks Polylang-backed catalog consistency. It does not translate content or certify multilingual checkout behavior.

These are three products. Cobalt Checkout Diagnostics was formerly called Woo Checkout Guard during development; that older name is not a fourth plugin. Our beta results do not change the plugins’ published compatibility metadata.

1. Save the exact version list, checkout architecture and a restorable staging backup.
2. Confirm staging permalinks and REST requests reach the intended installation.
3. Run one baseline diagnostic and preserve its sanitized report.
4. Upgrade the pinned package, observe background migrations, and repeat the same fixtures.
5. Record session/totals behavior, cart contents, scheduler progress and fresh logs.
6. Test a supported gateway sandbox journey separately where payment coverage is required.
7. Repeat on the final WooCommerce release before approving production deployment.

Share reproduction steps and redacted evidence with the responsible maintainer. Exclude customer information, credentials, cookies, Cart-Tokens and nonces. For broader configuration checks, continue with the checkout troubleshooting checklist.