What is the Future of WooCommerce Blocks?

I had the chance to chat with two WooCommerce Core developers about blocks. When asked about the next steps and the rollout plan, Gary Murray and Darren Ethier gave us some insights. (You can listen to the full podcast at the end of the post).

The Next Steps for the WooCommerce Blocks

Ultimately, the long-term plan is that the blocks would essentially replace the older shortcodes, that’s the long-term plan of where we want to get to.

Replacing the Shortcodes

It makes sense, essentially, in terms of the direction that the market’s moving in, the direction that WordPress moves in, that we get to the point where we can actually replace the shortcodes with these blocks. The real point that we’ve essentially been challenged with ourselves essentially is, they are a number of stores that potentially use the old shortcodes and they are using extensions that integrate with it that might never actually be able to potentially integrate with the new cart and checkout, and we do have to take that into account. That’s essentially why even in terms of how we’ve developed it, how we’ve essentially launched it today. We haven’t pushed it off from a perspective of, this is what it is, it’s in the core, it’s available to use.

Extension Intergration

It has very much been more released through the blocks, shown to be an experimental thing that we essentially are working on so that we, from our own perspective, have working to actually integrate some of the extensions ourselves as a proof of concept, that it does essentially work and that we can integrate and to get an understanding of how much time and effort it actually needs to go into it from a development perspective. There are some that, in terms of like development time, have been probably in a matter of hours, maybe a days worth of integration, but then we look at something at the moment like the checkout field for instance, that’s an extension which is going to require significant work to make it work with the new.

But then also, in retrospect, as we’ve been looking at it we also have to go, “Is part of the checkout field editor the reason for the existence of that extension due to some of the shortcomings of the current cart and checkout?” And then it’s like, “Do you actually need to put over all that functionality into the new cart and checkout if we actually are already making some of those improvements in the core product itself through the new blocks?”

The Long-Term Plan

We want to get to the point where these new blocks would be the default experience for customers, but we do have to take into consideration that they probably will be stores, there’ll be merchants that might need to use the old cart and checkout for the foreseeable future due to either customizations that they’ve made to their stores. That’s something we discussed internally, we’re trying to figure out the best way, essentially, for people to be able to do that because that experience in and of itself could get super messy basically, where a person is trying to use the one cart and checkout, they’ve got the old version.

Let’s just say, they’re using the version, the shortcode version. They want to switch to the new version. How do we actually know from our perspective what extensions they’re using that are not compatible with the new cart and checkout? So that’s where the experience could become quite a miss and we do need to make sure that we’ve actually taken that into account in terms of when we do look to roll this out, what is that experience going to be if you switched from the old to the new, or even if you switched from the new back to the old. We’ve got to try and make sure that there’s a clear and easy transition.

The Developer Experience

To add some color to the developer experience, which I think is good to highlight that. I think there’s two experiences that we’re looking at when we’re talking about the new products there’s, what are we aiming for from the perspective of the merchant and shoppers and their experiences over what they’re using now? And then, what are we aiming for in terms of the developer experience, the ecosystem that supports what we’re building that actually contributes to success of WooCommerce in terms of the products that we offer? As I’ve said before, one of the greatest strengths of WooCommerce has been the extensibility. The availability and the possibility for other developers themselves, or stores to build exactly what they want using the existing slate of filters and action hooks.

That’s been a strength, but it’s also been a weakness in the sense that it’s very easy for stores to end up where they’re ending up with a poor experience, not only for themselves, but also for the shoppers and not realize that they’re shooting themselves in the foot. And I think that’s an area where some of the competitors like Shopify and Squarespace excel in, because they’ve really set boundaries around what is possible that it introduces some less flexibility from the developer standpoint, but man, does it ever really make the user experience great. The challenge is we want to take the best of that curated experience to improve it for merchants and shoppers, but also how do we retain a lot of the developer experience so that they’re able to continue building great products for the WooCommerce ecosystem.

Bridging Current Blocks and the Future

The challenge is bridging between where we are now and what that’s going to look like in the future. In a way that doesn’t lead existing stores in the dark, in terms of what they’ve already got built and what’s already really working well for them, but also embrace all the new stores that are coming online, they’re expecting that better experience from the get-go. When it comes to things like cart and checkout blocks, a little bit of background.

I’ve been with WordPress since 2007. I’m a self-taught developer, came up with PHP. I started with just using other plugins, learning PHP. So I’ve been through all the different trends that have come and gone in the WordPress world and the challenge of being a PHP developer and seeing all this new JS, JavaScript stuff coming, being a little bit intimidated by that. I really, really empathize with the WooCommerce developers and shops that are seeing this shift and what that means for the time investments in that end. Just wanting to throw that in there.

What is Extensibility Going to Look Like

One of the things we’re trying to do with the development, we’re working on the blocks and feeling out what extensibility is going to look like. There’s something we call curated extensibility, where instead of just providing a bunch of filter and action hooks and people develop on top of that, we think about what problems need solved and how can we create integration points that help solve those problems. Under the hood they may use filter and actions in different ways of implementing that particular integration, but presented to the developer a simple way to hook in.

And a good example of that at work is with Gutenberg blocks themselves, with the register block interface. It’s a really quick interface for registering a block that you can have the PHP side, and you can have a JavaScript side, where it might only be JavaScript, but it’s a clear defined contract that exists for developers to be able to hook in and build a block and make it available.

We want to do something similar with some of our extensions, especially in the cart and checkout because that is such a critical piece of any e-commerce store. We want to make sure that we introduce extensibility in a way that if there’s a bad plugin that’s installed or a bad customization that’s installed and something breaks, it doesn’t interrupt the flow. And also provides a common way for any integrations or any extensions to hook into the improved UI and UX without having to build out so much of their own stuff. It’s like peeling back layers of the onion. If you need to move beyond that interface and the things that are behind you can still use, but then you’re kind of on your own at that point and you have to learn the technologies more in depth to be able to work with that.

And then initially for the cart and checkout blocks especially, for developers a lot of the learning will be on the client side. We’re trying as much as possible with extensions to preserve how things are processed on the server-side so that once things come into the new API for the checkout, we still fire a lot of the existing backend processing that happens with the hopes that it reduces some of the work needed for customizing and hooking into the new cart and checkout flow.

We’ve already seen that it’s working well for a payment methods. We’ve been doing some work on integrating subscriptions, which has helped influence what extensibility points we put in, but also the server-side, a lot of it’s being processed using existing server-side codes. So it limits somewhat the amount of work that’s needed to integrate.