WordPress is in the middle of its biggest architectural shift in 20 years. And if you’re running a WooCommerce store, it’s going to affect you whether you’re ready for it or not.
The shift? Block themes. Also called Full Site Editing (FSE) themes.
If you’ve heard the term but weren’t sure what it means for your store, you’re not alone. Most store owners don’t think about their theme’s architecture until something breaks.
Let’s fix that.
What Block Themes Actually Are (Plain English Version)
Classic WordPress themes (the kind most WooCommerce stores still run) work with PHP template files and predefined “hook” locations. Think of hooks as designated parking spots where plugins can drop in their code. There’s wp_footer at the bottom of every page, wp_head at the top, woocommerce_after_add_to_cart_button inside the product page, and dozens more.
Plugin developers have relied on these hooks for 15+ years. Your side cart plugin probably injects itself into wp_footer. Your notification bar probably hooks into wp_head. Your product badges probably use WooCommerce template hooks.
Block themes work differently. Instead of PHP template files with predefined hooks, block themes use an HTML-based template system controlled entirely through the WordPress Site Editor. You build your header, footer, product pages, and shop layout with blocks.
Here’s the problem: many of those classic PHP hooks don’t fire in block themes at all.
No wp_footer hook? Your side cart doesn’t load. No woocommerce_before_shop_loop? Your shop filters disappear. A plugin that relies on classic hooks in a block theme is a plugin that silently stops working.
Why This Matters Right Now (Not “Someday”)
You might be thinking: “I’m on Astra (or GeneratePress, or Flatsome). This doesn’t affect me.”
Today? Probably not. But here’s what’s changing fast:
WordPress core is pushing block themes as the default. Twenty Twenty-Five, the current default WordPress theme, is a block theme. Every default theme going forward will be a block theme. New users spinning up WordPress for the first time land on block themes automatically.
The theme ecosystem is migrating. The WordPress.org theme directory has a dedicated “Block Themes” filter, and the volume of block theme submissions grows every quarter. Major theme frameworks are building block-first versions of their products. WooCommerce’s own storefront direction is block-based.
WooCommerce itself is going all-in on blocks. The Cart block, Checkout block, Product Collection block, and Mini Cart block are all block-based. WooCommerce’s roadmap points to a fully block-based storefront. Classic shortcodes like [woocommerce_cart] are being deprecated in favor of their block equivalents.
The transition isn’t sudden. It’s gradual. But it’s happening. And the plugins that don’t adapt will break, one theme update at a time.
How Classic-Theme-Only Plugins Break
Here’s what actually happens when a WooCommerce plugin built for classic themes meets a block theme:
1. The plugin doesn’t appear at all.
Most side cart plugins inject themselves using wp_footer or similar action hooks. In a block theme, these hooks may not fire (or fire in unexpected contexts). The plugin’s HTML never makes it to the page. No error. No warning. The cart just… isn’t there.
2. The plugin appears but looks broken.
Some hooks still fire in block themes, but the DOM structure is completely different. CSS selectors targeting .site-footer or .main-content miss their targets. The cart renders, but it’s floating in the wrong spot, overlapping content, or invisible behind another element.
3. JavaScript errors cascade.
The plugin’s JS expects certain DOM elements to exist (elements created by the classic theme). In a block theme, those elements don’t exist. The JS throws errors, which can break not just the cart but other JavaScript on the page too.
4. The Site Editor can’t control it.
Even if the plugin technically works, it exists outside the block system. You can’t move it, style it, or configure it from the Site Editor. It’s a black box injected via PHP while everything else on your site is controlled through blocks.
None of these failures are dramatic. You won’t see a white screen of death. You’ll see a slightly broken shopping experience that slowly erodes trust and conversions. The kind of thing customers don’t report. They just leave.
What “Block Theme Compatible” Actually Means
Here’s where it gets tricky. A lot of plugins claim “block theme support” without explaining what that means. So let’s define it.
True block theme compatibility means:
1. No dependency on classic theme hooks for core functionality.
The plugin can render and function without wp_footer, wp_head, or any WooCommerce classic template hooks. It uses WordPress block registration, the Interactivity API, or the WooCommerce Store API to operate.
2. Works in the Site Editor.
The plugin offers blocks or patterns that can be placed and configured through the WordPress block editor. No shortcodes. No widgets-only approach.
3. CSS that doesn’t assume a classic DOM structure.
The plugin’s styles work whether the surrounding HTML comes from a classic theme or a block theme. No selectors that depend on elements like #page, .site-header, or .entry-content.
4. JavaScript that operates independently.
The plugin’s JS doesn’t wait for or depend on DOM elements created by a specific theme architecture. It manages its own state and rendering.
That’s a high bar. And most WooCommerce plugins, including most side cart plugins, don’t meet it.
A Quick Compatibility Checklist
Before your next theme switch (or WooCommerce update), check your critical plugins:
- Does the plugin work on Twenty Twenty-Five (a block theme) out of the box?
- Does the plugin offer a block for placement in the Site Editor?
- Does the plugin still require jQuery? (If yes, it’s almost certainly classic-only)
- Does the plugin documentation mention block theme support or FSE compatibility?
- Can you configure the plugin’s position and behavior from the Site Editor?
- Does the plugin use the WooCommerce Store API or still rely on legacy AJAX endpoints?
If you answered “no” to 3 or more, that’s a plugin that will cause problems on block themes. Maybe not today. But soon enough.
Where Caddy 3.0 Stands
When we rebuilt Caddy from scratch for version 3.0, block theme compatibility wasn’t an afterthought. It was a core design requirement.
Caddy 3.0 is built on the WordPress Interactivity API and WooCommerce Store API. Not adapted from a classic-theme architecture. Built natively on the modern stack.
What that means in practice:
- Works on any theme. Classic themes, block themes, hybrid themes. Caddy doesn’t depend on
wp_footerhooks or classic template structures for its core rendering. - Offers a Caddy Cart block. You can place the cart trigger anywhere in your site using the block editor. Header, footer, template parts. Wherever you want it.
- Zero jQuery. No jQuery dependency means no jQuery version conflicts, no extra weight, and no reliance on a library that block themes are actively moving away from.
- Reactive updates via Store API. Cart state is managed through the WooCommerce Store API, not legacy AJAX. The same API that WooCommerce’s own blocks use.
- HPOS compatible. High-Performance Order Storage ready, because that’s the other major WooCommerce migration happening right now.
The free version on WordPress.org includes the sticky side cart, free shipping meter, product recommendations, save for later, and coupon field. All of it works on block themes.
Caddy Pro ($99-$399/year) adds the multi-tier Rewards Meter, announcement bar, custom cart icons, and Google Analytics integration.
Try Caddy Free on WordPress.org | See Caddy Pro Features
The Bottom Line
Block themes aren’t a niche experiment anymore. They’re the direction WordPress is heading, and WooCommerce is heading with it.
Your side cart is one of the most interactive, customer-facing elements on your entire store. If it can’t keep up with where WordPress is going, it’ll be the first thing to break, and the last thing you notice.
Worth checking now, before a theme update makes the decision for you.