WooCommerce 11.0.0 RC 2 was published on July 29 after RC 1. A store that passed RC 1 still needs a controlled delta run because a release candidate can change code, package contents, database behavior, and extension interactions close to stable release.
Use this for WooCommerce store owners, agencies, extension teams, and release managers preparing a production upgrade from 10.9.x to WooCommerce 11 after testing an earlier beta or release candidate.
Quick answer
Clone a fresh production snapshot, record the exact RC 2 package and dependency versions, review the RC 1 to RC 2 code delta, then rerun checkout, payment, stock, email, Action Scheduler, refund, analytics, and rollback tests. Do not carry an RC 1 pass forward unless the workflow and all code it touches are unchanged.
What to check first
- Record the production WooCommerce version, RC 1 test result, RC 2 tag, package checksum, WordPress version, PHP version, theme, database mode, object cache, and every checkout-critical extension.
- Compare the RC 1 and RC 2 tags, changed packages, migrations, feature flags, templates, REST behavior, admin assets, and Action Scheduler dependencies before choosing the focused retest set.
- Place test orders through classic checkout and Checkout Blocks with guest, account, coupon, tax, shipping, virtual, failed, delayed, refunded, and subscription-related paths used by the store.
- Reconcile order rows, notes, stock, payment references, customer emails, scheduled actions, webhooks, analytics events, fulfillment exports, and accounting feeds for every fixture.
- Restore the pre-RC snapshot in an isolated recovery target and prove that database, files, caches, queues, and external order side effects can be reconciled without losing a paid order.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze the production baseline | Record the production WooCommerce version, RC 1 test result, RC 2 tag, package checksum, WordPress version, PHP version, theme, database mode, object cache, and every checkout-critical extension. | The installed staging package reports 11.0.0-rc.2 and matches the recorded checksum. |
| Review the RC 2 delta | Compare the RC 1 and RC 2 tags, changed packages, migrations, feature flags, templates, REST behavior, admin assets, and Action Scheduler dependencies before choosing the focused retest set. | Every critical checkout fixture has one order, one payment result, correct stock, expected email, and expected external records. |
| Run revenue workflows | Place test orders through classic checkout and Checkout Blocks with guest, account, coupon, tax, shipping, virtual, failed, delayed, refunded, and subscription-related paths used by the store. | Action Scheduler has no unexplained failed or overdue action tied to the test window. |
| Reconcile all side effects | Reconcile order rows, notes, stock, payment references, customer emails, scheduled actions, webhooks, analytics events, fulfillment exports, and accounting feeds for every fixture. | The release report names pass, block, accepted risk, owner, evidence, monitoring, and rollback criteria. |
Why this usually happens
- A late release candidate can include fixes that touch workflows already tested in RC 1.
- An extension may declare compatibility without covering the store's payment, tax, or fulfillment configuration.
- Background actions can finish after the visible checkout result and hide a regression during a quick test.
- A database rollback cannot undo payment, email, webhook, or fulfillment effects already sent outside WordPress.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
baseline: WooCommerce 10.9.4
candidate: 11.0.0-rc.2
compare: 11.0.0-rc.1...11.0.0-rc.2
checkout_fixtures: 14
payment_gateways: 3
failed_actions: 0
external_mismatches: 0
rollback_minutes: 18
release_decision: pending_owner_signoff
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Freeze the production baseline
- Review the RC 2 delta
- Run revenue workflows
- Reconcile all side effects
- Rehearse rollback and sign off
Decision rule
Approve the stable WooCommerce 11 upgrade only when each revenue-critical RC 2 workflow passes, the changed-code delta has an owner, no unresolved scheduled action remains, and rollback plus external reconciliation are timed and documented.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- The installed staging package reports 11.0.0-rc.2 and matches the recorded checksum.
- Every critical checkout fixture has one order, one payment result, correct stock, expected email, and expected external records.
- Action Scheduler has no unexplained failed or overdue action tied to the test window.
- The release report names pass, block, accepted risk, owner, evidence, monitoring, and rollback criteria.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Can an RC 1 pass count for RC 2?
Only for a workflow whose code path, dependencies, fixtures, and environment are unchanged. Record that evidence instead of assuming it.
Should RC 2 run on production?
No. Use a disposable staging clone with protected customer data and disabled live side effects.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, prepare a WooCommerce 11 production upgrade.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Retest the WooCommerce 11 RC 3 delta after the delay
RC 3 arrived after the stable release was delayed. Use the WooCommerce 11 RC 3 staging delta checklist to compare packages and rerun changed checkout, order, stock, queue, extension, performance, and rollback paths. Keep the release delay production freeze checklist open until WooCommerce publishes and verifies the stable package.
Move from release candidate evidence to the final WooCommerce 11.0 gate
Use the final WooCommerce 11.0 database and large-store checklist, then add the failed-order stock ledger, the Action Scheduler 4 queue test, and the DataViews extension readiness matrix where those systems are in scope.
Helpful references