Release check: what changes now that 11.2 is stable?
Checked October 8, 2026: WooCommerce released 11.2.0 on October 7. The date input is now a released Checkout block capability, but a delivery promise still needs the business rules and acceptance tests below. The release requires a database update and includes security fixes. If your store uses PublishPress Future 3.0.0 through 4.10.3, WooCommerce warns of a fatal-error conflict; update that extension to 4.10.4 or later before the WooCommerce update. These are documented release conditions, not a claim that your store is affected.
Before deployment, preserve a restorable database and file backup, record the checkout extension versions, and define who can stop or recover the release. A previous plugin ZIP alone is not a complete rollback plan for a database change. Stop if the date differs between checkout, order records and customer email, or if unavailable dates remain selectable. No Webless store update or payment test was performed for this article.
Would a date picker at checkout let your WooCommerce customers choose delivery? WooCommerce 11.2.0 was released on October 7, 2026 and adds a date field to its Additional Checkout Fields API. The official release notes confirm the feature for the Checkout block. This is a useful new building block for a Checkout block extension; it is not a built-in delivery scheduler or a reason to skip staging and compatibility checks on a trading store.
Before adding a field, decide what your customer is actually choosing: a preference, a dispatch date, a guaranteed delivery date or a capacity-limited time slot. Those are different promises. A calendar that accepts a date without checking fulfilment can create more customer-service work than an honest estimate.
What is changing in WooCommerce 11.2?
The release adds a date field type for extensions using the Additional Checkout Fields API with the Checkout block. WooCommerce says it uses the browser’s native date picker, including mobile controls. A shopper enters a date in the browser’s locale; order details and emails use the store’s date format. Developers can set fixed or relative minimum and maximum dates. The same date limits apply in Checkout block and My Account forms.
That describes the field interface and basic validation. It does not mean WooCommerce automatically knows your warehouse closures, carrier collection days, inventory allocation, shipping zones, public holidays or the number of orders your team can fulfil on Tuesday. An extension or custom integration must supply business rules where needed. The feature is available in 11.2, not earlier 11.1 installations; verify your installed version and the responsible extension before planning a production launch.
| Customer-facing promise | Rules the store must check | Suitable wording until proven |
|---|---|---|
| Preferred delivery date | Store the choice with the order and make clear that fulfilment will confirm it. | “Preferred date, subject to confirmation.” |
| Dispatch date | Processing lead time, stock readiness, cut-off time and warehouse opening days. | “Requested dispatch date” if staff still need to approve it. |
| Delivery date | Carrier service, destination, holidays, cut-off and realistic transit range. | A specific date only after those constraints are verified. |
| Reserved local delivery slot | Capacity for driver, vehicle, route and timeslot, including simultaneous checkouts. | “Reserved slot” only after successful capacity allocation. |
If your current site merely wants to collect a preference, a field may be enough when your installed version and the responsible extension support it. If the date changes what you promise or charge, design the rule and failure response first.
Check your current checkout before adding a field
Identify whether your store uses the Checkout block or a classic shortcode/custom checkout. The 11.2 announcement concerns the Additional Checkout Fields API used by the block; do not assume a classic checkout field plugin will gain this behaviour automatically. Inventory existing delivery-date, pickup, shipping and checkout-field extensions, then decide which component currently owns the date and order metadata.
Also check whether the customer needs to select a date on the product page, in the cart, at checkout or only after payment. A checkout-only field can be too late if delivery availability affects which shipping method is offered. For international shipping, ask whether a chosen date can be honoured in every zone. For local pickup, establish a separate opening-hours rule.
WooCommerce’s Order Delivery extension documentation illustrates a fuller scheduling system: available dates reflect products, shipping methods and store availability, and an invalid date can block checkout. That is a different level of functionality from a plain date input. This is a comparison of documented capabilities, not a recommendation to buy a plugin without testing your store’s needs.
A staging test that exposes false promises
Test the stable release first in an isolated staging store using the official WooCommerce update guide. Keep live payment, outgoing customer email and production inventory disconnected. Record the current checkout type, extension versions and a restorable backup before changing anything. The cases below are a proposed acceptance matrix, not results from a Webless store test.
| Scenario | Expected result to define before testing |
|---|---|
| Customer selects the earliest allowed date. | The interface, order record, email and staff view agree on the same local date. |
| Customer changes shipping method or destination. | Unavailable dates are rechecked; an old selection cannot silently survive a new rule. |
| Two shoppers choose the last available slot. | At most the configured capacity is confirmed, with a clear message for the other shopper. |
| Customer crosses a time-zone or midnight boundary. | The displayed date matches the store’s promised local delivery day. |
| Payment fails, is retried or redirects back to the store. | No unconfirmed slot is treated as a paid delivery commitment; a successful order retains its date. |
| Customer views the order on mobile and in My Account. | The same date is readable and no field or validation message overflows the screen. |
Write down the failure path too: what happens if no dates are available, if a customer omits a required choice, or if the shipping integration is temporarily unavailable? When the answer is unclear, stop at “preference” language rather than silently promising a slot. Our checkout testing checklist covers the wider cart, payment and confirmation journey.
Choose the smallest solution that matches the promise
A simple request field is appropriate when a human confirms dates later and the wording says so. A real scheduling solution needs availability, lead times, capacity, exception days and a decision at the right point in checkout. It also needs an owner for refunds, changes and missed deliveries. Adding a visual calendar does not remove those operational obligations.
WooCommerce 11.2 gives developers a more natural date input for the Checkout block. Verify extension compatibility and the actual fulfilment rules before deploying. If the store needs rule-based dates, Webless’s WordPress development service is the relevant route for scoping and testing the integration. Keep the official release notes and your staging acceptance record with the implementation so a future update can be checked against the same promises.