At what point are FSE theme developers going to start integrating and considering WooCommerce for their themes? WooCommerce has almost always seemed to lag behind all other considerations. It’s a bit like it’s an afterthought to simply scramble in the elements of a solid WooCommerce store. Where is a persistent cart header? Where are the templates for /single-product? There’s all kinds of elements which can be developed right along side of other teams working on FSE, but it seems to (again, consistently) not happen.

I’ve taken Blockbase and all the other FSE themes for a spin on LocalWP, and none of them have any WooCommerce elements in them. Again, one should not expect perfection at a “developmental” stage. However there does seem to be a behavioral pattern of WooCommerce elements being a bit of an “afterthought” that simply brings up the rear about a year or year-and-six-months afterwards.

Why not get everyone on the same page immediately? That way theme authors can address putting the cart elements in the header template. (Yes, WC can be run, but w/out a cart header, shoppers don’t know where to click after an item is in their cart). And, if theme authors and WP core developers always, Always, ALWAYS started simultaneously with one or two WooCommerce folks on board, it would absolutely shorten the time needed for store owners to receive the benefits of FSE (and remove some of their pagebuilders!) and for WordPress to get more Shopify business over to WooCommerce. But that seemingly never happens because WooCommerce always seems to be the “afterthought.”

Brad

First, I want to make sure all of our readers are on the same page. WooCommerce is a third-party plugin. It is unrelated to the core WordPress and Gutenberg projects. Granted, WooCommerce is owned by Automattic, one of the largest contributors of resources and people. So, there is likely some crossover among developers.

It is still crucial that we make a distinction between the two. When looking at some of the recent block themes that other developers have released, I have yet to see any integrate with the WooCommerce plugin. I cannot say whether any of their authors have plans to do so in the future. I imagine that some will and others will not. Like with any third-party plugin that outputs something on the front-end (e.g., bbPress, Easy Digital Downloads, etc.), it is the theme author’s choice of whether they want to take on the burden of supporting integrations with projects that are not their own. It can be a maintenance nightmare at times, particularly when it comes to free themes. However, I have no doubt that we will see more block theme authors catering to WooCommerce users as we move forward.

All of this is a long-winded way of saying the responsibility of WooCommerce working in a block world is on WooCommerce itself. When it gets to that stage, theme authors will follow.

One of the things I love about the block system is that it creates a standard for all themes and plugins to build from. The long-term goal of plugins like WooCommerce should be to work without theme support. If a user wants a cart item in their nav menu, it should be as simple as adding a block via the site editor. The same should be said for any other element of creating an online shop.

I reached out to Darren Ethier, an engineering team lead within Automattic who works on the intersection between WooCommerce and Gutenberg. He agreed that the block system could make it easier for things to simply work without specialized theme support.

“That’s definitely the target we’re shooting for,” he said. “Whether or not we will land it in the first iteration is still unknown.”

However, the answer is more complex than that. WooCommerce is a heavy plugin with a history entrenched in the pre-block era of WordPress and has an ecosystem of third-party add-ons it must be careful not to break. The team is making progress and has a few things shooting through the pipeline. It will take some time, but you will not see block themes showcasing WooCommerce shops without the plugin first laying the groundwork.

Block templates are a high priority. Top-level templates like single-product.html, archive-product.html, taxonomy-product-cat.html, and taxonomy-product-tag.html will be available to any block-enabled theme soon.

“This initial iteration will be a straight port of the existing PHP templates and have a placeholder for the rendering of the template in the editor,” said Ethier. “We’re essentially wrapping the rendered PHP template in a dynamic block. This is definitely not the end goal. It just is the initial step of moving towards our vision of ‘Store Editing’ where merchants are able to completely customize the layout of their stores using all the opportunities available through the block and site editors.”

This is more of a stopgap measure than full-blown support. However, it is a step in that direction.

“We decided to take this approach because it more quickly helps bridge the gap between the current PHP-based templates and block themes so that folks can start to see the potential (and still add blocks around the PHP-rendered content),” he said. “We also know it’s going to be a complex job to more fully implement the vision of Store editing with block themes while supporting (and inspiring) the rich existing ecosystem of WooCommerce extensions. So, this allows us to incrementally improve things over time.”

This may not be the news all block theme authors want to hear, but the changes will be enough for them to start exploring tighter integration with the plugin.

The team is currently aiming to add block template support in the next release of the WooCommerce Blocks plugin. If all goes well, the feature will be ported to WooCommerce 6.0, which should be in time for the WordPress 5.9 release.

“It’s important to set expectations, though (which is why I’m mentioning this again),” said Ethier. “This initial iteration definitely will not be the final iteration of Woo Block templates.”

He also highlighted several things from the roadmap:

• “Product Element Blocks” – which are the Woo equivalents to the WP template blocks. So, things like “Product Title,” “Product Description,” “Add to Cart Button,” etc.
• Integrating with the WP Query Loop Block (for products).
• “Mini-Cart Block” – which should allow for insertion into header/footer template parts.
• Commerce Patterns.

“All these things (and more) will help us with iterating on the various components of a store that are visually represented via templates, template parts (i.e., think of things like reviews on the single product page, etc.),” said Ethier.

For a deeper look at what is ahead, read Peek into the WooCommerce Blocks Roadmap. Warning: it is dense and geared toward developers, but it must be. The solutions for a project the size and scope of WooCommerce are not simple.

“One key strategy we’re trying here is to provide default WooCommerce store editing templates and functionality out of the box with Woo Core that should in theory ‘just work’ with any block theme,” said Ethier. “There’s so much that theme.json and global styles unlock to make this possible. Themes will still be able to override the default WooCommerce templates and template parts if they want, but they won’t need to.”

While it may feel like block-based storefronts are lightyears away, we must remember that block themes are in their infancy. There are only about a couple dozen in the directory, and most of those are experimental.

I am as excited as anyone about what this could mean for projects like WooCommerce. At the same time, I also know that the road might be longer than what we have in mind, but the WooCommerce team is already traveling down it.