# Moving from shortcodes to cart and checkout blocks on WooCommerce

> Since WooCommerce 8.3, released on 14 November 2023, the Cart and Checkout pages use Gutenberg blocks by default on new installs, replacing the historic [woocommerce_cart] and [woocommerce_checkout] shortcodes. Shortcodes remain supported as a fallback: there’s no rush to migrate.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/migration/blocs-panier-commande](https://allaux.fr/en/wordpress-woocommerce/migration/blocs-panier-commande)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Leave the live pages alone: duplicate Cart and Checkout, drop the Cart block and the Checkout block into the copies, then place a full test order with your real payment methods and shipping rates. Once the copies check out, point WooCommerce at them under WooCommerce, Settings, Advanced. The [woocommerce_cart] and [woocommerce_checkout] shortcodes remain supported as a fallback.

## What blocks change compared with shortcodes

The [woocommerce_cart] and [woocommerce_checkout] shortcodes generate the checkout flow in server-side PHP, with a classic HTML render. Cart and checkout blocks work differently: the interface relies on React in the browser, talking to the site through the WooCommerce Store API rather than a full page reload at each step. The visual result for the buyer is still a standard checkout flow, but the underlying technical mechanism changes entirely.

You can switch back to the shortcode at any time via the transform button available in the block’s toolbar, which leaves room to manoeuvre if an extension is blocking the migration.

## Why a checkout customisation might stop applying

- A classic PHP hook or filter that changed the display of the shortcode cart or checkout (adding a field, a message, or reordering sections, for example) doesn’t apply automatically to blocks: the React architecture doesn’t run that PHP code at render time, so a rewrite is often needed through the block-specific extension points (JavaScript filters, Store API).
- A payment or shipping extension that doesn’t explicitly declare block compatibility may not show up as an available payment method on the block cart or checkout, even though it works normally with shortcodes.
- A theme that heavily overrode the CSS or PHP templates of the shortcode checkout (files under woocommerce/checkout/) will see those customisations have no effect on blocks, which use their own templates.

## How I run the switch to blocks

1. **Identifying the site’s current mode** — I check whether the Cart and Checkout pages still use the historic shortcodes or already use blocks, especially on a site created before November 2023 that didn’t switch automatically.
2. **Testing the relevant extensions before switching** — I check on a test environment that every active payment and shipping extension works with blocks and declares its compatibility, before any production switch.
3. **Listing existing customisations** — I list the PHP hooks and template overrides that change the shortcode checkout, to identify which ones need rewriting for blocks.
4. **Switching over and targeted rewriting** — I enable the blocks and rewrite only the customisations that no longer apply, using the block-specific extension points rather than reproducing the old mechanism.
5. **Fallback if something blocks the migration** — If a critical extension isn’t compatible, I convert the affected block back to shortcode via the toolbar, which lets me postpone that page’s migration without blocking the rest of the site.

## No strict point of no return on this switch

> Unlike a URL or platform change, switching back to shortcode remains possible at any time from the block’s toolbar: that’s what makes this migration safer to roll out gradually in production.

## Going further

- **Migrating WooCommerce to high-performance order storage** — A change from the same period of WooCommerce, with its own compatibility logic on the extensions side. ([/wordpress-woocommerce/migration/stockage-haute-performance-commandes](/wordpress-woocommerce/migration/stockage-haute-performance-commandes))
- **Fixing a WooCommerce payment issue** — If a payment extension stops showing up after switching to blocks, this is usually where I start diagnosing. ([/wordpress-woocommerce/probleme-paiement](/wordpress-woocommerce/probleme-paiement))
- **Updating WooCommerce to a major version** — Cart and checkout blocks are one of the changes to check before a major WooCommerce version upgrade. ([/wordpress-woocommerce/mise-a-jour/version-majeure-woocommerce](/wordpress-woocommerce/mise-a-jour/version-majeure-woocommerce))
- **WordPress and WooCommerce migration hub** — Every migration and version upgrade I handle on WordPress and WooCommerce. ([/wordpress-woocommerce/migration](/wordpress-woocommerce/migration))

## FAQ

### Do I need to switch to blocks if my site still uses shortcodes?

Not urgently: shortcodes remain supported as a fallback. I recommend migrating once the payment and shipping extensions in use are confirmed compatible.

### Will my custom PHP hooks simply stop working?

They won’t throw an error, but they’ll stop applying visually since blocks no longer go through the shortcode PHP render they modified. A targeted rewrite is needed to get the same behaviour back.

### How do I know if my payment extension is block-compatible?

I test the payment method on the block Checkout page in a test environment: if it doesn’t show up in the list of available methods, the extension likely isn’t compatible yet.

### Can I go back if the migration causes a problem?

Yes, every cart or checkout block offers a transform button to its shortcode version directly in its toolbar, with no heavy technical work involved.

### Do the blocks change what the buyer sees?

The flow still looks like a standard checkout to the buyer. What changes is on the technical side: rendering relies on React and the WooCommerce Store API rather than classic PHP rendering.