Why is there no Woo! with WooCommerce blocks?

The Block Era: Promises and Pitfalls

Blocks were introduced as part of the broader Gutenberg initiative, bringing React-powered components to the frontend. These blocks were supposed to deliver better UX, faster interactions, and modern architecture. And in fairness—they do… somewhat.

The Cart and Checkout blocks in particular are smoother, prettier, and more responsive than their shortcode-based predecessors. It opens the door to a new dynamic and responsive checkout, without needing to rely on repeated Ajax calls.

But here’s the kicker: it’s a small part of a fractured architecture that’s making it really difficult for third-party developers to come on board.

The broader block based ecosystem in WordPress is still evolving, even after years of development at this point. Some earlier decisions are rearing their ugly heads, so you now have the block based Checkout which is frontend rendered, whilst WordPress is pushing the Interactivity API and retaining server-side rendering.

So unlike classic Woo templates where a developer could drop in a do_action( 'woocommerce_before_cart' ) and sprinkle in some magic, the block equivalents don’t expose the same kind of hooks. The JavaScript layer is composed and bundled in such a way that it’s almost entirely opaque to third parties. You can’t enqueue a script and target any old inner block. You can’t just “add a field to checkout” the way plugin developers used to (not unless your UI consists of only three types of fields, anyway).

It’s as if the block system was built for WooCommerce the product, not WooCommerce the platform.

Developer Frustrations, in Three Acts

Missing Entry Points

In the classic checkout, adding a custom plugin feature was a matter of maybe using the woocommerce_checkout_fields or one of the many hooks and filters. In the new block checkout, the same task requires creating an extension via the Checkout Blocks API, writing React components, and navigating a more limited plugin registration system that’s built on top of the WordPress block registration system. You are now required to know PHP, JavaScript, React, Redux, and the WordPress AND WooCommerce block APIs and packages.

That’s a steep learning curve for most.

In the WooCommerce community Slack, the most common question is “I know how I can do this with classic checkout, but how do I do it with blocks?”. The answer is almost always more convoluted, more complex, and less flexible than the classic approach. Sometimes, it’s not even possible.

Now, in fairness, you could argue that the decision with the checkout block for instance was done before WordPress blocks picked up steam, so they’d be forgiven for backing the wrong horse. We all understand technical debt. And yet, years on, this is seemingly by design and embraced by the core team.

This has been discussed many times. Actions/Filters lock us into supporting specific patterns which, once shipped, become impossible to move away from if we want to change later.

That is why we specifically took the approach we did in blocks, favouring curated, focused extensibility points…

In a recent office hours discussion on Woo blocks, plenty of developers expressed similar frustrations.

If I can paraphrase what I’ve heard from others [..] – before blocks we had the WP hooks api, actions, filters, it was THE thing that let devs tap into EVERYWHERE and devs let other devs tap into their code SUPER easily. It was (past tense) the super power of WP. Blocks lost that. That is the gap, and its been missing for years.

So far it seems while developers are being heard, the path forward is still focused on a curated, limited set of extension points. The team wants to know very specific use cases, so they can consider solutions for those problems. Rather than focusing on the broader extensibility that made WooCommerce so powerful in the first place.

Lack of Composition-Friendly Patterns

React is composable. WordPress is trying to embrace more of this with the Interactivity API, individual blocks, and block patterns. But WooCommerce Blocks often render monolithic structures with limited prop-passing or extensibility points. The checkout block for example is completely frontend rendered, which is quite the opposite to WordPress’ choice for blocks. Even smaller blocks such as the add to cart block has limited entry points to allow for customisation.

There’s little room to inject functionality unless you’re willing to dabble in Experimental components, restrict the type of features you’re looking to add, or build repeat blocks from scratch. And even then, you end up creating a mini ecosystem within the Woo ecosystem. Fractured and isolated from the rest of the third party developer community.

So the majority of the time, developers are suggesting to merchants to revert back to the classic checkout. Causing more fragmentation, and increasing the complexity of existing plugins that do manage to add block support. Now you have to support both the classic and block checkout, with the same code base, different APIs, and potentially different user experiences.

Not to mention what all this does for end users who are supposed to navigate this from the outside without any knowledge of the underlying architecture (and nor should they have to!).

Developer Experience is missing

As a predominantly frontend-focused engineer, with enough PHP knowledge to get by (as well as working with some very clever backend PHP developers), I should be jumping for joy at the prospect of building out new features with React and JavaScript. It feels like I should be Woo’s primary target for this new blocks world.

But the reality is that the developer experience (DX) for extending WooCommerce Blocks is still rough. The documentation is mixed and sparse, the APIs are complex and numerous, and the tooling just isn’t up to the modern standards I want to work with. Most Google searches lead to archived links, thanks to the merging of the WooCommerce blocks repository into the main WooCommerce core repository. So you’re never quite sure if it’s up to date or not.

I’ve seen this sentiment echoed by many in the community:

this is by far the most frustrating thing ive worked on recently

And they’re not wrong. If I’m writing code these days, it’s going to be in TypeScript, and it’s nigh impossible to write safe and correct TypeScript with WooCommerce blocks. We’ve put in numerous hours trying to come up with workarounds to help (such as copy/pasting and self-managing and updating the un-exported types from Woo core), but none of this is a good long term solution.

The wp-scripts package and wp-env is the suggested tooling for building blocks and test environments. But it doesn’t provide the same level of DX that modern JavaScript frameworks do. The nature of WordPress also makes e2e testing way more difficult to set up and use. Granted these aren’t WooCommerce specific issues, but they do compound the problem.

Tooling aside, if you then try to add WooCommerce blocks beyond the Checkout, there is extremely limited information available. The best bet is to throw a question into the community Slack, and keep your fingers crossed.

Even then, the developers working on WooCommerce sometimes don’t have the answer either.

The Real Issue: Control vs Community

It’s tempting to frame this as a growing pain. Maybe Woo is still evolving its block strategy? Maybe more hooks and APIs are coming? But there’s a bigger philosophical divide at play.

The traditional WordPress ecosystem prioritizes backwards compatibility and customization. WooCommerce Blocks, by contrast, prioritize performance, stability, and DX for Automattic’s own developers.

In other words: the Woo Blocks team is building for predictable experiences. That’s great if you’re a merchant whose happy with the default Woo experience. Less great if you’re a merchant who needs to reach for a plugin to solve a problem. Something that was always possible with WordPress. Your data, your site, your way.

This tradeoff—between control and community—is at the root of the problem.

Where Do We Go From Here?

To be fair, the WooCommerce team is still turning up to these discussions. They could shy away and ignore them as nothing but a vocal few. But adoption across the board is low. We’re seeing many merchants revert back to the shortcode checkout just to get the functionality they want, as plugin developers struggle to implement feature parity with blocks (not to mention having to support two separate implementations for the same feature). The learning curve is steep.

It doesn’t feel like the same ecosystem that made WooCommerce what it is today—it feels like a change of direction at its core.

For WooCommerce Blocks to truly live up to their name, they need to embrace the WordPress ethos: Simple things should be easy, and intuitive, and complex things possible.

That means:

• Building out a DX that embraces the WordPress community, not just Automattic’s internal team
• Publishing clear extension points, with examples, even if they require constraints or compatibility layers
• Supporting more composable patterns that allow developers to extend functionality without reinventing the wheel
• Investing in documentation that goes beyond surface-level guides

The Woo is Still There—It’s Just Buried

The WooCommerce Blocks project isn’t yet a failure. It does seem like a necessary evolution to keep pace with the wider e-commerce market. But it’s an evolution that’s at risk of leaving behind the very community that built it in the first place.

There’s still some Woo! in there, somewhere. It’s just muffled beneath layers of abstraction, packages, and cautious engineering. Let’s dig it out.

Because if WooCommerce wants to be more than just “Shopify for WordPress,” it needs to bring its community along—not leave them locked outside the walled garden.