Building WooCommerce in Public

James:
Hey, it’s James Kemp from WooCommerce and I’m joined with Darren Ethier from WooCommerce as well. Darren, do you want to tell us a little bit about what you do at WooCommerce?

Darren:
Sure, yeah, I’m happy to be here. Pretty excited to be invited and joining James on this. I was talking with books, so I’m one of the engineering directors for Woo and for the longest time at Woo, I’ve been working on the intersection of Gutenberg and WooCommerce and all the changes that have been happening there, so helping promote that and work towards Woo’s future in that context. That’s kind of the overall story for me.

James:
Yeah, I think one of the things since I’ve joined Wu is if I have any kind of engineering question, Darren is the person that I’ll reach out to and he seems to know where to direct me, who to talk to or that kind of stuff. Cool. So yeah, that’s been really great and we had a session in WordCamp Europe of this year where we got together a group of agencies, WooCommerce developers and that kind of stuff, including Bob, and we had pizza, a bit of a pizza party and just a chance to sit down with some Woo friends and have some pizza.
It was really nice and it was your idea actually, you brought it to me and we made it happen. That was very interesting to put together. How did you feel about the kind of conversations we were able to have?

Darren:
It’s really great. I think one of the things, obviously one of the values of WordCamps is connecting with people in the community of working on WordPress and especially for Woo, just having an opportunity to connect with people who use Woo and hear their perspective on what’s going well, what’s not going well, and just learning about the types of things they’re hearing from their users and seeing where it lines up with what we’re hearing and the research we’re doing as well. And just building relationships is often really cool because when you connect on Twitter or you connect in other contexts, if you’ve had that in person kind of gathering over food is always good. It just makes things go a little bit easier. You get to know each other’s personalities and stuff like that. And it also is really fitting too with over the past two, three years, I think in particular we’ve kind of had this internal mantra that we’ve been drip, drip, drip over time is default to public with everything we do and communicating and engaging with the community and just really doing even more of our development in public so that we’re getting more visibility into the kinds of things we’re wrestling with, which especially for any of the newer stuff that’s happening with WordPress, I think is really valuable.

Both because we see what people are struggling with in the community, but also give the community insight into some of the problem space we’re struggling with and how we’re going about tackling that, which in the end helps us make a better product. I believe. So we’ve definitely stepped that up in the past few years.

James:
Yeah, I completely agree. One of the things that I have always done even prior to being with WooCommerce is be quite public about what I’m working on and just connect with people and talk to people. I can’t remember when you published it, but one of the first P2 posts that I saw on P2 is our internal version of WordPress was a post from you talking about how we should be more public and we should talk more with the community and just talk about what we’re working on, get feedback before it’s kind of too late before we roll these things out into WooCommerce itself. And I think that’s really valuable. It’s still something that we are figuring out the best avenues to do that, and I think the meal we had in Europe was a good example of how we could execute on that plan. But also something I do a lot is I use Twitter or X quite frequently to connect with primarily agencies and developers, plugin developers, and also developers building WordPress and WooCommerce websites. We also have the developers blog where we’ve started. One of the things that Brent from developer advocacy has done is enable I guess anyone to publish posts on the developer blog, but primarily the product managers have a lot of flexibility to publish on there and get feedback, so you should start to see some posts coming through on the, and I think they’re assigned to the roadmap category. Our roadmap on there is more like it’s less fixed dates and more like these are things that we’re working on,
Which is quite an interesting approach.

Darren:
I mean you’ve hit on some, there’s different levels of how this happens. I mean, there’s the one to many where we’re kind of broadcasting what we’re doing and how we engage and sometimes we’re just experimenting with a bunch of different things to learn what works best. And I guess from my perspective, what I really like too is when it’s not just one way us to the community, but it’s also a community to us. We can provide more avenues for that type of communication happen, whether it be on the Twitter and just listening to what’s being said around there or Bluesky, which latest hotspot now or our GitHub discussions is open as well. Anybody can start a discussion. Maybe it’s not a specific bug that you’re dealing with or feature that you want, but just describing something you’re trying to accomplish in WooCommerce that you can’t and some of the roadblocks you’re hitting.

We had a recent discussion that opened up about our use of a compatibility layer and the code base to help bridge between some of the older way of extending row and in some of the newer stuff we’re building across blocks and templates, and that’s kicked off a really good discussion about our philosophy and our approach to how we’re rolling out these changes and what we’re headed towards. That may surface in a blog post at some point, but it got kickstarted by somebody in the beauty that was really saying, Hey, this isn’t working for us and it would be great if you could extend this more broadly and even internally it’s kicked off different views of what we should do here, but that’s the kind of thing that I think is so valuable that comes out of this kind of devote to public mindset because we wouldn’t encounter that if we didn’t do that. And it also really fits in with that whole open source ethos as well. We really believe in the importance and the value of WooCommerce being open and it goes beyond just the software. It’s about how we do our work as well.

James:
Yeah, it’s an interesting one to tackle. I mean, I think you’ve touched on it before. There’s so much changing now in the way that WordPress does things. I’ve worked with WooCommerce for 11 or 12 years from the beginning, and it was very much like PHP focused and jQuery was the thing to use, and whereas now it’s a completely different landscape with blocks and all that kind of stuff. Where do we stand with extending blocks in a way that was similar to how we used to be able to do with PHP? Because I know that’s something that I see come up quite a lot and it’s also, I would say one of the reasons that WooCommerce is so successful is that we as builders have been able to expand what WooCommerce can do. So I think there’s definitely some concern there that expanding the block, the react interfaces is a lot trickier than it has been with PHP.

Darren:
Yeah, and I think that extending WooCommerce at the end of the day should be about extending WordPress, and that’s an important thing to keep in mind because WooCommerce is a plugin built on copper wood press. So in many ways this influences not only the experience that users have, the end users have when they work through, they’re working on the admin or on the front end. Their experience with WooCommerce will be the same as their experience with WordPress will be the joint experience with WooCommerce, but it’s also influences how we build on top of WordPress. If WordPress is changing some of the philosophies and approaches to how things are built, that naturally is going to trickle down to how Woo addresses that. And so I think what will remain true no matter what is that flexibility is a primary pillar and strength of what we have, and that applies both at the code level and what we’re seeing even more so now is at the no code level, the flexibility, what the end user is able to do without code, and that impacts how we build things rather than strictly thinking about flexibility at the code level and how people can extend and use that for anything they need to make, which I think will always remain to a degree how it happens definitely is changing, but we also have to think about when we’re building our products, how does that work for the user at the no code level and are there things that they should be able to do or should that be something that should be controlled by whoever’s extending it to add their own product features?

Maybe they don’t want the user to be able to do that, or maybe agencies want to lock down certain parts of it. So I mean, I’m not getting too deep into the specific technical stuff, but I think at a higher level, thinking about the fact that WooCommerce is built on WordPress and a lot of what we do is influenced and shaped by that. A good example is even just talking about blocks for example, and how pages are built, how templates are built, there’s a whole change in the paradigm there between the PHP templates that have both the business logic and the display logic all encapsulated in that PHP file and you can basically go in and modify that and have it do whatever you need or be really complex and take care of a whole bunch of conditional stuff that happens right in that template.
Whereas in the black paradigm, all that business logic becomes more encapsulated by the actual blocks themselves and the templates themselves are more concerned with the layout and the presentation. So there’s been a little bit of a separation concerns there. So that’s a bit of a shift in mindset and I definitely see that the flexibility is still there, but it’s more curated. There’s more clear pathways to how you extend things, which in the end should the goal is to make it easier for the developer or the builder working on top of that because they’re not having to try to figure out among the a hundred or 200 different ways of how to do something, it maybe 20 or 30 different ways instead, which not only allows them to continue to have the flexibility for what they need to build, but also build it in a way that is consistent with the user experience across WordPress and across Woo.

And I think that’s what we’re heading more towards as we continue to see this take shape across WordPress and then across Woo. And there’s still a lot of stumbling we’re doing along the way. Either we used to be able to do this and we can’t do that now. That’s a gap, obviously, or the whole thing around the bill processes being so complex and difficult right now, that’s a pain point that shouldn’t be there for the developers building on top of our staff, so let’s think about how would we improve that or maybe reversing some of the decisions we’ve made there. In some cases,

James:
One of the big of 2025 I guess is build a tools and how we can improve what we have already and how we can add to the stack of builder tools that we have available. So I think that’ll be a really interesting exploration to take.

Because right now when a builder spins up a WooCommerce site, they have the same experience as a merchant essentially. They get the onboarding, they have to either dismiss it or go through it in the same way that a merchant would. And we should really lean into the fact that we know there’s a lot of WooCommerce websites are built by builders or agencies, and that should entail a different experience. Whether that’s like I’ve touched on the idea of configuration files that they can utilize to initially configure WooCommerce or have a base that they always work from in some way. I dunno what that would look like in reality, but that’s the kind of thing that we want to explore a bit more

Darren:
And it’s very much connected to this whole public thing. We want folks who are building lots of WooCommerce sites who have developed their workflows for streamlining how they build for their clients, how they do handoffs. If there’s things related to setting up payment extensions for example. Oftentimes there’s a lot of overlap between what a merchant or the end user on the store is building versus the builder who’s building for them and then handing off to them. And there’s these weird overlaps that make it hard to determine when to do that hand off. And it goes even all the way back to even licensing when it relates to the builder buying these plugins or these extensions for their bills. How do they manage that in an effective way where they don’t have to renew? I mean, it covers a whole wide range of different things that we want to hear from builders, how they’re doing things right now, what’s working well for them, what are some of the tools they’ve made themselves that have worked really well because we might spot some patterns that we can bring into core that don’t necessarily replace everything that people are doing but enhance what they’re doing.

Maybe help them remove some of those steps that they have to have in their own tool tooling. And I think that’s important too. As we do this stuff, we want to make sure that what we ship in Core gives a great default experience out of the box. It is just awesome for the needs of most stores while recognizing there’s still going to be that last mile of customization or flexibility. That is one of the strengths of Woo, we hear over and over again that people stick with Woo despite some of its gaps and deficiencies because they can do whatever they want and we have to be careful that we don’t lose that. I think as we work towards this future of more curated extensibility, more consistent user experience, there’s still always going to be that last smile of really personalizing and customizing the experience for the stores that are being built for.

James:
Yeah, like you say, that’s the beauty of WooCommerce is that you can essentially make it do whatever you want it to do. It does lead quite nicely into an effort that I’ve been talking about a lot recently, which is the more core, the effort, sorry, my camera froze again. Yeah, it’s okay. More core. This is an initiative that we’re undertaking and the goal of it is to ensure that the core of WooCommerce, the base plugin that you install has all of the essential basic features that a merchant might be looking for. So part of that strategy is to potentially roll in a lot of our premium extensions, and this is our own branded premium extensions that we have in the marketplace currently, and we’ve seen that already in progress with brands, which was rolled in recently. I think it’s not officially available to everyone, but I think that’s coming in at the end of this month or I think so, yeah,
Pretty soon.

So it exists, but it’s not necessarily just there by default and brands is a massive one. You touched on my puzzle site that I was working on. Brands is something that I just used straight away. I need to put a brand on those different puzzles and it makes sense to have that kind of feature in core. Some of the other ones we’re looking at are back in stock notifications where it is kind of an essential feature. If your customer is interested in a product, then they should be able to know when it’s back in stock. It’s very basic functionality. It’s not doing anything too exceptional in terms of functionality or feature set. It’s literally just sending an email when a product is back in stock. And that’s the kind of stuff that we should be looking at for core. There’s other products that I think need some assessment and that’s something that I’m going to be doing with some members of the team and also just community feedback and all that kind of stuff to see which of these features do you want in core, which should be in core. There’s discussion around product add-ons and gift cards. Some of that stuff I’m not entirely convinced should be in core as they are anyway, maybe a basic form of it, but in my mind, coupons are kind of a basic form of gift cards.
So yeah, there’s a lot of exploration that needs to happen there

Darren:
Too. It’s an interesting tension there, and I know we’ve already seen this happen as we’ve been talking more about more and core, there’s a tension between what do most stores need out of the box that there’s friction right now for them getting configured and set up because it’s not included with Woo. It’s something that they have to research among the myriad of different solutions that are out there to figure out which one is the best one for them versus this mindset of core being really lean.

And leaving it up to people don’t want the added bloat of having things that they’ll never use or even goes back to some of the things Tension that was around Jetpack happened over the years with Jetpack being having everything in there. And I think what we’ve heard over and over again as we’ve been looking at stores and what they typically need to get off the ground, what we’re seeing in the competitor market for what is attracting people to our competitors, and frankly, there are gaps in people starting Woo. And one of the biggest frustrations is I need to go and research all these additional things after I install Woo to get the functionality that my store needs.

James:
We hear that a lot that one of the biggest issues that merchants have, and one of the main reasons they leave WooCommerce is because they have to deal with this plethora of plugins just for basic functionality. And I think plugins are absolutely fine if they’re adding expanded functionality and we’re not trying to get rid of that market at all. We want the basics to be available out of the box without this need. And then if there’s specific needs or enhanced versions of the basics that they require, then they can go and find these plugins and these extensions that handle that stuff

Darren:
And that leads one of the strengths of Woo being its flexibility can also be one of its weaknesses

James:
And WordPress in general

Darren:
And WordPress in general, right? Because the risk does exist that the user experience is fractured when you have different extensions adding functionality or different ways of adding the same functionality and the whole additional load of having to keep those things updated an update breaking that functionality because that extension or plug and developer just happens to not follow the changes and all that stuff. So I think there’s this recognition where we try to balance this tension of what goes in core versus what remains out is reducing some of that overhead of those key kind of table stakes in important things for stores that they shouldn’t have to think about how it works together with all the other feature set in their stores, how the user experience flows between the different contexts in which they’re working with that feature and even the nitty gritty of keeping things updated, like having to update those different plugins.

And so I think there’s room even with the flexibility of Woo, to be more opinionated in how the commerce experience is out of the box for the majority of stores to remove some of that decision Incs that stores have to go through when they’re first setting up their stores or they’re maintaining their stores over the long haul. And even for builders, I think that can alleviate some of the friction they experienced when they have merchants coming and saying, I need X, Y, Z functionality and I wanted to do this and this. And then builders have to think about even just the base framework for whatever that future set is before they even get into what their user needs are for the store they’re building. But if we’re able to take care of that base feature set that most stores have, that just removes a whole set of problems from the whole experience. And then yeah, builders can extend on top of that for their niche or custom bespoke needs that the score may have, but in a way that reduces the transfer complex with other plugins down the road the merchant may add because it adds additional functionality. So I think it, it’s just managing that tension wealth and balancing that wealth, and again, going back to why we hear from the community and we reach out to find out what people are already doing in this space and where can we adopt the best solution for that.

James:
I think there’s a lot of considerations to make, and I think one of the things that I’ve heard from the community as well is they want to know what the criteria is for things that we put into core. These are things that you shouldn’t touch as a plugin developer because we’ll probably want to put them in core and that’s something that we plan to document. I think it’d be useful to put that out there, what that criteria might look like. Really it’s like you were saying, it’s the majority use case. So the majority of users require this functionality and we don’t have it. It’s competitor analysis. The competitors have these features, they’re well received. It’s community feedback like the community developer community or merchant community beliefs that this stuff should be in core. So there’s a whole bunch of data points that are going to determine what features should be in core. And then also just a bit of product decision and common sense, I guess.

Darren:
And I think at the end of the day, what drives a lot of the things we’re thinking about for a product and Woo is a user experience across our product. I mean, we want to make sure that from setting up a store to maintaining a store on the day-to-day work and all the stuff that different, the other angle is the different contexts of people who work in a store. I mean, you have people who might be designing a store versus people who are just doing the day-to-day management, but all across all those contexts that there’s a really great user experience. And I think we can do a lot better in that area and be more opinionated in some ways. And I think that will inform kind of where we draw a line on what’s in core versus what can be extended because we have more control over that overall user experience. And it’s kind of set the guardrails for the flexibility within that user experience. You could still do incredible great stuff, unique stuff, but for the end user, it still feels like it’s part of the whole a better weight from there, but we’re getting there.

James:
Yeah. Yeah. I mean that’s the 2025 goal. Is this more part of the 2025 goal is more on core? Yeah, I put some messaging out yesterday regarding the name More in Core because I had some feedback that it could imply bloat, and we mentioned, we touched on this earlier as well.

And I think I see the value in that feedback because really we’re not just adding more to core for the sake of it. We’re adding essential features into core that aren’t currently there, whether that’s from our premium plugins or just features that don’t exist already in our product collection, then that’s the kind of stuff that we’re looking at. And that might also involve a working on what’s there already, what we already have in core maybe we don’t need. So it could involve some stripping back. So yeah, more in core is a nice phrase because it rhymes. It’s quite tricky, but it doesn’t truly encapsulate everything that is going into it, and I think that’s where our messaging on that effort is going to come into play. So yeah, I would keep an eye on the developer blog for that kind of stuff. I’ll probably put a post up, I would imagine January time hopefully kind of saying this is the strategy and these are the features or products that are next up on the list to add to core. And I imagine that strategy is going to evolve over

Speaker 4:
Time.

James:
Definitely. But yeah, I think the key thing is we want feedback on this kind of stuff

Darren:
That’s exactly, it dovetails with what we’ve been talking about defaulting to public. We’re communicating even at the early stages of a lot of this stuff because we recognize that’s where we can sometimes get the best feedback. There’s more freedom and flexibility for us to revisit some of the assumptions we’ve made as we’ve started thinking about this. The assumption of moron core, everybody would get what we mean by that. But no, clearly we’re getting the wrong impressions out there, so we have to revisit even what we call this thing. I think. I mean in

James:
Saying that though, a lot of the feedback was that Morin core is the perfect name. Yeah,

Darren:
I mean you get a mix.

James:
Yeah, exactly. Yeah, I think it is a good name. It is catchy. I just think, like I say, the messaging behind it needs just putting out there, having a location of this is where you can go to read more about this initiative.

Darren:
Something else that’s been really on my mind is our connection. I mean, I touched on this a little bit earlier, a connection to WordPress and how that impacts how we build and what we build and the user experience. Because one of the things we’re finding, we’ve really realized even in the past couple of years, we’ve always known this and I think everybody in the WooCommerce community knows this, that with we being a WordPress plugin, it can inherit a lot of the experience that WordPress offers. But I think what we’re realizing more is that we need to treat WordPress as much a part of our product as WooCommerce. In other words, it’s not something else that we worry about what WordPress is doing and then they’re doing that kind of thing. It’s more that no, when we have to evaluate any improvements we make, is this something that we need to fix in WordPress or contribute to in WordPress to improve versus trying to work around that in how we best thing.

There’s been this mindset in some context where WordPress isn’t commerce friendly, the UX isn’t friendly, the information architecture isn’t friendly for somebody who just wants to build a store and work from that kind of mindset. And so we need to build a more commerce friendly element in WooCommerce and fix it that way. Whereas I think actually it’s the opposite, especially with WordPress being in the transition is right now thinking, rethinking through how the admin works and how people interact with moving through to different contexts or this whole mindset that Matt is promoted of WordPress being the operating system of the web. We really had the opportunity to influence what’s happening in the WordPress space. So not only does it give us more flexibility for how the user interacts with WooCommerce in the context where they’re thinking primarily about their store functions and features, but also for every other plugin in the WordPress space because it’s interesting that a lot of our merchants don’t only just install WooCommerce extensions, they specific the commerce, but also will install plugins to help them just for their site in general, like SEO or some of the other things that they might do on their content side of things. So I think it’s really us shifting this mindset to WordPress, this is about ship product as WooCommerce and make sure we’re investing in contributing upstream where necessary to improve that product service area.

James:
And that’s come into effect with the product editor work that we were doing, right?

Darren:
Yeah,

James:
That project got pretty far and then essentially got

Darren:
Paused. Yeah, well, we realized that we were doing the right thing in connecting this to how users are managing their products and recognizing that the default classic interface that people have used for so long, which many people have developed their own workflows around, they’ve accommodated it to fit their needs, but finding out what those workflows are and how can we improve that with the default experience and then trying to incorporate some of the APIs that we knew WordPress was exposing at that level. It was very creative, it was very groundbreaking in some cases, but we found we were getting ahead of WordPress and too far ahead and some of the gaps that we were trying to address in a product editor are really gaps that need to be addressed upstream. And so putting the product editor work on pause and intentionally working upstream on some of those gaps, like what’s happening with the data views and data forms projects in WordPress will not only help the work that we want to eventually do with the product editor, but also across the WooCommerce admin with things like settings and even some of the different views that we’re doing with email or analytics, all those sorts of things.

So again, going back to the user experience being across the whole product editor experience, I mean across the whole admin experience, whether it be fixing something in the configuration of their store and the settings or whether it be managing a product and then switching to, I want to customize how this product looks to shoppers on the front end and their experience just more holistically thinking about where’s the APIs that need to be addressed here? What is the user views that need to be addressed that we can then replicate across our product service area? And right now, for many of those that’s upstream work and for builders, that should result in a better experience as well because instead of having to learn the WooCommerce specific way of extending things, they’re really learning the WordPress way of extending things in this new paradigm and can apply that to what they build on top of WooCommerce as well without having to learn a bunch of new things. So it’s kind of the mindset behind that shift.

James:
What do you think the timeline is on that product editor?

Darren:
It’s tricky because

James:
Is the plan to pick up where we left off or is the plan to revisit?

Darren:
So the plan is to, I imagine a lot of the UI elements will remain similar and maybe the tech stack underneath that changes. But even with what we’re doing upstream, we’re going to be prototyping some of that work into what we’ve done with the product editors so far. And we also want to make sure we come up with some sort of, if possible migration plan for those who have already built on top of the beta version of the product editor nd make sure we’re also satisfying some of their needs that we already saw surface, especially from developers who were trying to extend the beta product editor that we put out. We know there’s some pain points that already came up and we’re hopeful that we can address a lot of that with the new stuff. So I mean, right now we have two engineers working upstream in the WordPress project with data forms and data views and making sure that some of WooCommerce needs are addressed there. And keeping in mind that when you’re working directly in WordPress project, it’s not just for WooCommerce, it’s for everybody building on top of WordPress.

So feasibly, it’s introducing that flexibility in a way that we can adapt it for our needs to make sure it’s going to meet the needs of our stores and builders on top of Woo. But also keeping in mind also going to work for anybody building a plugin ecosystem, which is a win-win, right? Because at the end of the day, usual WooCommerce is of used to have WordPress, so it’s not like we’re doing anything that’s not going to help us in the long run, but it does take time and we have to count for rollouts of WordPress and when we press gets release. But that’s one of the things that we’re going to be coming back into in the new year as well. And that’s why we’re kind of vague on timelines in our posts because we have a rough plan and we’re working towards that plan, but it all depends on how easy or how hard it gets as we work on things.

James:
Yeah, it makes sense. One of the things related to that that was noticed the other day is in our documentation about blocks, we could improve that and be more explicit about which blocks are soft deprecated, which ones are deprecated and all that kind of stuff. I think that’d be very useful for developers, particularly

Darren:
Up in particular in the conversations around the product collection box, which we’ve released and we’re making sort of the canonical way to work with any sort of product collection across the shopper experience,

James:
Which I use on my puzzle site. And it’s really powerful what you can do with it

Darren:
And hopefully provides a good base for the flexibility that we talked about earlier where people want to add things. I mean, you even brought up something that you were trying to do customized in the block with our team and injecting a short quote or something like that just as a quick way to add the functionality that you want to add. That’s a good example of, I think where we can do better in our documentation is say, this is how you used to do it in the PHP template way. And you can often still do that stuff with PHP. It’s just learning the new way to accomplish the same thing, right?

James:
Yeah. I think that’s one of the biggest challenges is that a lot of WordPress developers came into it as PHP developers and not even PHP developers, but WordPress’ version of PHP development.

Darren:
Yes. That’s a good caveat there.

James:
It’s reasonably different Laravel, for example.

Darren:
Yeah, and I empathize with that. I mean, I grew up in WordPress. That’s how I gained my engineering chops seeing from back WordPress 1.5. So I’ve been through a lot of the changes in WordPress and still remember Matt’s talk, I forget where it was, but learned JavaScript deeply. And here I was just fiddling around with the LJ crew stuff and realizing, oh, this is pretty serious in the web development world right now, and it’s becoming the go-to way of creating rich interactive user experiences. So that’s kind of this evolution that we all have to go through. And I think on our part, the best thing we can do is help people along with the changes we’re having to accommodate. How can we bring our developer community along? Because I definitely understand that you may have these one person product shops who really struggle to find the time to invest in some of the newer technologies, and yet are still maintaining a really successful business around the product that they built and the customers that they’re serving.

So how can we help that one person shop who doesn’t have the time? And I think one, the important thing that we’re already doing is default to public communicating as much as we can about what we’re doing and the trends on the horizon and the kind of things we think might be worth investing in. But then also the education and the documentation part, and then the building tools, which we talked about already at the beginning of the call. Can we make it easier for people to do some of this stuff? I would love to get to a state where even we can automate some of the changes that might need to happen in a plugins code where it automatically shifts from one hook to another dynamic with ai. Wouldn’t that be awesome if somebody would say, here’s my plugin code, I need to do this, and it automatically transmutes all that code to the newer way and then they just have to fix it. I don’t know if we’ll ever get there. That’d be cool

James:
Days.

Darren:
Yeah, that’s

James:
My trading strategy. This is how I would do it. How would you do it now? It works surprisingly well, to be honest. But yeah, I think with the product collection block, a lot of the customizations that I might’ve done in the past with PHPI could do super easily with just the block editor, and that was really great to see. I had a nicer experience building with WooCommerce using a full site editor theme that my picture site was kind of a mix. Some of it was editable in the block editor and some of it wasn’t. So I guess that’s a block theme. So I was able to use blocks, but I wasn’t able to customize it as much as I have done with my puzzle site. But it’s been a really interesting experience to kind of come at it from both the builder’s perspective. And obviously that was my background anyway, was building client sites. But then also,

Darren:
That’s a really important point. The builder perspective, can encompass so many different types of builders. There’s the builder who worked primarily in code customizing in code and creating the bespoke stuff. And then there’s the builder who’s used to working with page builders and having the flexibility of the no code type of environments for creating what the client needs when installing plugins that might enhance the functionality that the client needs. And that’s kind of the mindset we’re bringing to what we’re doing as well. We don’t see the builder as one specific niche of person interacting with creating for a client. We have to think about that bit of a broad spectrum of builder. And you’ve experienced that between the two sets you built, right?

James:
Yeah,

Darren:
Exactly. Interesting.

James:
Yeah, it is interesting. I come into this building experience with coding knowledge, but I’ve tried to kind of build it without using code, which hasn’t been entirely possible. So there’s definitely some gaps there. And that was gaps for things that I to explicitly do, like certain layouts that I wanted or certain things that I wanted to display in the product list. But it’s valuable experience for anyone working on WooCommerce to do that and to see here’s something that we could improve. So yeah, I think we could probably wrap up. We’re coming up. Time

Darren:
Covered a lot of topics. It’s

James:
Touched on a lot of things. No, it’s been really interesting to cover all of this stuff as well as having that engineering input as well as product input is super useful. And I think a lot of people will find this an interesting chat and hopefully we can do some more of them.

Darren:
Definitely

James:
Always open. I love it.

Darren:
Cool you are on board too, James. I was so excited when I saw your name in our new Mattitians P2, and I thought, oh yeah, here’s a good guy. So it’s been great having a chance to work with you and really lean into your perspective and experience. Thank you. I appreciate that.

James:
Awesome. Well, until next time. Alrighty. See you later.

Darren:
See you all.