← All posts Insights 4 min read

WooCommerce Cart and Checkout Blocks: Migrating Off the Classic Shortcode Before 11.0

WooCommerce 10 made Cart and Checkout blocks the default; 11.0 drops the classic shortcode. Migrate custom fields, gateways, and styling without breakage.

WooCommerce 10.0 made the block-based Cart and Checkout the default for new installs. WooCommerce 11.0 — pencilled in for the back half of 2026 — will drop the classic

shortcode entirely. If your store still ships the shortcode checkout, you have one or two release cycles to migrate before the rug pulls.

Who this is for: WooCommerce store operators or developers who still have

on the checkout page, custom checkout fields hooked via woocommerce_checkout_fields, or a payment gateway that doesn’t advertise block support yet.

What’s actually different

The classic checkout is a server-rendered PHP form. The block checkout is a React app that talks to the WooCommerce Store API. That changes three things at once: the styling pipeline, the hook surface, and the data path. Anything written against the old surface needs to be ported.

  • Styling. Theme overrides via woocommerce.css stop applying. Block styles come from theme.json and per-block CSS classes.
  • Hooks. woocommerce_checkout_fields, woocommerce_after_order_notes, and the dozen other classic filters are no-ops in the block context. You add fields via the woocommerce_register_additional_checkout_field API.
  • Payment gateways. A gateway needs to register a block-aware integration to show up in the block checkout. Stripe, PayPal, Square, Mollie, and the major hosted gateways all ship block support today. Niche gateways often don’t.

Adding a custom field — the new way

The block API is more declarative than the classic hook chain. You register a field once and it appears in both the order admin and the customer-facing checkout, with validation server-side.

add_action('woocommerce_init', function() {
  woocommerce_register_additional_checkout_field([
    'id'            => 'softxone/vat-number',
    'label'         => 'VAT number (EU buyers only)',
    'location'      => 'contact',
    'required'      => false,
    'sanitize_callback' => fn($v) => preg_replace('/[^A-Z0-9]/', '', strtoupper($v)),
    'validate_callback' => function($v) {
      if ($v && !preg_match('/^[A-Z]{2}[A-Z0-9]{8,12}$/', $v)) {
        return new WP_Error('vat_invalid', 'VAT number format is not recognised.');
      }
    },
  ]);
});

The value lands in the order under _wc_other/softxone/vat-number, accessible via $order->get_meta('_wc_other/softxone/vat-number'). If your NetSuite sync needs the VAT number, that’s the one place to read it.

Migration order

Don’t flip the checkout in production without doing this in order. The risk isn’t that the new checkout doesn’t work — it’s that a gateway or a custom field silently disappears.

  1. Inventory every plugin that hooks woocommerce_checkout_* filters. grep -r 'woocommerce_checkout' wp-content/plugins/.
  2. Inventory every payment gateway. Open the gateway’s plugin page and confirm “Cart and Checkout blocks supported.” If not, contact the vendor before migrating.
  3. On a staging site, switch the checkout page to use the blocks via wp option update woocommerce_checkout_page_block 1 or by replacing the page content.
  4. Re-test every custom field, gateway, shipping method, and tax scenario. Side-by-side with prod is the only honest test.
  5. Promote to production on a low-traffic window. Keep the old page as a draft, so you can roll back the URL in one click if you missed something.

What you gain

Faster perceived checkout (the React app updates the total without a full page reload), better mobile layout out of the box, and a real REST surface so a future headless storefront can reuse the checkout logic without forking. The Store API is the foundation we covered separately in our HPOS migration post — the same data model underpins both.

FAQ

Will my existing orders be affected by the migration?

No. The migration changes how new checkouts are rendered, not how past orders are stored. Order data stays in the same tables and remains queryable via the same admin and REST endpoints.

Can I still customise the order-confirmation email?

Yes. Email templates are unaffected — they live outside the checkout flow. You override them the same way as before, in woocommerce/emails/ in your theme.

What if my payment gateway hasn’t shipped block support?

You have two choices: stay on the classic checkout until they catch up, or migrate to a gateway that has block support. WooCommerce maintains a compatibility list in the Cart and Checkout Blocks documentation. Don’t migrate blind — verify gateway support first.

Is the migration reversible?

Trivially. Switch the checkout page back to one containing

and the classic flow returns. Keep the old page as a draft during migration so the rollback is one click. This stays true until WooCommerce 11.0 removes the shortcode entirely.

The deadline you can’t see yet

WooCommerce hasn’t yet announced the exact 11.0 ship date, but the team’s cadence has been two minor releases per year and 11.0 is queued. Stores that wait until the deprecation warning shows in the admin will be making the migration under time pressure. Stores that migrate this quarter will be making it under their own.

If your store has a NetSuite integration, a complex tax setup, or custom checkout fields and you’d like the migration handled end-to-end, our WooCommerce + NetSuite service package now includes a block-checkout migration as a standard line item.


Ship it

Need this in your stack?

We build, integrate, and ship — no calls, just delivery.

Start a project →