From Plugins to the Full Site Editor, Blocks to Performance, Staging to AI

Zach: Zach Stepek here with another Woo Dev Chat. And Carl, you’re with me as usual. How are you?

Carl: I’m great. How about you? I’m glad to not be in Japan anymore. I’m not living in the future, but also not in the cursed time zone, as I was saying.

Zach: Yeah, it’s nice to have you closer and back in a two-hour window of normal for me, so that’s always nice. But you had a good time in Japan?

Carl: Loved it. I’m going to go back, so definitely a positive experience for sure.

Zach: That’s awesome. And that all started with you going to WordCamp Asia, right?

Carl: Yeah, I spoke at WordCamp Asia.

Zach: Nice. Yeah, that’s a heck of a trip and a great reason to stay in Japan for six weeks. I like that. But hopefully, I will be at WordCamp US, I do have a ticket, so… I do have a ticket.

Carl: Yeah, I hope to see you there. I’ll be there for sure. I got a ticket.

Zach: Awesome. So, yeah, that’ll be a good time. Really looking forward to seeing the community there, and maybe we’ll even record a little bit of stuff for the podcast while we’re there. Do a DevChat roundup of all of the people who want to talk about nerdy things with us. And speaking of people who want to talk about nerdy things with us, occasionally we get emails from people who are interested in participating. And our guest today, Sean Conklin is one of those. Sean, how are you today?

Sean: Doing great. Thanks for having me on the show.

Zach: Yeah, it’s great to have you here. I see that your submission came through talking about you having developed over 100 WooCommerce websites. Now, that’s more WooCommerce websites than I’ve… That’s a very large number.

Sean: And it’s probably been more than that, but when I say develop, I mean either build or rebuild retheme or work on significantly. So, it all depends on how you want to count it, I’m just using a round number there.

Zach: Well, yeah, that’s a lot of WooCommerce sites. I’m sure you’ve seen a lot of things. Looks like you’ve been in the WordPress space since 2010 and you run codedcommerce.com.

Sean: Where I feature a bunch of code, if anybody wants some code snippets or some of my free plugins are on there. I mean, money-wise, I do billable work for clients, so building, supporting, maintaining, things like that. But I do have quite a bit of code on codedcommerce.com so that naturally fits.

Zach: I was looking at your blog earlier and I saw a maybe slightly controversial article title about avoiding WooCommerce staging environments. Now, I know why before even reading the article, why this is a thing that you’re talking about, and it’s because WooCommerce and the data structure of WordPress make it very difficult to pull changes forward without having collisions with post IDs.

Sean: There’s a lot of reasons why, which I get to in that article. So, it’s a great read. Thank you for pointing that one out. That’s a really useful one. But for me, it’s all about local hosts. That’s where I do most of my development. And in fact, I have other articles up, one recently the most recent post is about using Homebrew on a Mac just to set up a really fast local environment and switch between sites and stuff like that.

Zach: Yeah, I use Laravel’s Valet for my local development environment. Really fast, really easy, gives me a folder I put things in automatically, and everything becomes a local domain based on the folder it’s in. It’s so much faster than pretty much everything else I’ve ever used.

Carl: Also, a Laravel’s Valet fan.

Sean: Oh, might have to check it out.

Carl: There’s a nice open-source little Mac app too, that lets you manage everything from just a toolbar at the top.

Zach: Yeah, that’s a game-changer. I don’t have that on my studio machine here because obviously, it’s in a recording studio, but the work computer does have that little Mac app running, and so that’s really helpful. Makes it pretty easy to manage. So, yeah, local development environments are, of course, important. We talk about the importance of testing in local before anything even touches a staging environment pretty frequently. And I push a get first deployment and version control scheme to most of my customers, so they’re having to develop in local because nothing gets committed to a repository otherwise. So, that’s definitely something I agree with wholeheartedly, so…

Sean: Yeah, there’s so many gotchas and I list them out, but the idea that if you don’t properly protect it, password wall it, customers might be able to place orders on it, accidentally an email can pop off. A lot of these sites have plugins that send out waitlist emails or in-stock notifications or abandoned carts or something or another that could land a customer on it. So, that can be a real risk. But I’ve even seen some plugins that talk to Cloud services that’ll actually share the URL.
One of them was an advanced WooCommerce search plugin, I forgot the name of it, but it was one of those where if you run a search, it caches that search into the Cloud, and that also serves production, and the search results are going to be whatever your staging environment is. Hopefully, at Blocks localhost, I hope they’ve at least done that, but that could end up causing somebody on production to do a product search and then click a link that then takes them to staging.

Zach: In the environments that I work with things like say ElasticPress, we generally have separate configurations for staging that don’t touch the production environment, just to make sure that we avoid that kind of a collision in the data set itself, so…

Sean: Subscriptions was a big one too, because Woo, the database has all those renewals queued up. They go in the action scheduler, and if you move that to a staging and you happen to have subscriptions… Subscriptions will put itself into staging mode, but not before it’ll try and run some renewals that are in the queue. So, if your payment gateway is turned on, you may have to refund some orders there. I’ve seen that before too.

Zach: Yeah. It tries to detect automatically, but I do recommend in your staging environments, having things set up to disable Action Scheduler completely, just to make sure that that’s never an issue. And so, that’s a very easy way to avoid that problem, because if Action Scheduler isn’t running, then subscriptions can’t renew because Action Scheduler is what does all of the renewals.

Sean: Unless you need Action Scheduler for some of your staging and testing, but maybe not, it all depends.

Zach: Yeah. And generally, I don’t see a need for scheduled actions to run in a staging environment.

Sean: Unless you want to keep it clean because there are some cleanup jobs that run that keep the environment a little bit more tidy.

Zach: Yeah. Most of our staging environments are temporal, so they’re created for an individual task purpose and then they go away, but they may reuse a staging URL, but yeah, they’re all temporal in nature, so…

Sean: And that right there solves a lot of problems, just by not keeping it online for very long. That itself solves some of the issues.

Carl: Yeah. I disabled the Action Scheduler unless it’s run via Cron and Cron’s disabled. So, that’s by default.

Sean: And if you want to keep staging up to date, you spend a lot of time just trying to keep it up to date and maintaining it unnecessarily too. Whereas in local, I would typically only activate the plug-ins I need for what I’m actually doing on the site. I don’t really look at it as something I need to be maintaining all the plug-in updates except for when there’s a big operation taking place. So, staging because it’s shared amongst others, you have more security concerns, so, therefore, you need to keep it up to date more.

Zach: Yeah. And in those cases, the temporal nature helps a lot because staging is built off of a staging branch in Git, and that branch generally has a feature branch push to it when it’s ready to be tested. So, that feature branch overrides everything, and at the time that the feature branch gets pushed to staging, the database gets pulled down from production at that moment in time as well. So, generally, we don’t run into a lot of issues there.

Sean: Yeah. Wow, you’ve got it really ironed out. Most of my clients are on the smaller side, so their idea of staging would be going to WP Engine, click add a staging, copy it directly from production, you get the whole enchilada, and that’s where you run into a lot of these issues.

Zach: Works really well for content-based websites, and not really well for complex applications built on top of WordPress.

Sean: And with all the plug-in licenses that like to turn themselves off too, maybe not the top-grade plug-ins that do that, but there’s definitely a bunch that will. I will pick on Elementor Pro, for example. They don’t like a lot of the staging URLs, and they start turning features off for you, which is not so fun.

Zach: There are a number of plug-in companies that are increasingly supporting Composer for bringing plug-ins into a project. So, as long as they’ve added support for private packages, you can generally include license information in an environment file that then is brought in during the build process. And that will generally work for most major plug-ins now. So, that’s what we tend to do, get as much of the activation of those license keys into the build process as possible. And that way when we have to update a license key, if that happens, it’s updated in one place that’s in version control. These are the concerns when you’re building something that you want to have hardened for security and for ease of deployment long term. You just have to focus in on these things to get them into the right place. And that’s a lot of what we do.

Sean: Which it sounds like you’ve done a great job of, so again, I’ll preface that my article’s going to apply more to the masses. You’re definitely high-end, you’ve got these things figured out, you’re beyond what I’ve done with staging, I could tell. But still, in general, people should be wary of staging environments and the pitfalls that they may not necessarily think of, and then face these issues, even on a smaller site. It doesn’t have to be enterprise-level. Just on a smaller site, you can start to have these issues. It depends a lot on your plugins, of course. It’s the answer to a lot of things in WordPress and WooCommerce is, it depends on the plugin.

Zach: And whatever you do, do not create new products in your staging environment and then sync your database from staging to production. Because if you do that and you’ve had orders on your live site, those orders will go away and that’s a problem. So, yeah, that is why I hope that custom order tables, the high-performance order storage is only the beginning of getting our WooCommerce data out of the core post and post meta tables. Because if products were in their own table, well then this wouldn’t be a problem. If every data-

Carl: You still shouldn’t do that either way. General practice is you want the code to move up and the data to move down, basically. So, code goes from dev, staging, production, data goes from production, staging, to development, basically, and not the other way around. Obviously, there’s exceptions, but they should be really exceptions and not something you do. You should be very careful, take backups, take backups before you do anything, too.

Sean: For sure. And if you do need to launch a new line of products or something where you do want to stage that content somewhere, use an export-import which Woo, for products, already has built into core, export those to a CSV file, maybe even test importing that CSV in a local environment just to double check your work. QA, right? And then you can then launch that in production. But WordPress also, Core has a built-in XML exporter, importer for various post types and media by month for example, and things like that. So, there’s a lot of ways to piece it together in production step by step.

The safest way to go do one thing, test, and just continue. This is why releases for e-commerce sites can take a couple of hours to do because even after you’ve prepped all that, you’ve got multi-steps to do a release. You’re not just pushing code, you’re also changing configs, updating those, moving content over testing at every step of the way.

Zach: Yeah. And there are some very cool ways to handle doing live deployments in a way that the site doesn’t go down and you don’t have to take the site down completely, but it’s really, really hard to do that well in WooCommerce. So, in most of these cases when you’re doing a major site release, you’re probably going to have to put your site into maintenance mode to make sure no new orders come in while you do all this work.
And unless you’re not doing a ton, if you’re doing a large release where there’s numerous products and a whole bunch of front-end work that’s changing, you’re best off doing it during your most non-peak hours and taking the site completely down while you get it all in place and working and then bringing it back up when it’s done.
Sean: I did it that way just a couple of weeks ago. I was switching a site from Elementor to Blocks full story editing or full site editing as some might call it, right? Because that was a theme change all the templates had to be set up. I had to do maintenance mode for about half an hour at what, eight o’clock at night. So, well, it wasn’t so bad, but normally you can just put cart and checkout into maintenance mode. That way people can still browse the catalog while you’re making changes, but not if it’s a theme change.
And I think we’re going to see a lot more theme moves into Blocks. I would love to talk about Block themes at some point today, by the way. I relish the idea that your theme could simply be just a few little files that just turn on full site editing that really it takes the theme decision out completely now, you don’t even need a theme, you just a few files that engage the Block Editor for all the templates, I love it.

Zach: Well, let’s go ahead and jump there for a little while. When full site editing first came out, probably the first major use that I saw of a full site editing theme was Pagely doing their site redesign, right? That was a very prominent site redesign that was using all of the FSE features, but they started that during beta and then had to change it all because it changed quite a bit for the first production version and now it’s changed even more, and it’s gotten more powerful as time has gone on.

We’ve learned some things along the way, like how important it is to make sure people understand how to create a menu because that was not easy for a little while. We went from having, in my opinion, the easiest menu editing experience in content management systems across the board to suddenly our way to create navigation became mystery meet navigation itself. And it looks like we’ve ironed out some of those issues at this point, but that’s the fun of open-source software, right? We get to innovate and change and sometimes the experiments don’t work and sometimes we have to fix that, but we may go full release without having that fully fixed, right?

Sean: Yeah, my own site, which I sort of treat as a Guinea pig for some of this, I had redone, what did I use? Not the Blocksy theme, the Block-based theme. Well, first there was the 2021, what did they call it? 2021-Blocks, there was that. That was a total dev track, but the first actual theme I could think of before 2022, and then now 2023, we had BlockBase which automatic was using as its base for the block themes that they were developing. So, that was just a Vanilla thing to start with. But I love the idea now that you just make your own theme and it’s just the theme.json with just some definitions in it, an index.php, an index.html sitting inside of your, I think it’s called the templates folder, and that’s it. That’s all you need to engage the builder, and then it’s just a blank canvas, just build away at that point, design away.

Carl: Well, and I find it very interesting because there was a long time where, as WordPress developers, we were trying to figure out how to do things like allow plugins to override or have their templates, their pieces of HTML and PHP that they output, overwritten by themes, right? And now we’ve gotten to a point where a whole bunch of stuff that’s part of WordPress core, just by its nature, can be themed by Blocks, but it’s all tied to this concept of everything being a post myth, post meta. So, when we move into Blocks in the WooCommerce space, there’s a lot more custom development that’s having to happen.

Sean: But it’s still very thin, that development. It’s not like you’re building giant things like I’m doing a lot of short code, I’ll take code snippets I wrote before and I’ll just make them and add short code and then pop that short code into the block template or the page if you’re editing a page or post. That way, you could bring that dynamic PHP output you could enqueue scripts and styles if you need to. When it comes to styles, I’m really liking the register block style where you can actually make the style variance within the native Blocks.

For example, list, the list block, you want to make a horizontal version of a list. It’s just a few lines of CSS and you could register that in PHP. I do a lot of the PHP sites still I haven’t really gotten into the Node side of Blocks yet. I’ve played around with it a little bit. I did add a block into one of my plugins, but generally speaking, I stick to the PHP side of block manipulation, filtering render block, for example. But the short codes is the go-to. And we recently had a little issue with the latest version of WordPress that fixed a security bug and ended up breaking short codes in block templates, which I reported, they fixed it the next day.
I’m sure a bunch of people reported it, not taking credit there, but I participated, which is a whole other topic, QA is everybody’s job that’s another discussion, but it’s one that we need to have as well. Anyway, sorry to break your train of thought.

Zach: No, it’s okay. You can break any train of thought here. You’re the guest, that’s why you’re here.

Sean: Thank you.

Carl: And I’m an ADHD mofo so, basically, I don’t stay on no track ever.

Zach: Yeah, there are no rails on this podcast. We don’t have rails personally, so why would we keep them on our podcast?

Sean: So, we’re going to start the Shopify talk now then on why Woo is better?

Carl: I mean, I have a lot to say there too. I think we all have a lot to say about Shopify versus WooCommerce versus just getting WooCommerce to behave.

Sean: Blocks ties into that too because, so this actually bridges these two topics because Blocks is the official answer that provides a free core, built-in, fully supported solution, right? Would you agree, Carl? Sorry to interrupt you, but I just had to, these tie right together.

Carl: No, no, no. I mean I’m more, I’m full stack, but I definitely prefer backend work. And I mean, I’ve been assistant since I’m like 16, so I do the full thing and EMIR is a hosting solution. But I think what people get frustrated about too with Shopify is not just the front-end stuff, is just the scaling stuff. It’s the performance, just the store.

Zach: Like if you want to have more than two admins on your site, for example, you got to go to their higher level, the next higher level or I think it’s two admins on the basic, and the mid-grade is five admins. You’re limited at that. And that, to me is just silly.

Sean: Well, and even beyond that, let’s just talk about the ability to do things that exist outside of the black box known as Shopify, right? So, if you want to do anything that requires custom code that would be in a custom app that is proprietary to your company and not something that’s offered on the marketplace for everyone to use, well that functionality requires Shopify Plus. And the difference in price there from basic is going from $29 a month to $2,000 a month because writing custom codes should require spending $2,000 a month, right?

Zach: And, of course, you still have to hire the developer as well and Shopify developers because it’s maybe a bit newer and they’re probably not as affordable as us hardcore open source devs out there with… What is Codeable at now? They’re at what, 120 an hour. Upwork is somewhere around that too. So, I roughly match what’s out there. So, I believe it’s a great value. WordPress devs, we do a lot.

Sean: We do. And let’s not even talk about the Magento developers that I’ve heard about that charge $2,000 an hour or… Yeah.

Carl: I mean Magento’s a completely indifferent beast. I’ve definitely touched Magento, that’s a different beast entirely. You don’t really touch Magento unless you’ve got a Home Depot budget. It’s a bit like Droople and the education sector. If you deal with Droople, you have to go through AQIA and you need a college slash university/tech budget to deal with them.

Zach: It’s really interesting to look at how competitors to WooCommerce are positioned, and let’s just talk about that subject as a whole for a moment, right? You have your software as a service companies, you have your Shopify, you have your big commerce, you have even some tools like Ecwid, right? But then you have this enterprise-level e-commerce platform space where the SAP hybrids of the world live and IBM Demandware and Salesforce commerce and Adobe’s hosted version of Magento Enterprise called Adobe Commerce Cloud, that ties very deeply to their Adobe experience manager, right? And all of these tools in comparison to WooCommerce are harder to develop for. They are a much higher barrier to entry to doing anything custom. And they are expensive. They’re very expensive. Now Shopify and big commerce have plans that are focused more toward smaller store owners. And in the software as a service space, you can do that because you know that your smaller stores are probably in most cases not going to become bigger stores. So, they’re still paying for more than what they use. And then that subsidizes the people who may still be on the low plan that are doing medium plan business, right? And so, the software as a service model allows for that subsidizing of other people who are paying more for less or less for more. And so, that’s really helpful

Sean: Over time. So, is it maybe short-term thinking that sends some people in the direction of Cloud proprietary SaaS? Because that’s month after month, after month, after month, that’s percentages of your revenue. Really that’s going to add up and they’re going to turn up the heat on that frog over time. I mean, YouTube used to have no ads, then it became one ad, now it’s two or maybe three. I don’t even want to watch YouTube any more unless you get their paid version, right? So, what’s Shopify going to do, they have the full control there. And, of course, WooCommerce is managed by a company too, but you have the benefits of being distributed community based, a lot of feedback going on, more of a nonprofit type of a mentality I would say is what we seem to have. Would you agree with that?

Carl: I mean, there’s a squeeze from WooCommerce. I mean, if you install a Vanilla WooCommerce install and you see the upsells, there’s upselling. But…

Zach: Yeah, I mean they’re absolutely going to try and maximize the spend that you have on things that automatically makes money on. That’s good business. It’s not something that I think is a dark pattern or anything.

Sean: Well, you’ve got to fund the project.

Zach: Right. Exactly. Exactly.

Carl: Yeah, you got to fund the project. Exactly. But it’s still pretty similar, I find, between both products, I would say from that experience standpoint.

Thanks to our Pod Friends

Carl: I think there’s a lot, I don’t know for you, Sean, but a lot of the frustration to move to Shopify is performance of when you start adding a lot of plug-ins and behaviors and getting that to behave correctly. I was just in a call right before this and they were using Events Calendar, play-in plus tickets plus this, and it was just even with object cashing, you were looking at 300 quarries, SQL queries.

Sean: But see, in Shopify, you can’t even see that. You can’t even debug it because you don’t have access to the sequel system.

Carl: But it just performs better, no? What’s your experience?

Sean: So, let me talk about one of my bigger clients who uses both Woo and Shopify and she likes to say Woo makes sense when you’re selling about a million a year or more. I don’t really see it that way, but basically, what she’s saying is if it’s a more smaller, more experimental site in her view, she perceives Shopify as more of a do-it-yourself that she could do where she doesn’t need to have a dev get involved. But then we always run into these problems, and we keep coming back to that, “Well, you don’t have that problem in Woo, do you?” Wink, wink.

Carl: Can you give an example? Yeah, give an example.

Sean: Well, the number of admins thing, a friend of mine who works on Shopify stores quite a bit, told me to install the Speedium plugin to fix page speed mobile because I monitor my Woo sites and her Shopify sites and she’s my client. I want to give her, “Oh, you got an accessibility problem here. Oh, you got a performance problem there. Look at this page.” I monitor that, monitoring’s part of what we should be doing as developers. And so, I tried to install the Speedien plugin and Shopify, but oops, “Your account’s been suspended.” So, I emailed the client, “What’s going on?” “Oh, I hit my five. I had to demote you temporarily. Let me see who else I could boot off before I can let you back in.” Right?

And I’m looking at her apps and sure, it’s the same number you would see in WooCommerce generally. And again, performance-wise it’s having mobile page speed trouble. In fact, it’s one of the lowest scoring sites in my whole matrix that I’m monitoring right now are some of the Shopify sites. So, there’s a…

Carl: Interesting, because that goes against a lot of what I hear actually.

Sean: There’s a perception versus reality, in Woo, it’s more editing product that’s slow for the admin. So, that creates that perception. But what really counts is the front end and what Google is seeing and what your users are experiencing. So, perhaps, and again, I’m looking at my sites that I’ve already cleaned up, that probably would segue us into a whole new topic about WooCommerce cleaning. You want a WooCommerce site to be fast and to blow Shopify away, clean it out, consolidate your plug-ins, use good quality, trusted plug-ins, monitor performance, clean the database, keep things tidy.

Carl: I have to explain that all the time when I onboard people on YMIR because it’s more sensitive to that and it’s more sensitive because everything’s not on the server. So, latency has more of an issue. And I have to explain to them, “You can’t just necessarily toss something in…” And most WooCommerce, like yourself, you know this, the expert and the enterprise agencies know this. You have to actually go in and tweak the performance based on the actual profile of the store.

Zach: It’s really interesting because a lot of the work that I do comes out of badly performing WooCommerce sites. So, when you said the list of things that you do, it seemed like you had been going to the School of Zach for a while because these are the things I’ve been talking about since 2015, and where those performance things really come in are when you start to have massive traffic events and what’s massive for a store? Well, I generally like to say that a massive traffic event for a WooCommerce store is two times its normal traffic or higher because that’s an order of magnitude beyond what they’ve normally seen. And so, if they’ve never had a problem, but they suddenly experience an order of magnitude more than what they’ve seen, they may start to have problems, so…

Sean: Yeah. And that is where your hosting is so important it is and why, you don’t want to cheap out on hosting, but you also want to, again, test. I mean, we can load tests if we need to, that we have a lot more freedom within WordPress and WooCommerce to be able to do these tests. And if you’re concerned that you’re going to get a giant spike, let’s look at it. And this totally depends on your hosting and what they allow, but I’m just going to use Cloudways as an example. That’s basically a VPS-type posting optimized for WordPress.

I got server charts in there. I can go see what the CPU looks like, what it’s looked like over the last 30 days, et cetera. You could drill that down. You could connect New Relic; you can install the Query Monitor plug-in and take a look at your real-time queries that are happening in your admin and your front end and look at all the environment variables. And is my database buffer high enough? That was one of the things on Local, if you read my article on Homebrew and Local, one of the things that I always turn up is my InnoDB Buffer Pool, because these are good-sized databases, and if you don’t allocate enough RAM to that, you’re going to have performance issues.

So, any performance issue you have at scale amplifies. So, it’s really important to identify and to resolve these as much as possible. And the easiest thing people can do is reduce their number of plug-ins. That’s just going with the law of average, I know, two plug-ins are not the same. One may be giant; another may be tiny. So, you can’t necessarily just purely look at count. But I generally look at, I expect a Woo store to have a good 25 plug-ins. And if it grows to 35 and you’re on a private server, I’ve had a lot of success with that. As you get beyond that, it’s becoming unmaintainable. How do you keep track of all these vendors and their updates, compatibility issues, et cetera? It’s just too much.

Zach: You mean 112 plug-ins is too many, especially when five of them are sliders?

Sean: Well, there you go. That’s the thing. How come some of these sites… I find abandoned plugins; I find three different slider plugins. I’m like, “Okay, the scientific process, go back to elementary school here.” You measure before, you run the experiment, you measure after and then you make a decision, “Did it win, or did it lose? If it wins, you keep it and you get rid of its predecessors. If it loses, you get rid of the experiment.” You clean up after yourself. It’s very simple. You’re in the kitchen cooking a meal, you got to clean the kitchen up before you get to the next meal, right? So, why do people have three sliders on their site? It boggles my mind.

Zach: In some cases. It’s just simply a matter of a lack of knowledge, a lack of understanding. And they buy one of these kitchen sink themes that’s designed to do everything, and it comes with five slider plugins and they bundle instructions on how to install all five of them, but they don’t tell you that you probably shouldn’t.

Sean: Yeah. And again, this is where Blocks is a big solution to standardize around some of the common stuff that people do when laying out their store or their site, and again, there’s a lot of different slider plugins. Jetpack would be the official one. It’s that and a whole bunch of other things. But there’s single service slider plugins you could look at that are very Block friendly. And actually, I’ll give you three single service block plugins that I use a lot when I set up just a virgin block theme without any of these big Cadence-type builder add-ons or anything like that, just purest Blocks.

There’s one called Block Animations that I use a lot when I want to have pictures fade in, things like that. That’s a really useful one. And it’s a simple single-service plugin. Another one is called Create Block Theme, and I can load fonts with that, Google fonts, or custom font files now. It’s probably not a good idea to install those fonts into the 2023 theme. You want to make a child theme or just make your own virgin block theme and use that plugin to manage your fonts. I do that one all the time. Another one is called Lightweight Accordion. I use that a lot for the little dink downs. And it also loads FAQ schema, which is a lot of people are asking for that, for their SEO. So, those three are my go-to Block add-ons.

And I look at them as, they’re small, they’re well maintained, they solve an important need, and they’re not the kitchen sink, they’re not the Swiss Army knife. They’re a precision solution. So, I really want to put a shout-out to those three plugins.

Zach: That’s awesome. And I think it’s really just building the stack that works for you and works efficiently for your clients. That’s the job here, when we’re WordPress and WooCommerce developers, the job is to build something that serves the client’s purposes while managing maintainability and making sure that the site continues to perform even after we hand it off to the client and they do whatever they want to do to it. And that’s where things get hairy is once we hand it off.

Sean: Yeah. Well, and especially, we talked about monitoring earlier, one of the things I monitor is admins on the site because one of the telltale signs that maybe I’m not communicating well enough with a client is I see another dev show up on their site and I need to go have the conversation on who is this person? What’s their role? Maybe they just shouldn’t have been an admin. Maybe it’s a new staff member that they meant to make a shop manager or something like that, half the time, that’s what it is. The other half the time, “Well, we wanted to bring in another designer to help with designs.” Or whatever, whatever.

And at that point, I’m like, “All right, well, I’ll still maintain your site, but I need to communicate with this person. We need to have a meeting. I need to know what they’re up to. We need to be collaborating on releases and testing. Otherwise, I’m going to have to turn my monitoring off and only be available on call for you. I’m not going to actively monitor and maintain your site because there’s another dev doing God knows what to your site. You still have a budget with me. We’ll still work together, but I’m just an on-demand. I’m like a white label, some additional resource for you. I’m not going to go away and leave you high and dry.” Because hopefully this other dev will disappear, and I’ll get the work back.

Carl: It’s also just as a consultant, the burning bridges that way is a not useful way to do it, honestly.

Sean: Well said. Yeah. I don’t want to burn bridges, but I do want to enforce some consequences that are very reasonable, which is that, “I don’t want to go in and be updating plugins and…” I made a whole one-page maintenance agreement about this very thing, by the way. And I don’t make people sign it, I just put it out there as this is the policy here. If you’re going to have devs on your site that I don’t know what they’re doing, they’re not coordinating with me. I don’t want to touch your plugins anymore. I don’t want to update anything. I’m afraid I may break something. We’re not collaborating anymore, so I’m still an hourly resource for you, but that’s it.

Zach: Yeah, no, that makes a lot of sense. And I’ve been in the nightmare situation where somebody whose site I built decided they wanted to hire somebody cheaper, and they hired a designer who was really good at using Visual Composer, and they began the process of building all new pages that they were making with Visual Composer on a site that was well optimized and well-tuned to what it needed to be. And then suddenly pages I had built were getting rebuilt with Visual Composer because this other person didn’t know how to edit it without it. Yeah, I mean, there are definitely situations where a new developer will come in or can you even call them a developer at that point? A new person?

Sean: Well, I love it when it’s a page builder you’ve never heard of, “Oh, we found this person who’s half your rate, who is probably fresh out of college or something like that, but they want to use Breakdance.” And I’m like, “What is Breakdance?” It’s one of the newer ones, right? I’m just like, “In the era of Blocks, why do we have Kadence and Breakdance gaining popularity?” I mean people should be going more purest Blocks.

Zach: Kadence is gaining popularity because it’s Blocks, right?

Sean: Well, but it’s got its own ways of doing things that Blocks can already do. And that’s my big concern.

Zach: It does, and that’s because it existed before Blocks could do those things. So, without Kadence, Blocks wouldn’t be as functional as they are today because Kadence pushed Blocks forward.

Sean: Yeah. And Divvy pushed Visual Building forward.

Zach: Yeah. Divvy pushed Visual Building forward, and Visual Composer did before Divvy did, right? Elementor did too. So, did Beaver Builder. All of these people who’ve helped bring us to where we are now. But I would say that Breakdance is a very different beast than Cadence is. I actually like Breakdance, but I like it because it eliminates the concept of themes completely. If you choose to turn off themes, and then it’s just a page builder and it’s a great experience for an end user. And that’s where Blocks are still a little bit behind is in creating an end-user experience that consistently is great every time, but we’re getting there.

Every release improves the user experience of the core Gutenberg Block Editor, and every time we push a little bit further forward, we get closer to not needing these other tools as much.

Sean: I’ll say that my friends in the accessibility community love GeneratePress because of the strong support… I never even used GeneratePress so, for me, I’m just like, “Really, it should be Blocks. We should be rallying around the standard system that represents us, the community.” But at the same time, I understand they get really good support. And so, that builder, I’m told, does accessibility really well. Of course, so does Blocks, but in their minds, it was about the support and the representation, they’re getting the love that they needed from that builder, therefore they’re going to stick with it for a while.

Zach: Well, there are still people out there who aren’t ready to make the move forward to the Block Editor, and this is… It’s interesting because WordPress is now old enough at 20, nearly old enough to drink, right? But WordPress is now old enough at 20 that it is getting to a point where there are people who have been in WordPress long enough that they’re getting resistant to change.

Sean: Oh yeah. Like me not getting into Node for example.

Zach: Right. Or into React, and that side, the JavaScript side of Blocks.

Sean: It’s all about Vanilla flavor.

Carl: Oh my God, ChatGPT is the best for that. I have to say I’m using the shit out of ChatGPT for that stuff.

Sean: To write your Java scripts for you?

Carl: No, not write it. But honestly, this is a terrible segue when we have 10 minutes left to record, but basically, I’ve been talking and teaching some other developers. The best way to think of ChatGPT is as pair programming if you’re familiar with what pair programming is. So, it’s imagining you have a junior developer that you’re basically working with, so they’re going to be wrong, and you shouldn’t assume that anything you ask is correct, but they will usually know some things better than you do, especially on the language that you don’t use as often.

I do some JavaScript, but it’s usually more Node for the backend. But if I wanted to do some stuff, I could just ask it. And even for WooCommerce, even for WooCommerce, I don’t work with WooCommerce all the time, but I’m like, “How would I do this?” And then it would show me something and then I’m like, “Oh, I know where to look in the code now.” And things like that.

Zach: Yeah, it’s really good at finding the right action hook or filter and giving you boilerplate code for using those things.

Carl: Oh, it still gets it wrong. I asked for an order complete email, and it just did email-enabled order complete. But it’s customer underscore order complete.

Zach: Oh yeah. It’s wrong constantly. And this is where I think that Microsoft actually is getting the naming right on AI because the things that they’re building, they’re calling co-pilots just like GitHub Copilot. So, now Microsoft has internalized that co-pilot idea in all of their AI across the company. So, the office suite is getting a co-pilot that’s probably going to be Clipy, but there’s going to be a co-pilot, right? And they’re all there to sit alongside you and help you do your work, not do it for you. And that’s where the true power is right now in AI, is in having something that can assist you in doing your work more efficiently.

Sean: To think of the inventor of Clipy, I mean, wow, what a legacy.

Zach: Yeah, yeah. It looks like you’re writing an email. Would you help with that?

Sean: I’m going to find a Clipy app for the Mac.

Zach: Oh, Clipy was great. But yeah, you look at these innovations and these things that are happening, and I have a friend who’s working on using AI inside Photoshop to do really cool stuff, like taking every layer and removing its background by typing, “Remove the background from all layers.” These are really cool things that just get rid of the busy work, right? It doesn’t change the creativity; it gets rid of the busy work. And imagine when the first company decides, “You know what, we’re going to release an AI-powered layer that sits on top of Gutenberg.”

Sean: One of the things that we really need that for is ALLText in the accessibility community, especially with these stores with giant image catalogs, I’ve seen some that have like 20,000 images in the media library. And if they’re missing critical ALLText, AI could really help. I wouldn’t say rely on it 100%, but it can really help describe that image enough to where you could just quickly, “Yep, that’s good. Yep. Ooh, let’s fix this one.”

Zach: Something that gets you part of the way there, not all the way, and then gives you a way to review the work that it’s done and accept it or modify it and then accept it. And that’s really where the power is, is in reducing the amount of this busy work that we have to do. If I could tell an AI that was built into WooCommerce, “Please take this CSV that the customer gave me and figure out how to import it.” Without me having to worry about what the headers are or anything. “Here’s a CSV, please figure out how this mapping should happen.” And AI was doing that analysis for me a lot of the busy work of going through that stuff could just go away. And that’s what we should be focusing on using AI for, is taking away the busy work.

Sean: Yeah. I tell you, one of the things in Woo that has been a challenge is when a client brings me a bunch of spreadsheets of inventory that have variations, and I need to now take this spreadsheet of inventory and break these variations out into the attribute columns so that I can import it into Woo and have it automatically set up all the product variations, import them all, and that’s a very time intensive… I got to keep taking my glasses off, it strains your eyes staring at spreadsheets for hours on end. Although it’s good billable work, I must say. But yeah, I mean, if AI could help me with that, I’m all for it.

Zach: Yeah. And I think that’s an area where we’re just going to see more and more growth in the WordPress space, in WooCommerce. We need tools that use artificial intelligence to make our jobs easier and to make our clients more money. Because in the end, when you’re working as an e-commerce developer, there is one rule, there’s one law, and that is, store owners need to make more money, that’s what they do. Right? Scaling their business is all about making them more money.
It doesn’t matter how that happens in the long run, whether it’s performance optimization or search engine optimization, or helping them launch a new feature that gives their clients reward points that they get to come back and spend so that you are increasing the number of return purchases, right? It’s all about increasing average order value, increasing customer lifetime value, and making more money. And if we can use AI and AI tools to help our customers make more money, then I’m all here for the AI revolution.

Sean: Yeah, just don’t trust the code that it generates. You still need that human review, I mean, somebody would have me bring a WIC site over and I would look at the generated source and just be like, [inaudible 00:54:36].

Zach: That’s not even AI.

Sean: I’m just going to put your WIC site on the left side of my screen, the builder, whatever builder I was using at the time, on the right side. And I’m just going to lay this thing out myself because I need that code to be good. I don’t want to bring in a bunch of junk code, which Gutenberg has become a lot better now at cleaning up, although those in the accessibility community, tell me to copy, paste from Word into Google Docs and then from Google Docs into Gutenberg.

Zach: Yeah. I actually use TextEdit quite frequently as an intermediary between whatever document I’m going from into Gutenberg or whatever other editor I’m using just because I like using a tool that strips formatting in between the two tools, so…

Sean: Yeah, I do that with Visual Studio Code all the time, so I’m with you there.

Zach: Strip the formatting and get it in there is raw text and trust the theming that you’ve done, whether that’s in styling how Blocks are displayed or in setting up an Elementor Breakdance theme. But trust that to do the styling and just provide the content, so… Well, we’ve definitely covered the gamut here today. We took a journey through WooCommerce development, and it was a nice little jaunt. I was happy to be your guide during this tour today. Sean, where can people find more information about you? We’ve shared your website and we’ll have it linked here to Coded Commerce, but where can they find you on social media? Yeah.

Sean: Well, the best place, I would say, by wordpress.org profile has all the links or go to codedcommerce.com, C-O-D-E-D commerce.com. And I’ve got all the stuff there on my contact page. But yeah, my own site, or you could just email me at sean@codedcommerce.com. I’m happy to provide some free tips here and there. Obviously, I do this work for a living, so can’t go too far, but I’m happy to point you in the right direction at least.

Zach: Awesome. And if you too would like to take the journey that Sean took today of becoming a guest of the Woo Dev Chat, feel free to use the form on the Do The Woo website to submit a request. And if you’re lucky, we’ll put you in the hot seat too. Sean, it was a pleasure having you here today, and I hope that our listeners have gotten value from having you here as a guest today.

Sean: Thank you, Zach, and Carl. I appreciate the opportunity.