The Modern WooCommerce Developer Workflow

James Kemp:
Welcome to do the Woo, the podcast where we talk about all things WooCommerce. I’m James Kemp, the core product manager for WooCommerce.

Katie Keith:
And I’m Katie Keith, founder and CEO at Barn2. And today we’re going to be talking about development tools and workflows for building WooCommerce stores. So the way you build for WooCommerce has changed in many ways due to things like blocks, AI assisted coding and so on. And plenty of builders are working out their setup as they go along. So we wanted to get expert advice on the best approach for modern WooCommerce development.

James Kemp:
Yeah. And before we get too deep into the conversation, it would be great if you could subscribe to our channels. We’re on YouTube at Do the Woo podcast. We’re on X at Do the Woo. Or you can visit our website atdothawoo.com.

Katie Key:
now let’s get into WooCommerce development. To discuss this, we’ve invited Brian Coords as our guest. He’s developer advocate at woo. Hey, Brian.

Brian Coords:
Hey, thanks for having me.

James Kemp:
Brian, thanks for coming on. Why don’t you start by telling us a little bit about what you do at Woo?

Brian Coords:
Yeah, so I’m a developer advocate, which is kind of a weird role because you’re half in the development side and half in the marketing side. So I. I see. Our primary job is connecting the engineers inside of WooCommerce to the broader community. That could be if you’re building stores, if you work at a store that you know, where you handle development yourself, if you’re at an agency, if you’re building extensions for Woo, you’re trying to sell plugins in the marketplace, that sort of thing. Or if you’re just trying to contribute to WooCommerce and push changes to it. So our job is to basically listen to what the community needs, listen to what they’re talking about and bring that back inside and make sure that we’re actually building the things that the other developers want.

Katie Key:
Yeah. So on a day to day basis, how specifically can you support developers? Can people contact you directly? Is it more indirect than that? How does it work?

Brian Coords:
Yeah, I mean, we have a Woo community slack where we definitely get DMs and messages from people. They interact with us on social media. I try to pay attention to the Woo subreddit, which is pretty active and popular. And so we also show up at conferences. I’ll be at WordCamp. Us, we went to Checkout Summit. So, yeah, I would say that getting DMs from people in the community is a pretty regular occurrence. But also just engaging online and trying to be as available as possible.

James Kemp:
What would you say is the most popular channel at the moment?

Brian Coords:
Probably X. Twitter. I feel like that’s where you see the most. I also feel like LinkedIn has a really strong WordPress WooCommerce community because there’s kind of WooCommerce has that more business aspect than like, vanilla WordPress. It’s very, you know, people are using WooCommerce to build business, make money. So I feel like LinkedIn is like, also a place where I keep meaning to put more time into it because I do see a lot of good posts and conversations there.

James Kemp:
Yeah, LinkedIn’s an interesting one. It’s. It’s changing a lot, I think. I. I still have this stigma that it’s kind of fake. Like, the posts you see there are kind of very orchestrated.

Katie Key:
You just unfollow those people.

James Kemp:
Yeah, yeah.

Brian Coords:
Every social media has its downside. You know, LinkedIn can be a little fake. Twitter. Twitter can get a little too heated and political. It’s just every social media channel has its, like, pluses and minuses.

James Kemp:
That is true. Well, let’s dive into the conversation. I think a good starting point is to talk about how you can kind of get set up locally to, to run WooCommerce as, you know, either someone who’s building a website or someone who’s building extensions on top of WooCommerce, or even someone who wants to contribute to WooCommerce in the form of, you know, a PR or a code change or a documentation change. What is your personal local stack?

Brian Coords:
I would say it depends on the situation. If I need just like a really quick vibe check on WordPress and WooCommerce, I’ll use WordPress Playground and I’ll spin up like a disposable site just if I want to. What does this page look like? What does the setting look like? If I’m working on WooCommerce itself, like, we do a lot of work in the documentation, which is part of the same repo that WooCommerce itself is in. Then I’ll use the bundled in, you know, environment for that. But other places, I think WordPress Studio is a pretty good one. It’s kind of like a local development app that handles, you know, sort of just setting up websites. And then I personally, I would say the most that I use is actually it’s called Herd. It’s Laravel’s local development apple. But it’s honestly, it’s fantastic for WordPress because it handles the PHP, it handles the JavaScript comes with like a database, it has an email tracker and all that sort of stuff. So that’s kind of my go to. But otherwise Studio, Playground, those are the

James Kemp:
other things I saw Studio used to kind of run on Playground.

Katie Key:
Right.

James Kemp:
But I think they’ve just updated it so it bundles PHP as well, which is interesting.

Brian Coords:
Yeah, Studio is. It’s great, it’s fast. It has like a built in coding agent. It integrates with like Pressable and WordPress.com and all that sort of stuff. But yeah, it’s not quite the same as a actual hosting environment because of the way it’s built on Playground. So it’s. Sometimes I know they’re working towards it because the database is different. The way it runs is a little bit different. So if you have a really big WooCommerce store, it probably won’t work. If you’re just setting up something fresh, then I think it’s probably a good one.

James Kemp:
Yeah. On the, on the playground topic, I have, I don’t know if you use Raycast. It’s a thing that replaces what do they call it, Spotlight on Mac. I have a little shortcut there that I just type in Woo and it spins up a Playground site with Woo, installed some test products and like loads of that stuff. And you can kind of spin up a fresh WooCommerce site in I would say 30 seconds, which I find really useful for. Similar to what you were describing, like how does this page look right now in WooCommerce? Like what’s this setting default? So that’s a pretty useful thing to do, I think. Over on my blog, which is jamessecamp.com, i have a post about how I set that up. So if anyone’s interested, it’s pretty convenient.

Brian Coords:
And we also have the WooCommerce beta tester plugin that I would recommend if you’re. If you’re not going to pull the full WooCommerce like repo down and deal with all the build stuff. There’s this beta tester plugin that you can put on any like local environment or a staging environment. And it lets you basically say like, can I try the next version of Woo? Can I try the. The beta of whatever the next version coming out is? Can I turn on and off some feature flags and stuff? It gives you a NCUI for that. That’s another piece that I recommend. If you don’t want to do the full like I’m going to pull down Woo and build the entire monorepo.

James Kemp:
Yeah, with the feature flag stuff, there’s a few ways that we being WooCommerce reveal feature flags. One is that they get shipped with Core and you see them in WooCommerce settings, advanced features. I think that’s the right breadcrumb. And you can kind of toggle them on or off over there. But they’re not all available there. They’re only available there if we explicitly add them to indicate, like, okay, this thing is ready for the general user to test. But there’s also many other feature flags that exist within the code base that you can toggle and the beta tester plugin reveals them. So you can turn them on quite easily there. Otherwise you can use like a code snippet. But yeah, the. The plugin is very useful for that stuff.

Brian Coords:
Yeah, you can turn them on with CLI commands, you could turn them on with code snippets. You can database, you can change literally the option. There’s a lot of stuff there. But I think shout out to Luigi, one of our engineers, he’s been doing a ton of work just streamlining the feature flags, making sure we have a good system for it, making sure it’s really easy. Because sometimes there’s features that are something you can turn on and off, like indefinitely, like high performance order storage, for example. Like, that’s a feature that you can turn on and off. There’s a few other ones. So not all of them are experimental. Some of them are. Some of them you can probably run on a production site. Some of them you probably can’t. So he’s been doing a lot of work to, like, give us a really good system for that. So everybody knows what you should turn on, what you should not.

James Kemp:
Yeah, and also cleaning it up a lot. Getting rid of feature flags that have been deprecated for a while. You’ll have seen the product editor experiment from, I think, two years ago now, when it was deprecated, just kind of existed in the code base for a long time and that’s been removed now. I expect to see a lot of work around those feature flags.

Katie Key:
I have a question about the feature flags, which is in terms of building on top of them, obviously people don’t want to waste time on something that might never actually be continued. The product editor is a good example. But a lot of the new features, they might change significantly before they’re properly rolled out. For example, what would you recommend in terms of people that find these upcoming new features useful and are excited about them, but also don’t want to invest a lot of time in extending or developing on something that may not go ahead.

Brian Coords:
Yeah, that’s a good question. Some things we mark as experimental. If you go to that features screen, there’s features at the top that you can just turn on and off. Like, what was the one cost of goods sold that James pushed through? That’s a feature you can turn on and off, and you’re safe to use that. Then there’s a second section called experimental. That stuff is definitely, I would consider more like alpha features. Not even a beta, but like alpha, where things might change. You should definitely test them and give feedback because it’s a really good time to let us know, are we doing it right? Are we building what you want? Does it work the way. But as far as incorporating it into your live site or building a plugin on it, I probably wouldn’t do that until it moves out of that experimental phase.

James Kemp:
I agree. I think it’s useful for particularly plugin developers to try those features and try extending them to see if they actually suit what they want to do. But more than likely, those features that are marked experimental will change. You would probably expect that the features that are above that outside of experimental won’t change all that much. They may get new stuff added to them. But, yeah, usually the feature would kind of work its way through this kind of hidden feature flag that you can see in the beta tester into the experimental section when it’s pretty much like, I would want to say, like 80% ready, which I guess wasn’t the case for the product editor. And then it would move out of that when it’s. It would either move into the section where you can turn it on or off, or it would just become part of Core that’s, you know, always on, typically. Yeah. I think, like Brian was saying, one of the things we want to do is make it really clear, like, what that process looks like to help developers understand, like, okay, now it’s ready for me to actually build a thing that I know is going to work on top of this and get released. But also for us, we really need to make it easier for people to test these experimental features and feedback to us, because that many people do.

Brian Coords:
Yeah, there’s a really strong group in the community that will test a lot of these things. And that’s just features. There’s Also, you know, WooCommerce has a new version every five weeks, so there’s also just a general amount of testing that needs to happen. For the platform, because if you’re building on top of it. But I would say if you’re. If you see a feature, we post them on the developer blog. Usually when we’re looking for feedback, we post a call for testing. There’s usually a GitHub link that you can give your feedback. Those links generally get really lengthy with conversation. But if you see a feature and it’s sort of related to something that you do on your store or a product that you sell, that’s probably a sign that, you know, your feedback would be most valuable to us.

Katie Key:
Yeah, it’s definitely worth looking out for. So another thing we wanted to discuss, which builds on the previous one, is how to extend WooCommerce in the best way. Because obviously with. Even though it’s open source, you can’t just go and edit WooCommerce itself. You have to do it from outside. So what are the best practices that you would recommend that developers follow when building for WooCommerce?

Brian Coords:
Yeah, so WooCommerce is. I mean, it’s a complicated piece of software because there’s the actual server, that’s the PHP and it’s running, processing your orders and doing all of that kind of work. Then there’s like the front end, your storefront. You know, maybe you want to change the design, you want to change how things are presented to users. And so there’s a lot of different places. I would say the number one thing is to start with our developer documentation because we kind of try to give the best approach. Stay away from touching the database directly. There’s anything you want to change, there’s a function or a filter or a hook for it. That means you should. You’re free to do whatever you want with that, but changing stuff in the database directly or changing the way that like the actual code internally works is something you should probably stay away from. I mean, when I worked at an agency, we would get sites where they would say, oh, don’t update, you know, this Woo extension because they changed the code for it and you just have to keep it on an old version. That’s definitely not the approach you want to take. You want to, you know, have an approach where you should be able to update all your plugins and extensions safely because you’re only using three filters and hooks that are provided publicly and documented. And you’re only using some of these wrapper classes that if you want to edit an order, there’s a class to edit your orders, to fetch your orders and stuff. If you find yourself writing actual Database level code, like you’re writing SQL commands, you’re probably going down the wrong track and there’s probably a safer way to do it.

James Kemp:
Yeah, I think that’s a fair assessment and I guess like it bubbles down to WordPress standards as well. Like WooCommerce is a WordPress plugin and it’s been built in a way that is typical of how you would extend WordPress. So the best practices that apply to WordPress also apply to WooCommerce. I think one of the things that is slightly changing that approach is like the block era of WordPress. The ways to extend blocks and sort of react based code has changed slightly from hooks and filters. I wonder what your thoughts are there. What’s the best way to extend say for example the product options block. Like is it possible to do that or.

Brian Coords:
So blocks are a different story for sure. The first thing I recommend is actually making sure you’re using WooCommerce’s blocks because we’ve seen a lot of situations where people are trying to build their own custom thing and it’s like actually our blocks do that. The product collections, the filters, they’re all pretty like they cover most of the area. The cart and checkout are pretty robust blocks. They, you know, know they convert better. They’re, they’re really battle tested. If you’re getting to a place where you actually want to change how a block works, that’s where it gets a little trickier. There’s a few things, there’s, there is the concept of filters in WordPress, like the JavaScript side of it. So there are filters for specific things. Like I want to inject some extra content here. I want to change the way this content works that exists. The, some of the blocks around the product area, they pull in like template parts. So you can actually design in the block editor and swap out the templates template parts for it. And then if you’re getting past that, there is an option to build custom blocks. But we’re really rethinking how a lot of this works right now. One of the big pieces of WordPress is something called the Interactivity API. And that’s what handles like interactions on the front end of your site. Like if I click a button to add to a cart, the cart pops open and it gets populated. That level of interactivity is handled through something called the Interactivity API. The team that built it worked with Woo for like, I don’t know, the last year or so. They were basically building blocks, building it out, making it more extensible and so that’s going to be the approach going forward, but we are still in a bit of a middle ground where that area isn’t fully set up yet, but it’s getting there. So I would say just only use the available filters, you’re always free to make your own blocks and always use core things. Like we have what’s called the Store API, which is the API on the front end of your site that manages adding things to carts, fetching products, all that sort of stuff. It’s very well documented, there’s a way to call from it, make changes to it, all that sort of stuff. And so if you’re doing that properly, you’re generally not going to have a problem. And then if you’re actually changing stuff like at the server level, like, oh, when an order comes in, I want to apply this coupon, I want to apply that sort of stuff. You can basically use PHP for most of that because every time somebody interacts on WooCommerce we do have to go back to PHP, back to the server, update the order in the database, all that sort of stuff. So a lot of those filters and hooks at that level still work pretty well. But yeah, the front end markup is a little bit trickier and you do have to be a little more cautious there.

James Kemp:
Yeah, and I think it’s important to note that we are, our goal is to be extensible. Like that’s, you know, one of the reasons that WooCommerce is so successful is because of how flexible and extensible it is. So there’s definitely a shift in the approach to what that looks like today. But I would say if there’s something that you’re trying to do and it’s seemingly not possible to do it, then, you know, Brian or myself are perfect people to reach out to and just like state your case, like, what are you, what are you trying to do? Why are you trying to do it? And how could we help make, you know, WooCommerce more accommodating to, to that.

Brian Coords:
Yeah, you can post in the Woo community Slack, because there’s a lot of people in there that do this every day. They work on that extensibility stuff and they, the engineers at Woo are pretty active in there. You’ll generally get your questions answered. It’s a pretty good place. And then of course, you know, I’m sure we’ll talk about AI, but it’s with the way you frame things to. A coding agent is also super helpful because they’re generally pretty aware that there’s a way to extend WordPress and a way to extend Woo and a way to do it right.

James Kemp:
Yeah. Something we didn’t touch on in the local setup part of this conversation. In the WooCommerce repository on GitHub, we have a bunch of agent skills that live there as well. So there’s skills there that kind of help guide your agents in terms of actually setting up the repository, coding on the repository. So actually like back end developer, I think there’s a front end developer one as well. There’s. There’s skills there that help you create commits and create like draft PRs. So there’s tons of skills in the repository that can help with this kind of thing. And part of the work that Luigi is doing with cleaning up like legacy code, like the product editor is going to help guide the agents a lot more as well to sort of understand the actual way that things work. It can get tripped up by, you know, code that was experimental, like the subnet, how we do things currently. But yeah, I, I think, I think that’s a, a very useful way to do things.

Brian Coords:
Yeah, the agent skills have been super helpful. Um, I’ve been doing a lot of work on basically documentation cleanup because when you load WooCommerce, there’s a ton of docs inside of it that basically show the crop the proper way to do things and stuff. And so I’ve been seeing those skills in practice because I’ve been pulling up an agent, I’m like, all right, lets we work on this piece of documentation. Pull it in and it’ll read the thing. How do I make an issue? How do I make a pr? It’ll do all that for me. There’s a template to fill out. It’ll do all that for me. There’s testing steps that are very specific and tests that you can run that’ll build it and it does all that for me. It’s pretty intense how well the agents can really interact with the Monorepo now

James Kemp:
for sure. Sounds like you’re new.

Brian Coords:
That’s my four year old. She is opinionated and that’s what having four older siblings boss you around will do to a four year old. She’ll. She will quiet down soon.

James Kemp:
I think she is unhappy with the conversation.

Katie Key:
Yeah.

James Kemp:
Something that was, I think announced or released or is experimental recently is this concept of sort of automatically converting php settings pages in WooCommerce into the new React powered WordPress components. Do you know much about that?

Brian Coords:
Yeah. So as the front end of WordPress is converting to Blocks and converting to, you know, the more modern side, the backend of WordPress and WooCommerce is also getting that same treatment, which is, can we convert all this to React? Can we have a more unified design language? Can everybody, you know, use the same components and everything look the same? And so for WooCommerce, I mean, there’s a ton of settings pages. I mean, there’s settings pages for payments, for shipping, for integrations, for webhooks, for email, all these different things. But we’ve had a really solid class that you can use to make your settings pages where you just say, these are the fields I need. It handles saving, it handles storing, it handles all that stuff. If you do it the WooCommerce way and you use the classes that we have, it just works. It all worked in PHP to convert it to React. All of our own extensions basically said, all right, we need a way to do this without having to rewrite everything. You already have all the logic in php. We know what the components are. Fields are pretty consistent. Checkboxes, dropdowns. It’s pretty standard stuff. They basically said, could we write like, a function that would just do it for you? And so that’s rolling out 10.9. It rolled out sort of an experimental level. I think Woo Payments is the first one to use it. I think 11.0 is where you’ll see some more of it come out. But it’s literally, if you’ve been making settings pages the proper way before, it’s literally adding a line of code and we’ll just handle giving you the modern React version of it. You don’t have to actually write any JavaScript for it. So that’s pretty nice because, you know, WordPress is still in this, like, weird half shift between modern WordPress and kind of classic WordPress. And so we’re trying to do it in a way where it’s minimal effort and it’s not, oh, I got to rewrite everything with React. And so, yeah, that’s called the Settings ui. It was the Settings UI SDK. I think it’s just called the Settings UI now. And so, yeah, we’re going to have some tutorials and posts about that probably by the time this podcast comes up.

James Kemp:
Amazing. Yeah, I think it’s tricky because WordPress has allowed you to essentially output anything. The way that the new UI works is that it’s expecting specific types of fields, I guess. But like you say, if you’ve registered your settings pages using the appropriate methods from WooCommerce, then I think they’re already fairly well defined.

Brian Coords:
Right.

James Kemp:
I don’t know if they allow inserting essentially custom HTML to output your own fields.

Brian Coords:
Yeah, so that was part of the issue, is sometimes you do need a custom thing that’s just a little bit more advanced. In the past you would do that by passing a filter that would show, here’s my custom setting. It’s very complicated. I wrote it myself. So we have the same thing on the react side, which is if a field is not just a typical checkbox or a text input, you can actually write your own react component and it’ll just pull it and put it in there. And again it’ll still handle like saving the settings, putting them in the database, fetching them, all that sort of stuff. So you kind of don’t have to do a lot of the work. And I feel like that mentality is important to WooCommerce. I think that’s how high performance order storage worked, where if you were doing things the right way before high performance order storage, you didn’t have to do too much work afterwards because all the same functions worked, all the same stuff worked. But if you were getting a little creative, like I said, or doing direct database calls, or doing your own kind of weird thing, that’s fine, you can do that. But now it’s not going to work with the new thing. And so it really is important to build off of like the actual foundation. And it’s our job to make sure that we’re documenting that and showing how to do that properly.

James Kemp:
You mentioned custom blocks. I think that’s a good segue into the next question that we have or topic that we have. What’s. What’s the best way for people to actually build custom blocks with less friction? You know, I know for, for me, like I, I came into WordPress and WooCommerce very much as a PHP developer and I think a lot of people who have been in WordPress for a long time have kind of come from that PHP background and even like WordPress’s PHP is, is very different to how other places use PHP or like other software uses PHP. So it’s essentially like learning a new, I mean it is learning a new coding language, right?

Brian Coords:
Yeah. WordPress, we call it the WordPress way. You know, it’s, it’s its own way of doing things. I can go back and forth on this because it is, you can do a lot of stuff with just PHP. One of the things that WordPress 7 added is you can actually write blocks with just PHP and so you don’t have to write any JavaScript. There’s definitely some advantages there because JavaScript is messy. You have to have a build process, you have to run all these command line tools to get it to compile every time you want to do it. The dependencies change all the time and you’re constantly updating those sorts of things. And so I think the PHP only block thing that they added in some point zero is probably pretty helpful because you can really just write a block in PHP and you can use all your standard WordPress stuff like WP, like GET posts, get orders, get products, and you can pull that information, write it all in php and let WordPress handle showing up as a block, let it handle injecting it into the page, all that sort of stuff. So I think it’s going to probably follow that same approach, which is like, how can we just give the tools and give everybody the total freedom. But I will say on the other side, if you do like writing JavaScript and React, AI loves to write React. AI loves React, it writes it very well, it will use it if you don’t ask it to. And so that has been sort of a like hidden benefit of the React era is if you do need to go really custom and build all this stuff, AI is going to write React very well, it’s going to write PHP very well too. But React specifically, it’s pretty good. And that’s kind of been a benefit of using React versus WordPress, making its own weird JavaScript stuff. At least on the JavaScript side we’re using what everybody’s using and it makes it a lot faster for that sort of like agent coding.

James Kemp:
Are there any skills for that? Agents?

Brian Coords:
Yeah, I go back and forth on the skills. It feels like everything in AI is after four weeks, everybody’s like, oh, you don’t need that anymore, you need this other thing or something like that. I mean, skills are essentially just, you know, long prompts that you feed into it. There are certain things where the skills are Useful. I think they’re useful for like when things are weird, when things are specific, when you want stuff done like a certain way. So for general react stuff you really don’t need skills for general WordPress stuff. Like I don’t really find that the skills add anything to it because WordPress is so old, so well documented, so popular, like agents can do all that sort of stuff. Where I think skills are going to come in handy is those weird specific things of WordPress like the Interactivity API, WooCommerce’s Store API or checkout blocks, that sort of stuff. And so there are some skills for WordPress, there are some skills for Woo. And so I definitely recommend loading those. But I’m not a huge. Like, I got really into skills and recently I’ve been kind of like, I don’t know, I don’t know if they’re adding as much as I thought they were or maybe just the models are getting better, I don’t know.

James Kemp:
Yeah, I think there’s a lot of context required. I think if you’re building a plugin that adds a custom block, if the agent has the context of the WooCommerce code base, it can access it in some way. That’s typically enough for it to figure out how best to create something. I found.

Brian Coords:
Yeah, if I, if I’m working on a WordPress site, I usually load my agent at the root of WordPress so that if it needs to, it can search all my plugins and it can read the code. I think that’s one of the best things about WordPress is you have full access to the code. If you’re building on some other platform or something, the agent isn’t necessarily going to know what’s happening behind the scenes because it’s all off on some proprietary platform and it just kind of has to use the tools available with WordPress. I will ask it to do something and it’ll go, okay, I’m going to go look at WooCommerce subscriptions entire code base because it’s right here in front of me and I’m going to read and I’m going to find the filter that I need, I’m going to find the hook. And so it’s just your job to make sure you guide it and you keep an eye on it and make sure it’s not going to do anything that’s not going to like survive an update or something like that. But yeah, it’s a huge benefit of developing with WordPress that you can just look at all the code.

Katie Key:
Yeah, well, let’s move into the AI side of things in more detail. We’ve touched on it a few times, but I wonder how much of what we’ve talked about is actually irrelevant given that you can just use AI to do everything. How does that affect things like your local setup and your. Your overall approach? Because it’s fairly transformational, isn’t it?

Brian Coords:
I mean, AI has definitely transformed how I do my day to day work. It’s weird how much time I spend inside of. I’ve been using Codex a lot recently, which is if you use cloud code, it’s just like the OpenAI version of that. But it’s just really nice app. Like it actually got me out of the command line because the app is so just nice to use. But yeah, it’s definitely a change in the way that you work. I think we’re starting to find the things that like, AI just can’t do. There’s certain things where it’s like you really just need a human. You need like your own opinions, you need your own sort of expertise there. It’ll go off the rails if you just like give it free reign and stuff. But on the flip side, there’s a lot of things you can add to the coding thing where you can add, like if you have a local environment running, I tell it, all right, you have WP cli, which is a command line tool that lets you interact with everything inside of WordPress and Woo. You have access to that. Here’s how to use it. You have access to the browser. So open the browser, test the thing before you tell me that it’s done. It’ll open up a local WooCommerce store. It’ll actually click all the buttons and make sure they do the things that it says it’s going to do. If I need test data, I just say, all right, give me like 10 sample products. It’ll use WP CLI and it’ll throw in a bunch of sample products for me. Sample content, sample orders. There’s a lot that you can do once you kind of spend the time getting it set up. And then you still have to come in as the human at the end and you really do have to still test everything yourself. You still have to have the good ideas. You have to know how the code works to make sure it’s not doing anything that’s too risky. It’s definitely transformational, but there’s still a human need to all this stuff. There’s still a need for your own expertise.

Katie Key:
Yeah, definitely. Particularly anything visual, like you say it will go in and click all the buttons it can’t literally see. And that makes, makes a big difference. So if you’re asking it to say code a design that you’ve created, it’s not going to get the attention to details. So you really do have to check everything.

Brian Coords:
Yeah, that’s why I’m a huge fan of blocks and block themes. I know that they’re not the easiest to work with sometimes and there’s definitely gaps around blocks and block themes. But like, what’s nice is if we’re all using the same design system for the front end of WordPress and if we’re all using the same components for the backend that it takes away, like the agent, like the agent will love to like add its own custom CSS and add its own things, but if you kind of guide it and say like, no, just use the blocks that are provided, the colors and the settings and the spacing that’s provided by the theme, all that sort of stuff, then it’s, you’re going to get a lot closer, it’s going to look a lot more real. It’s not perfect, it’s still, it’s still like a hard thing to do. But it, it kind of makes it easier because once you have a good block theme, like I use Ollie a lot for Woo stores that I set up, it’s like, okay, you’re not in charge of the design, you’re just in charge of getting it there and the theme will handle the design and don’t go free rein writing random code for the front end of my site.

James Kemp:
Yeah, I think that’s one of the biggest shifts is like traditionally, maybe five plus years ago you would, building a WordPress site would be like a lot of custom code, whereas now you can achieve the same thing by just piecing together blocks and patterns and things like that. Especially with the Ollie theme, which is, you know, very well defined theme with tons of blocks and patterns that you can use. So yeah, I think that that’s really nice. Actually. I haven’t found, I mean, I don’t tend to build sites all that often anymore, but I haven’t found a nice workflow for getting the AI to actually build. Build a site using blocks. Does anything like that exist?

Brian Coords:
Yeah, there’s a few things. This is where MCP comes in a lot. So we haven’t talked about MCP, but MCP is another way where you can interact with a WordPress site. It’s probably not as powerful as just doing things through WP CLI and that sort of stuff. But especially if you have a site like Live or like on a server, MSP is kind of nice because it gives you a nice, safe connection to it. And so there’s a lot of good MCPs out there. WooCommerce has one that lets you interact with your products, interact with your orders. It’s mostly read only, it’s mostly like pulling information so you can have AI analyze it. But it’s pretty useful. Ollie has some MCP tools that it’ll search for the proper pattern. You can tell it, all, right, I need a product layout that looks like this and it’ll kind of search its own patterns and it’ll inject it into the page for you. WordPress.com also has an MCP that’s very useful and it can fetch patterns, templates and do updates to them at a very like, granular level. So all of those things, I think they’re all still being shaped. I think. I don’t even know if MCP is the way the whole industry will go in six months. But we are seeing, exposing all that stuff. And that’s also Another benefit of WordPress is it’s so extensible that anybody can interact with it because whether you want to use the CLI or STPI or whatever, AI agents, they just know how to use those things. They’re really good at it. They’re really good at using those sort of common open protocol type tools and they’re good at mcp. So, yeah, some of those tools exist, but I think design is always like, even more than other code, I think design is always going to require just a little bit of human attention, like you really do. Just like, you have to have a good, strong design opinion about it. And that’s why I use Ollie mostly because I don’t have good design taste. So I like offloading that to Mike and letting him handle the design and I just use his patterns.

Katie Key:
Is AI good at interacting with Ollie?

Brian Coords:
Yeah, he, he added some MCP tools that help. You know, I think the, it’s really just a block editor thing. The way that the block editor stores everything, it’s like HTML with these weird JSON comments inside. That’s the part that it struggles with. I’ve seen some of our coworkers at Automattic are building some skills that kind of help it validate that code and write that code more specifically, because I think that’s the one area where AI is not trained on it as much. That’s why I do think the way that Ollie works and the way that WordPress.com works and stuff, which is design all the patterns in WordPress make the layouts that you want have this nice pattern library that matches your brand, matches your design and stuff. And then it’s not generating code on the fly, it’s pulling the proper pattern and putting it in, in the right spot. And you already know that it’s designed to, you know, match your brand guidelines, match, like the tone of your site, that sort of thing. And I think that’s a really good approach. I think a lot of the vibe coding approach is make everything from scratch, just start fresh, make everything from scratch and it all kind of starts to look the same. It’s like a black background with like a purple gradient and like big white text and like you can tell those vibe coded sites and it’s fine, they all look the same and stuff. But I think WordPress is really good for like, no, I have a design system, I have a brand, I have designers building the patterns. We actually do this@WooCommerce.com, we have patterns for how we want our landing pages to look. Our designers build them, they’re very specific. And then we use like a skill or something to pull in those patterns and just populate the content and stuff. But we’re not getting rid of the designer. Like, we, we want the designer to give us the, the template first and like, have a strong opinion about what we want to look like.

James Kemp:
Yeah, I like that. That makes sense. I think one of the, this is kind of shifting onto the, the merchant mindset is when they first spin up a store, assuming they’re doing it themselves, it can be, they don’t necessarily know like, what should be on a home page or, you know, what, what pages they even need. And I think they probably wouldn’t have the understanding to create these patterns ahead of time. So I think it’ll be interesting to see the AI shift a bit to recommend them to do that first and potentially recommend that this is what you could have on the homepage and it’ll be nice to see. Okay, the AI is capable enough to go and create these patterns for you and then you can go in and like tweak them and modify them. I don’t know if there, if any of these MCPs allow Claude or Codex to create patterns. Unless it’s like WordPress is one. WordPress.com does create patterns and layouts. Right. But it’s, it’s kind of done for you. Like you’re not asking it to do it.

Brian Coords:
Yeah, there’s there. WordPress itself has an MCP. And if you load like if no matter where you’re hosted, if you open up that MCP connection, it’ll just depend on what’s installed. So if you have WooCommerce installed, a bunch of skills or like abilities will show up. If you have some of our extensions, you’ll see stuff for that. Ollie loads through that. I’ve seen like Yoast and other SEO plugins, they load through that and you can kind of see all of that. But if you’re on like WordPress.com and Jetpack, we have our own version where I think they’re sort of battle testing things before it makes it to Core and they’re kind of doing it more in a controlled environment because like I said, it’s so experimental. They’ve changed the way MCP works so many times. Everybody’s kind of trying to figure out what’s the best way. Do I want to have a hundred different tools? Do I want to have just a couple of tools that call other tools and stuff? But on the dot com one, it is pretty good at like every piece of WordPress, patterns, templates, template parts, your header, all that sort of stuff. But I do agree with you that like your average merchant, they don’t, I don’t know, I don’t think they want to reinvent design and like, you know, they just want something that works, they want something that converts. You can get really crazy and weird and all that sort of stuff. But with WooCommerce specifically, it’s like, no, I actually want people to buy stuff from my store. And that means I need a button that’s very clear to click and I need a cart that works the way that every other cart works because I don’t want to add weirdness, I don’t want to add friction. I want to make sure that people can buy things really well. And they do want to just load up a store with like, what are the best practices for me to, you know, be successful. And so I know that we’re working on internally a block theme that has a lot of patterns and has a lot of this stuff. I’ve seen some work, I’ve seen that that repo’s been getting a lot of activity recently. So I think that’s going to be coming pretty soon. I’m not sure when, but I think it’s going to solve that same goal of like, no, we just, we want to give you the tools to do your job. Because I don’t think every merchant wants to sit in there and be a designer. They want to build whatever product they’re building and they want to sell it. And, you know, that’s their goal.

James Kemp:
Yeah, I agree. I think you’re referring to the purple theme, I assume. Yeah. The plan is still to release that in its current state, so I think that’ll be useful. I think it introduces expectations of how an E Commerce Store, like the default theme of an E Commerce Store, should look. And I. I do think it’s time we move on from the storefront theme.

Brian Coords:
Yeah,

James Kemp:
let’s talk about testing and actually shipping code and keeping up with changes and things like that. What are some of the best practices around that? So let’s say someone’s built something that modifies the checkout, for example, like how would they go about testing that and testing payments and that the checkout process is working as they would expect it to?

Brian Coords:
Yeah, I mean, your E Commerce Store is. If it’s that important to your business, you should be taking it very seriously. Like, if, you know, if you have a lot of money flowing through an E Commerce Store, you should really have a good strategy for this. The first thing is, like, we really do recommend doing updates on a staging environment first. I think updating WooCommerce itself is generally pretty safe, but when it gets tough is extensions. I mean, we. We run all of our updates through our own. It’s called git. It’s like an automated testing suite. And what it does is it loads. If you build an extension in the marketplace before you can release a version, this exhaustive test runs and it checks everything. Do all the payment flows work? Do all the checkout flows work? Does the load time stay the same? Did you not slow anything down? Did you. Did you not slow down a conversion like a checkout moment? Does the admin load do any screens? Fatal. And it does that against WordPress and WooCommerce at a bunch of different versions. We’re also introducing a bunch of other extensions into it. So it’s testing against. All right, does it work if your plugin plus this other plugin plus this other theme is all installed at the same time, so it runs through all of this sort of automated testing. That said, I still think if you’re a merchant, you probably should have a staging version of your site where you just run the updates first, make sure nothing breaks, and then do it. And you can automate a lot of this stuff. AI helps you automate a lot of this stuff. But you really do need to check that the cart and checkout is still working, Any forms you have are still working. Any other call to actions are working. And so I would say staging first, then you can push update. And otherwise I would say that WordPress has this concept that updates break things. But I think if you look at the scale of WordPress and WooCommerce and how many sites there are, and I know I have probably a dozen sites that have auto updates on nothing happens. I’m not, you know, I think it’s actually pretty safe to continue updating things. But yeah, you should have a staging version that’s connected to a fake payment, like a test payment gateway and you should probably have somebody checking those things and you can automate that as well.

James Kemp:
Yeah, I think one of the complications that we have as a platform being WordPress and WooCommerce and anything built on top of that, it’s just the sort of exponential combination of hosting environment, PHP versions, plugins, combinations of plugins and custom code and data sources and all that kind of stuff that it’s very hard to test every possible scenario. And I think it kind of comes back to what we were talking about near the beginning with the tester plugin that we have and just kind of getting ahead of updates that are coming and testing. Before we do updates to WooCommerce Core, we have two release candidates that go out in the two weeks prior. And I think testing that stuff is very important and like helping us to catch those things early.

Brian Coords:
So I think one thing that a lot of people don’t know is that at Automattic, if you host with us on like WordPress.com or Pressable, you can opt into us managing WooCommerce. And so every WooCommerce release, one of the things that we do is we actually, before a release comes out, we start updating, auto updating sites that have opted in like small groups. And then we check it and so we like when WooCommerce 10.9 came out, we updated some subset of people onto WooCommerce 10.9. Before the actual release came out, we watched all the servers and logs and we tested everything and we actually found an issue where if you had like a really old version of the stripe payment gateway, like if you had like a version from last year and you just hadn’t been updating it for some reason, it would trigger some errors in some situations. So then we paused the release because we just don’t want people’s, you know, sites to go down. And we found out how a way to fix that because you Know, we can’t force those people to update. We know that people on other hosts might have it. So we fix that issue and we deploy it. So we don’t have a good representation. Like James said, like, there’s a million combinations of plugins and things you might be running and custom code. And we. It’s just physically impossible to account for all of that. But we do actually test each release ahead of time and just on real sites to see, okay, and then we immediately can just roll it back, move on, and actually fix the release before it goes to the wider audience. So it’s pretty cool to see that process happening. I think there’s actually a release going out today that I need to take a look at. But like, there. It’s really cool to see that kind of automated testing, but people should also be probably testing on staging sites for, you know, if their business depends on, you know, a lot of money coming through their store.

James Kemp:
Yeah, for sure. And I think in terms of like, if you’re creating custom code for a site or, you know, you’ve built a custom plugin that does something or custom blocks all of that kind of stuff, Git, of course, is. Is the go to mechanism for like versioning that code and being able to come back to that and remove something that maybe caused an issue or branch off of it and create a new feature. I assume git’s a pretty heavy part of your. Your workflows.

Brian Coords:
There’s some hosts that work better than others with git, I would say that I definitely am a huge git person. I like the ability to roll back. I like a good host that makes daily backups so I can roll back. I like Jetpack because it does backups at like, almost every single thing that happens on your site you can roll back to. So like somebody updates a post, you can just roll back. It’s super granular. But I think this is a good argument for why people should not Vibe code everything and stick to trusted extensions. Because I think what’s really nice about that is, like, I don’t want to have the work of like, checking that my code is going to work on every version. I’d rather pay whatever, $29 a year for some plugin and let them deal with it. And then if I don’t have to fix it myself, it’s their job to test it and fix it. I think there’s some things. I love Vibe coding and stuff, but once I get to something more serious, like subscriptions or stuff like that, anything with payments Anything that touches any of that, I would rather just honestly pay for a plugin at that point.

James Kemp:
Yeah, I think that’s an interesting point because you see a lot of discussions of people, I think I’ve mentioned this before, like trying to replace SaaS software that, you know, has solved a need for them for however many years. And they’re, they’re vibe coding their own solutions to replace it, which can be viable. But I think a lot of the time you don’t, you’re not necessarily paying for the solution as it is. I mean, that’s a part of it. But, you know, now that we can replicate that quite easily, you’re paying for like the ongoing innovation and just you as a, as a developer or person not having to worry about how it all works or like something’s changed and now you need to go and fix this whole system that you’ve built and, you know, you’re spending your time doing that instead of just paying the equivalent or less in a software subscription. So I think that’s a good point. Very cool. I think this has been quite a varied conversation. There’s tons of stuff that we can talk about in terms of developing on top of WooCommerce and WordPress in general. If anyone wanted to reach out to you, Brian, and ask any further questions or reach out to our engineers, what would be the best places to do that?

Brian Coords:
Yeah, so, I mean, I think Woo is pretty accessible. As an organization, we’ve gotten a lot of feedback recently that we’ve gotten more open, more accessible. I think there’s been a huge push internally for people to build in public. The code is obviously open, so if you have an issue, go file an issue on GitHub, go look at a PR. You can do all that sort of stuff. The places where we put the most Information is number one on the developer blog, which is developer woo.com if you go there, we post, you know, calls for testing, we post what we’re working on, the roadmap. Every release we do a post about. So that’s a good place. We have a newsletter there that I recommend we just send once a month, you know, like some like, new information, what events are happening, that sort of stuff. We also have meetups on there. So there’s a ton of local meetups for WooCommerce and WordPress. So I definitely recommend if you live somewhere where people do local meetups. Unfortunately, in the US we don’t do local meetups and wordcamps very much. But if you do, like live somewhere where that’s happening. I definitely recommend that I’ll be at WordCamp us and then we have our Community Slack, which I also recommend joining. All this is linked on that developer Woo.com the community Slack is a really good place to ask questions to see what people are working on. If you ask a question about a feature, most likely I will tag the engineer who worked on that feature to come and answer your questions. And so you see a lot of conversation happening in there and then. Yeah, follow us on X and YouTube and all the general places where you follow people.

Katie Key:
So our next episode is going to be about the Woo Marketplace. We’re going to be talking about should you sell your plugins on The Woo Marketplace? 7th of August, 3pm, put it in your calendar. Should be an interesting one because we’re gonna have Ian Meisner from Kestrel. They sell most or all of their plugins on the marketplace. Me who does not use the marketplace. And we’re going to have a representative from the Woo Marketplace as well. So it should be an interesting one.

James Kemp:
Yeah. And that’s 3pm UK time, right? BST.

Katie Key:
Good point. Yes. So that is 4pm Central European and I think other times may vary, 10am Eastern time and it’s like 7am Pacific time, so don’t bother.

James Kemp:
Yeah, that’ll be a really interesting conversation. Thank you very much, Brian, for joining us. For anyone watching, if you want to subscribe, as we said at the Beginning, we’re on YouTube at Do the Woo podcast, we’re on X at do the Woo and you can visit our website at DoTheWoo.com. Com.