Catching Up with Mike Jolley – Jigoshop, Headless WooCommerce, and more

Mike Jolley might know more about WooCommerce code than anyone on the planet. He was the lead developer of Jigoshop, which was forked by WooThemes over 10 years ago to create WooCommerce. Mike was the lead developer of WooCommerce through the company’s acquisition by Automattic in 2015.

I recently caught up with him to ask more about his journey, and the future of WooCommerce. One of the big takeaways I got from talking with Mike is that Woo is very interested in headless eCommerce, and there are exciting things in that area coming soon. One of those things being the WooCommerce Store API, which sounds really cool, but is still under development.

How has your work life changed since the acquisition of WooCommerce by Automattic? Are you still writing code and fixing bugs on a daily basis?

Definitely, yes. I’m still coding daily. My role has however changed dramatically over the years!

When we came over from WooThemes this was indeed my role, and I did lead a team of developers working on WooCommerce Core for several years. But as we grew, responsibilities were divided, more teams were spawned handling various aspects of the WooCommerce ecosystem, we added business and product leads, more developers, designers, and so on. It’s all so much larger than any one person!

Three years ago I started a new project; becoming a father. After returning from parental leave, I decided to step back from team leadership and go back to an IC position to reduce some of my responsibilities. Maybe it was a bit of a mid-life crisis too 🙂 I moved away from primarily doing PHP work to JavaScript and React by switching to a team working on WooCommerce Blocks. It’s been a huge learning experience for me. Overwhelming at the beginning.

---

What is the coolest or weirdest way you’ve seen WooCommerce used by a customer?

I’ve definitely seen a lot of weird stores in my time haha. I wish I could unsee some of them!

Coolest…To be honest what appeals to me most are stores just making the most out of the core product, using just the essentials. I think it’s way too easy to go over the top and install all kinds of plugins on top of WooCommerce that is decremental to the core experience.

I will add, shopping online and randomly coming across WooCommerce stores gives me a very strange feeling inside that is difficult to describe. It happens a lot more often these days. The last one I came across by accident was Venus Optics who sell camera lenses. That’s cool.

---

“Lots of talk about “headless commerce” at Shopify and BigCommerce. Also, there are a ton startups that have raised money to provide headless commerce solutions. What is the future of headless commerce with Woo?”
— @hashim_warren

The work we’re doing with React on the frontend in Blocks, powered by APIs on the server-side, proves that headless commerce is definitely within reach. As those APIs are improved and optimised I certainly think it will become more commonplace. I think there will still many advantages to using Woo as the backend for headless stores; extensibility, flexibility, owning and controlling your data. It will be fun to see how solutions evolve, with WordPress in general too. Whether or not this is the future though, I don’t know. Headless is the latest buzzword to describe this, but API driven apps have been around for a long time.

---

“What are some early product decisions they got right, what are some they got wrong, and what are some that may have been right at the time but are now technical debt?”
— @devinsays

WooCommerce was lucky; it was made close to when Custom Post Types were first introduced in WordPress which not only made initial development easier but gave it advantages over the other plugins such as WP eCommerce which were yet to make the switch. For the most part, this was a good decision. Even though it has led to some scaling pains over the years, the benefits have outweighed the drawbacks in my opinion, giving us a lot of functionality “for free”.

Another good decision early on to make things as extensible as possible through hooks and PHP templates. This was definitely a huge part of the success and adoption of WooCommerce. The flexibility it gave plugin and theme developers led to an ecosystem growing rapidly.

This is however a double-edged sword. Hooks need to be maintained to avoid breakage, which makes it more difficult to refactor things over time and leads to technical debt. Deprecation only helps to a point. In hindsight, some of those hooks should not have been introduced without more careful planning for the future.

I think the approach we’re trying to take now, where we have more curated extensibility points is much more sensible. This allows for extensibility, but through more controlled APIs so any changes can be rolled out in a more controlled manner.

---

“Does want to wade into the fork drama? What persuaded him that WooThemes would be a better place to continue development of what is now WooCommerce?”
— @devinsays

I could mention the market WooThemes had already captured or their experience in the WordPress space, but the biggest reason for me was the focus on product.

At that time, 90% of my day job (as a developer) was client work. We worked mostly with business sites, WP Ecommerce, Shopp, and Magento stores. I don’t remember exactly when the idea for Jigoshop came, but it was largely out of frustration with the solutions we were forced to use at the time.

After its inception, client work was still the primary focus of the business, and Jigoshop felt more like a side-hustle than anything. You can imagine the time-investment involved to keep on top of development, issues, and support. It was enjoyable, but mentally draining on top of everything else.

Around the time Jigoshop launched, WooThemes was trying to create their own eCommerce platform to build into their themes. Naturally, we pitched Jigoshop as a potential solution for them to integrate with instead, and things spiralled from there. Rather than just using it as a third party, WooThemes wanted to hire us to build something with them and they were keen to acquire what had already been built.

You say on your website that WooThemes was not able to acquire Jigoshop, so they forked it. Why couldn’t they acquire it?

I wasn’t involved in the business side of things at all, and I had no shares or vested interests beyond my salary. To my understanding, an offer was made, but for whatever reason, it was rejected. Maybe the sudden interest from a major player influenced that decision.

Either way, I think my move to WooThemes was inevitable. I’m just grateful I was able to continue working on and shaping something I was passionate about.

---

“What is he is most excited about on the future product roadmap?”
— @devinsays

This is a tough one. The range of things being worked on is so vast! I can probably best comment on the things within our team’s space, and that would have to be the Cart and Checkout Blocks.

This project started at the end of 2019 and not only is this a total reimagining of the cart and checkout flow using a modern stack (using React), it’s built on top of a new public REST API (named the Store API) which I’m really proud to have worked on. This API provides access to the WooCommerce cart amongst other things, and could even enable checkouts in a headless context.

Our usage of React in the Checkout block is exciting in itself. Unlike regular Gutenberg blocks which save HTML to the post, or dynamic blocks which use Server Side Rendering, we’re actually using React Components directly on the frontend. It’s really powerful stuff.

Hopefully, more people find out about the Checkout Block and start playing with it. I’ve been noticing a few 3rd party solutions popping up doing similar things, but I don’t think any of them are thinking about integrations with other plugins as much as we are. This is one of our main focuses going into 2021.

Can you tell me more about the Store API?

Not much has been said about it publicly because it’s still in active development 🙂 Hoping to change that soon!

Essentially the store API is a public Rest API that does not require authentication. It provides access to non-sensitive product information, Cart data (with the ability to add/edit/delete from the cart), and Checkout. It’s what powers the majority of the Gutenberg Blocks in WooCommerce, including the new Cart and Checkout Blocks.

So in the case of Checkout for instance, it converts a cart to a draft order, then accepts customer address data, and finally facilitates payment via a payment gateway before sending the result back to the client.

You can think of the Store API as the API for clients, and the core Rest API as the api for store management. Keeping them separate like this makes it clear that one exposes data in a public context.

Will it be an API on a WordPress site or something hosted on Automattic’s servers?

This one will be self-hosted like the Rest API in WooCommerce core.

Are public docs available?

The docs can be found on GitHub. Again, I should stress, it’s in active development and a state of flux, so it’s not yet versioned and may change to meet the needs of the checkout project.

I’m building headless WooCommerce apps over at AppPresser, and the cart/checkout situation is the hardest part. It’s cool to hear you guys are working on that!

We’re hearing this more and more. There are a few small gotchas currently, but you can actually create a cart, and checkout from a rest client like Postman or Insomnia using the Store API right now, no frontend required. For me thats incredibly useful.

---

If you have more questions for Mike, leave them in the comments and I might be able to persuade him to drop by and answer a few. You can see more about what Mike is up to personally and professionally on his personal website mikejolley.com.