If classic WooCommerce checkout stopped working after the 11.2.0 update and your store removes address fields, check the 11.2.1 fix before adding another field workaround. WooCommerce lists this exact regression in its October 9 release notes. The repair still needs a checkout test with your customizations enabled.
Confirm this is the affected checkout
Open the checkout page in the WordPress editor and establish whether it uses the classic shortcode or the Checkout block. Record the active WooCommerce version, field-editor extension, child theme and any snippets removing billing or shipping fields. A hidden input, an optional field and a field removed from the data structure are different changes.
On a sanitized staging copy, reproduce the failure with a synthetic customer and a sandbox payment method. Record whether submission produces a field error, a server error or no request at all. Check whether an order was created before attempting payment again. Repeated clicks are not a reliable way to determine whether a transaction succeeded.
Compare one version change
- Back up the staging database and files. Keep the failing configuration available for comparison.
- Capture the installed versions and the exact field customization. Do not remove the customization at the same time as updating core.
- Update WooCommerce to a supported release containing the 11.2.1 fix, checking extension compatibility first.
- Repeat the same basket, customer type and sandbox payment method.
- Inspect the resulting order, not just the thank-you message. Confirm required billing data, shipping selection and tax calculation still match the intended workflow.
The official 11.2.1 announcement identifies the fix but does not establish that every field editor or gateway configuration is compatible. If the error persists, collect the first relevant application error and compare it with the field-removal callback or extension configuration.
Digital basket: No unnecessary delivery prompt. Physical basket: Delivery details remain valid. Invalid input: Useful validation remains. Saved order: Payment and fulfillment agree. Explanatory checklist, not a customer test result.
Keep the business requirements intact
| Test |
What must remain true |
| Digital-only basket |
Checkout completes without demanding genuinely unnecessary delivery information |
| Physical basket |
A deliverable address and appropriate shipping method are still required |
| Returning shopper |
Saved information does not hide a failure affecting new shoppers |
| Invalid required value |
The user receives a useful validation message |
Do not remove all address validation to make a failing request return success. A gateway, tax service or fulfillment system may need data that the storefront does not visibly use. Confirm those contracts with the responsible integration before shortening checkout further.
WooCommerce's classic checkout customization reference is relevant to shortcode filters. Do not assume the same snippet controls the Checkout block. For that path, follow the billing-field validation guide.
Decide whether the repair is ready
A useful completion record includes the before and after versions, field configuration, test order ID, validation outcome and downstream result. Use non-sensitive evidence, not copied production checkout requests. If the failure disappears only when a field extension is disabled, report that dependency instead of describing core as fixed for the entire store.
HandL WP can investigate checkout customizations when the release fix and the site's field contract still disagree. Keep live payment handling unchanged until the controlled test establishes the correct repair.
References reviewed October 11, 2026. Examples are explanatory, not customer test results.