WooCommerce Checkout and Cart Blocks

Ronald: Hey, welcome to another episode of Doo the Woo, I’m Marcus. You joining me again and we have a guest. His name is Nadir and he works for Automattic on the… Is it Rubik’s?

Nadir: Yes. Rubik. Yeah.

The day to day as a Woo engineer

Ronald: Yeah. And well, Nadir. Maybe you can explain what you do in your day to day life.

Nadir: Thank you. Thank you for having me Ronald, thank you, Marcus. So I work for the checkout team within the Welcome Arts organization. And we are a newly formed team. We formed it six months ago. Before that we were a parent team that handles all the block in commerce team. And now we exclusively work on Cart and Checkout.

And our day to day works basically involves building the story PI and building the cart and checkout block. So we maintain those two things. My day to day job, as of right now involves working on future work for Cart and Checkout setting up some architectural stuff, and basically everything that involves checkout within Automattic, within WooCommerce, within the actual product itself.

Ronald: And how many engineers work on your team on the Cart and Checkout Blocks?

Nadir: As of right now, we are nine engineers with one of them being on parental leave.

The complexity of working on the Cart and Checkout block

Ronald: Okay. So if you’re not so up to date with what involves in coding or developing with blogs, it seems there’s a lot of manpower for a Cart and Checkup Block. But I’m sure it’s way more complex than that. How can you best describe the complexities that you’re facing day to day?

Nadir: I would say that our team actually started with four people. And we worked as four people on that project, the Cut and Checkout team for a couple of years now. And then at the beginning of this year, we switched, we added developer apprentices to the team, and we are now a total of nine.

So I would say the complexities of a Cut and Checkout are like a box that you really don’t know what kind of edge cases that is going to be there. What kind of problems. Our team basically handles two things. We own the story PR, which is WooCommerce, new public API. So it’s different from the rest API. It is publicly available and it enables hitless commerce. Building hitless shops and stuff like that. And you also build the Cart and Checkout, which are of now a collection of a lot of blocks that are going to make the cart block.

And they handle a lot of some stuff. As of today, I was spending most of my day handling translation in specific… Loading translation on specific parts of the checkout. Overall, on the long term, our work basically evolves getting checkout into a competitive place. Basically, we started with a really bad checkout in WooCommerce. The old checkout was slow. It had problems, the design was bad. So we designed this new checkout. We worked on it for around eight months and then we launched it. And then that’s a working checkout right now. But the issue is, it’s built on React. It’s built on JavaScript and it’s basically blocks. So all of the integrations, all of the plugins that were there are no longer working right now. And we are actively still spending the last 18 months working on integration APIs and extensibility.

What we did is, we started with payments. Took us two to three months to get some payments API in place. And then we started thinking about extensions from start and finish. So we tried to integrate WooCommerce subscriptions, WooCommerce booking, stuff that.

And we started reimagining how do things integrate with the checkout? Previously It was actions and filters, and it was a free feed, like you can do anything there. And you can do anything, it’s a powerful thing, but it’s very dangerous when you have a checkout that your business relies into. If a plugin isn’t up to date, isn’t using the code probably. The code is not safe from that plugin, your whole checkout is down. And this is a problem for merchant because you can’t really trust your store.

We are spending this time reimagining how extensibility looks for a Cart and Checkout, and what can you do while preserving decor experience? So it means the checkout is still going to be optimized. We try to prevent merchant from shooting themselves in the foot with some wise customization that’s might seem like a good idea, but will hurt their convention a lot.

We try to educate developers about how to build stuff. And has been our main challenge for the past 18 months, which is, getting extensibility points in place, educating developers into the JavaScript and React word, and how they can integrate their stuff.

Backward compatibility

Ronald: Yeah. I’m going to involve Marcus actually in the next question, because Marcus used to work for… Well, still works for SkyVerge, but bought by GoDaddy. And you did a lot of payment gateways and things that involve checkout. So hearing this, and maybe you can give an insight as well of the things that have been happening behind the scenes at GoDaddy.

So with these new block development, how much of the team, how much involvement do you have? And then I think as a part two to pass it back to Nadir, how much they reach out to other developers to get them involved, and up to speed, and make sure they’re all compatible. So Marcus.

Marcus: Yeah. I think for the most part, all of the payment gateway stuff relies heavily on the WordPress way, the WooCommerce way. Working with WooCommerce the way that it works out of the box. And so I would imagine that to some degree, that has to be figured into building these payment gateway integrations and new Cart and Checkout. It’s got to continue to be somewhat backwards compatible.

I know SkyVerge has a couple dozen payment gateway plugins, but that’s just a small portion of all the available payment gateways that you could possibly have across the platform.

Ronald: Is that the key to make it backwards compatible, Nadir? Is that also one of the challenges?

Nadir: One of the challenges is basically how can we make the developer experience easier, but still respecting the merchants and still respecting how things evolve. So as, as Marcus said, the bulk of a payments getaway is HPHP code. The code that does the handling that does the processing stuff, and that state works fine. We made sure it works fine even when a lot of instances it was not written in a wrist API mentality. It relies heavily on the sum of the browser variables. So we still manage to get that working. But the second part is going to be the presentation layer of a payment getaway. So how do you capture the payment and how do you interact with the different life cycles of a checkout?

Previously this was not very fleshed out in the whole checkout. You had a couple of events and stuff like that, but you had to do the most of your work yourself. In the new checkout, we have this whole event basic system into how checkout would collect information, how will it pass them to payment getaway? Now payment getaway would need to rebuild basically that front and side of it.

Basically for this one, it’s for the payment getaway that capture information. But for some, that will just redirect it to another page to capture payment integration issues one line. So it’s very easy, but for the ones that are a bit complicated on the front end. Like Stripe or PayPal or Square, there is some work that needs to happen to integrate into the event system.

Ronald: And you engage with these parties, with these developers so they don’t certainly find themselves at a big surprise, “Oh, here’s another update. It doesn’t work anymore.” Because they represent thousands of merchants, of course.

Nadir: For us, the Cart and Checkout Block are still in the future plugin. They are not yet part of WooCommerce core because of this. We don’t want to present a solution yet that doesn’t work with health for the payment getaway. So it’s been a catch 22 issue. Sometimes we reach out to payment providers. We ask them, “Hey, this is the documentation.

An example. Can you integrate your plugin with the cart block.” And they would say, “No, we won’t do that until checkout block is part of WooCommerce core and we can’t get it part of WooCommerce core unless we get that.” But we still work with payment partners. So as of right now, as of this couple of weeks, I am working with Amazon pay, with PayPal, and with Cloud and to get some integration going.

And we also reach out to other people. Developers reach out to us usually and we communicate with them. We provide some guidance if they have any question usually. Our get up is very well maintained. So if a question came in, it’s usually answered within a couple of days or so.

Marcus: For plugin developers working on payment gateway, plugins and integrations and stuff, is the best way to keep on top of some of the early releases that are coming out. Make sure that plugin developers are downloading those, and testing those, and making sure that everything is working.

Nadir: Yes. And we try as best as possible to make everything backward compatible. Even this is a future plugin. Everything we do is backward comparable. We don’t just change an API over day. I think as of last year we changed it a couple of APIs, but we had some duplication handling and we left them there for six months, and we chat to developers. Even if there is just one plugin that’s using that TPI. We would still want to reach out to them and make sure that whoever started building on the new Cart and Checkout Block can be rest assured that we will not suddenly be changing stuff for them.

Marcus: Yeah. I feel like the WooCommerce team does a pretty good job of keeping people up to date on the blog and stuff about things that are coming out, the change logs, things that are being deprecated and stuff. A few big players in the game that you probably talk to, but for all the other payment gateways, it’s best to keep up. To see what’s going on, what’s new and make sure that the code is up to date to make things work the way that it’s supposed to work.

What the future of Woo checkout looks like

So you work on Cart and Checkout. I know that checkout has been a hot topic with WooCommerce and stuff. What is… I guess, what does the ideal checkout look like for WooCommerce in the future? Let’s say I have a brand new WordPress site. I throw WooCommerce on it. What am I looking at? Is that going to be… Are those pages that are automatically generated going to be generated with blocks on them? What is the future of the checkout look like?

Nadir: So as of right now, as I said, the Cart and Checkout are still in the future plugin. And we want to make them available in WooCommerce score. And we have a couple of payment providers that we want to finish first before we go that. So it’s mostly PayPal and Amazon. Once it’s there, the new Cart and Checkout are going to be available, but they’re not going to be the default. Once they’re available, we know that more plugins will be motivated to start integrating, and then we’re going to help them.

And when we feel that a good portion of the market has integrated their plugins, we’re going to start to make them the default experiences for new start. This is still up on exactly how we’re going to implement that. But what do we want to do is that, once you unstart WooCommence as a fashion start, the WooCommerce block is going to be there.

And we will try to detect if you have running plugin that does not integrate with the checkout block. And if that’s so, we’ll probably just replace it with the shortcut one or issue some warning or something like that. And it is still a bit of a long way when the checkout block is going to be the default one. And we have no plans at all of removing the shortcut on its own to be stated.

And definitely, at least to my knowledge, we don’t want to delete it because we know there’s a lot of use cases for it. That’s a lot of people who will not update or will not integrate or who do very specific things with checkout that the new one will not probably not enable. We’re going to keep that.

Marcus: Yeah. Is the checkout block a container for a number of different blocks? Is the checkout block going to rely heavily on the settings in the sidebar, how does the checkout block work?

Nadir: The block itself is a container, but it’s a shallow container. It has a lot of the logic of a checkout. So the data processing and stuff like that does come with it. But inside of it, it’s just a collection of blocks. And so our goal is that you can select the shipping address block, and then you’ll see the shipping address. You’ll see the shipping address settings, and if you can add fields in line. You can change the text. You can change the titles, you can place new blocks.

Let’s say a third party developer would want to build a block that instead of having a list of just, let’s say, shipping at a shipping method. You get a map for pickup location, stuff like that. And this is going to be possible with developers building blocks and those blocks just integrating there. And one thing we are looking for in the future is how can we enable different configuration of the checkout?

Let’s say your shop only sells courses, or only shared digital stuff. We probably will not want to need the shipping address in the order. And you might want to tweak how your checkout look and it’s going to be just possible within Gutenberg.

Ronald: That’s very powerful, isn’t it?

Marcus: Yeah. I was going to say really the third party integrations there goes way beyond just the payments providers. There’s a lot of other Cart and Checkout related plugins that are going to want to make sure that they stay on top of that as well.

Ronald: Yeah. All the coupon codes, or if you do a checkout in a cafe bar and you just want to add your table number, you don’t need everything else. So you can quite easily disable that, add that, or add your whatever earned air miles into it. It’s going to be very powerful to make those changes quickly. Very exciting.

Nadir: Beyond payments, examples include the MailChimps and the MailPosts of the world, the newsletters where they can choose how and where you’re going to collect your concept for newsletters. Future plans also include us going into different pages beyond Cart and Checkout. So the thank you page is also going to be a block based. And the my account in the future is also going to be block based. And you can customize those things to your business without using code.

Thanks to our Pod Friends Captcha 4WP and Trustpilot

Nadir’s journey to Automattic

Ronald: Nadir, your journey into Automattic. And how did you get where you are now? Tell us a little bit about that.

Nadir: I’ve been working as a freelancer since I was 17 years old. I did WordPress and WooCommerce. I had a WooCommerce agency back in the day. And I was working mostly on front and stuff. So, period to joining Automattic, I think the last project I was building was a hitless shop for a client. And there was no store API back then, there were no stuff so we had to build a lot of the stuff from scratch.

At the same time, I was running a co-working space in my city, and I met someone who works at Automattic in that co-working space. He introduced me to the company and what they do. And I started to get to know Gutenberg. I wasn’t really a big fan of Gutenberg, but this person was the lead developer of the Gutenberg projects. So I started to get to know the project, stuff that.

And I started to like it, and started contributing. And then decided I might want to switch from doing freelance into this company. And I was placed on the blocks team. And from day one, the week I joined it is the week we started working on Cart and Checkout. So I was there since the first line, which is almost three years now, basically two and a half years.

And I’ve been working exclusively on that team for that duration. I worked as an engineer, then at the beginning of this year when our team splits. So we have a full editing team and now our Cart and Checkout team. I become the engineering manager for the checkout team. And I did that for six months or four months, and discovered that being an engineering manager is not for me right now. So I switch it back to being an engineer and someone else from our team happily decided to be our engineering manager. And she’s been doing a great job ever since.

Ronald: That’s quite the journey to what you’re doing.

Marcus: Yeah. You said you were freelancing before. How much of that was writing code? I would imagine that’d be a bit of shift from building websites to then being part of the fundamental code that helps others build websites. How is that switch?

Nadir: My journey into freelancing has been a bit disjointed. Well, in the later half of it, I started focusing on WordPress. Before that I was mostly working on frontend stuff. So I would do contract job with companies for six, nine months, being their frontend guy. Building their pages and performance stuff. When I was doing freelance for the WordPress, I was a bit lucky to be able to decide on what projects I want to work on. So I was always trying to limit them to the technically challenging projects mostly. And this project would take three to six months. And the business of it was not really complicated a lot for me because I was not taking a lot of project a year, but those were a bit of a complicated project.

So I managed to try these problems, get an idea of a lot of the limitations and things that a developer would go to into building the stuff. I also build plugins at some point for WooCommerce as well.

So when I joined the WooCommerce team, I had an idea of what kind of issues me as a developer were to [inaudible 00:20:20]. What kind of documentation I would appreciate, what kind of APIs I would expect. And I brought with me the wrong assumptions I had about this developers team, or about what I think a problem should be solved in a specific way. But once I joined this team, it took me some months to fully switch from the mentality of a freelancer to a consumer of these things to mentality of someone who is building.

Ronald: But that’s really valuable feedback and experience that you’ve brought to the team. Because to have a view from both sides of the experience is, of course, incredibly valuable. Especially when it comes to rolling out new features and new releases that you have that in mind. That actually on the other end, you have the developers, and further that, you have the merchants that might face all these problems.

So for you to double check, and check in and check in again, and test is, of course, really reassuring as well for whoever’s listening to this podcast. Knowing that the Cart and Checkout blogs are taken care of by people with experience. And experience in what it’s like to be in their shoes. So I think on behalf of everybody, thank you for looking after that project for the last three years. And hopefully that you will continue with that.

Nadir: The team I worked on at that point also included our previous team lead, Darren Ethier, who is now leading the force editing team. He also had a lot of experience being a consumer. We also had on our team, Mike Shirley, who had a lot of experience on WooCommerce as well. So we brought those informations.

They switch it from a team that I worked on and get up to working with us internally. And they brought a lot of perspective that I was simply missing. As a team who builds plugins for a living, they brought new perspective that we didn’t have. Because I had an experience as a developer building custom things, but I was struggling to see it from a plugin author who has 10 plugins to maintain. Who has a lot of backlog issues.

And who’s struggling to lean React, to lean JavaScript. And how do we balance a lot of the stuff? So, when the summer warn team joined Automattic, we unlocked a lot of the stuff. We saw a lot of the problems, a lot of limitation that they had. That they pointed us to us. And we are actively working with them. I think as of this week or next week, we’re going to start rolling out a series of articles into using Cart and Checkouts for those kind of developers who are completely new to JavaScript, or completely new to React. And this perspective has been really helpful for us as well.

Ronald: Yeah, that’s incredible. But the way I see it, it’s a living and breathing machine, the open source and WooCommerce and WordPress. And people with experiences just come in, they add their flavor to it. I know in Automattic, lots of people stay there for a very long time. But it evolves. It’s not a company that’s closed and you join, you have to learn and you do things maybe based on what people’s habits are. You’re open to bringing your own experience. And I think, it creates a very healthy atmosphere and of course platform or not platform, but the software itself.

Marcus: Yeah. I mean, I think that’s important to note too, that the people building WooCommerce are also people that use WooCommerce. And I think that gets overlooked a lot. And that’s not just this black box of how do we build a piece of software? It’s how do we build a piece of software that serves developers, that serves customers, that serves merchants? And how do we do that best for everyone? And those audiences are also the folks that are working on the project themselves.

Thinking about the number of stores and the responsibility

Ronald: Yeah. It’s a responsibility. Do you ever wake up, Nadir, in the middle of the night? And think, “Whatever I’m doing is going to affect three, four, 5 million stores.”

Nadir: It is. I remember as four, five months ago, I was setting up some of the guidelines for how we built extensibility APIs. And if you look at WooCommerce or WordPress back in the day, it was a bit liberal into how you add filters and hooks. As of now, I started to think, “If we don’t do this right, it’s going to affect millions of shops.” And each shop has thousands of customers. This has this much impact. So we have to respect that responsibility, which is… Sometimes it’s a bit daunting, really to handle this much responsibility. We are affecting not just the livelihood of developers, but the livelihood of merchants as well, who rely on this to make an income.

Ronald: Sorry, just to throw in the figure that $31 billion revenue went through WooCommerce as I think Matt Mullenweg said in another episode in January.

Marcus: Yeah. No pressure.

Nadir: I think one thing I really love about the WooCommerce team, and people I have been working with is how much cultural background each one brings. For example, I remember nine months ago. We had a designer working on the marketing channels for WooCommerce and she’s from Singapore. And she brought a lot of perspective from the Asian market into how they do e-commerce. Which is completely different from the perspective that people in the US will be doing e-commerce than the one in Europe.

So there’s a lot of reliance on marketplaces. There’s a lot of different way to shop. For example, I’ve been also trying to bring some changes to the way we do checkout. Because for example, in my country, we don’t do emails. Emails are something very rare and only done on businesses.

But for your day to day people, phone numbers is the way to go. And for example, if you look at checkout right now, it requires an email. So while email is probably used widely in US, in Europe, it’s not used at a lot of other countries. So I’m starting to look into, can we use phone numbers as a primary way of making checkouts?

This is some of the perspectives that some of the people on our company, like sometimes Brinkley. We have someone from Japan who would say, “We do e-commerce this way. Locally, this is how we do e-commerce.” And then we have to balance all of these needs. Which is really interesting for me to see sometimes.

Ronald: That’s a great example.

Marcus: That’s interesting because it filters all the way down, I think, to the WordPress experience, right? Most of the time you create a user account. And WordPress, it’s a username and an email address. But if email addresses aren’t so widely used, then that filters down to, “How do you create accounts on the WordPress site itself?” Which then becomes the customer account and all of that.

Nadir: Yes. This problem, for example, it is a complicated one and I know that some other platforms are looking to it. or example, Shopify has the ability to only check out with a phone number, for example. And some other platform like Facebook or Instagram, we don’t need an email.

We don’t have the scale of Facebook, or the scale of Instagram that we have offices all over the world to be able to do this stuff. But when you have a remote company with a lot of people, you start to get into that perspective pretty easily.

And I think this is very important when you are building open source solution. When the mission is to democratize commerce, you need to look outside of your conference also. You need to look outside of your main consumers and see what new markets or what different countries are doing in their e-commerce experiences.

Ronald: Have you joined any of the meetups yet? Since the lockdown, COVID period?

Nadir: I didn’t have a chance. The first meetup I was going to was WordCamp Asia, and that one was canceled. And then we didn’t have anything yet since then. I was hoping to join the next meetup in Europe, but my visa never came through. So I’m probably not going to attend it.

Ronald: That’s a real shame. Because I know working remotely or distributed has its advantages with what you just described with working with people from of all over the world, and adding perspectives. But it’s also really important to meet each other. And actually have that one-on-one, and understanding people’s sense of humor, and what makes them tick, for example. So hopefully we’ll see you at some word camp or some other division meetup.

Nadir: Hopefully, yeah.

Ronald: Yeah, yeah. That’s really very insightful. Thank you so much for sharing your story. But more importantly, the journey you’ve embarked on with driving the project or co-driving the project on Cart and Checkout blocks. I’m actually very excited to learn a lot more about it and see what is coming out.

I know there’s some big changes happening to WooCommerce. I think the blocks is one. Also the database changes, product tables will change. That’s another big one that will affect a lot of developers. But again, it’s going to be backwards compatible. So that’s also really reassuring. Marcus, any last final thoughts before we wrap up this episode?

Marcus: Nope. Thank you so much for coming on, Nadir. And yeah, I’m very excited for what the next year or two holds for WooCommerce. Exciting changes.

Nadir: Thank you. Thank you. Thank you all for having me today. It was really fun to talk to you.