Optimizing WooCommerce Support for Developers

Zach: Hey, Zach Stepek here with Do the Woo and I’m here with Andrew Wikel today. Andrew, what’s going on man?

Andrew: Not too much. Pretty excited about this.

Zach: We’re friends, we’re co-organizers of a meetup together, we’ve co-taught sessions at WordCamps, we’ve driven across the country together. We’ve done some things, and I wanted to bring you on because I think you have a unique perspective for this audience that comes from the years of experience you have working where you have for the last, what, seven plus years?

Andrew: Yeah, it’ll be seven years officially at Automattic here in two months, three months.

Zach: And then at WooThemes before that.

Andrew: Yeah, a couple months there.

Landing at Woo

Zach: Why don’t you talk a little bit about your background and then we’ll jump in. What brought you to WooCommerce in the first place? Let’s start there.

Andrew: Okay. I’ve been working with WordPress for a long time, probably 12 years, so I dabbled in it. Basically, in my friend group at the time, it was a whole bunch of just geeks. Everyone was a geek, but we split ourselves in two subgroups. One was a design geek and the other was a web geek, and I was like, “Well, I can’t even draw a stick figure, this doesn’t work,” so I’m going to be a web geek, that’s what I’m going to do now.

Andrew: My buddy taught me the basics of WordPress and Joomla, and I figured out fairly early on I didn’t want to work with Joomla. I’m not knocking Joomla, they’re a fully fledged content management system doing well, but it just wasn’t what I wanted to do at that time. Started learning WordPress and worked at a nonprofit for a while there, and I joined WooThemes shortly thereafter. I wanted to take my career to the next level, specifically in WordPress tech, so I joined WooThemes and a couple months later we were acquired by Automattic. I’ve been here ever since. Yeah, the sale officially closed July one so that’s our official start date at Automattic.

Zach: It’s hard to believe that it’s been that long now since the acquisition. It doesn’t seem that long.

Andrew: It feels simultaneously like two years and ten years, because I feel like I haven’t been working there that long, and then I’m like, “Oh no, wait, it’s been a long time.” It’s almost hard to remember pre-Automattic, at this point, anything.

Zach: It’s interesting, because I was around during those beginning days of WooCommerce. I think I started working with it in 1.1 back when plug-ins were still a Trello Board and people could just go in and grab a plug-in they wanted to develop.

Andrew: It was the wild west.

Zach: I can’t even imagine, looking back, how many of those Trello tickets were owned by Max Rice, which is how SkyVerge started, right?

Andrew: Yeah, pretty much. It’s really cool, SkyVerge and Max and Beka and their team, the story there is really cool. It’s almost like the story of WooCommerce, basically. You find a niche inside the ecosystem and you’re like, “Oh, I can do this,” and you just nail it. You just kill it and grow from there.

Zach: And they did, they nailed it. They absolutely nailed it.

Andrew: Yes. All their plug-ins are stellar. Back in the day, WooCommerce actually used to support every single plug-in that we sold, even the ones that weren’t developed by us, for a long time. There were certain plug-ins and certain development teams that when we got one of their plug-ins, it was just cringe because we knew it was going to be a nightmare to unravel everything. Then, when we got a SkyVerge plug-in, it was like, “Oh, well they actually have real debugging, and everything’s built on the same framework, and I know that it’s going to work this way every time.” All their plug-ins are going to work a specific way and they normally just work, which made our job so much easier.

Zach: That’s awesome. I had the same experience with their plug-ins. That’s why I wanted to partner with them early on, because I knew that their plug-ins just worked. Given your background, you were building WooCommerce sites, so moving into a support role, being able to support as a builder yourself, with the background and the ability to write code and debug things, brought a unique perspective, I think, to that team because some of the people there had built real sites, but some had were just familiar with building sites.

The perspective from building a site vs just knowing the code

Zach: There’s a bit of a difference there, and when you’ve built a functioning e-commerce site with a platform, you get a different perspective than just if you know the code base or know what it’s supposed to do.

Andrew: I think there’s a wide variety of things that can make a customer support agent successful, and sometimes it’s you are just super empathetic, you’re the nicest person to talk to. If I have an issue, I know you may not know how to solve the issue exactly, but you’re going to empathize with me and you’re going to make sure that I get taken care of. Then there’s the people that you’re going to be polite, you’re not the people skills person. Your empathy is okay, there’s nothing wrong with anything, but you’re there because you know that code base back and forth and you know exactly where this JavaScript conflict is going to happen, or whatever it may be.

Then there’s the niche that we’re in, e-commerce, it’s very different than just running a website. It’s very different than just knowing code, and so there’s those people in support that have, or currently run, their own e-commerce business, so they’ve run into the issues that you’re seeing with shipping calculations. You don’t know how to explain it, necessarily, to a developer or to someone who’s just trying to empathize, but you’re like, “No, I just need some advice on is this a realistic amount to charge for shipping?” Not necessarily, “Is it returning exactly what the USB API is telling me?” but insights more along that line. I think that having a mix of those in a support team is very beneficial. They could find stuff that you don’t even know you need.

When it’s core priority

Zach: Exactly. WooCommerce, as a platform, is great, it’s a giant ecosystem, but that’s not where a successful e-commerce site stops. There are other things, like transactional email or marketing email, and there’s shipping and shipping calculation, there’s packing an order. That’s a whole ecosystem in itself. There’s all of these various things, payment processing, customer relationship management, customer service and returns management. These are all things that are part of the ecosystem, but can’t be part of the platform and be as targeted as some of these targeted solutions are in those areas, but that’s never going to get to the point where it is as robust as something like a ship station or something like that that can bulk print labels and packing slips, or some of these other ERP-tied solutions that can tell you what path to walk through the warehouse to pick the order.

Andrew: Building something like that into e-commerce just isn’t feasible for where it’s at because 99% of the people that use WooCommerce don’t need that feature. Spending hundreds, if not thousands, of development hours to develop a feature that realistically benefits probably less than 1% of WooCommerce users isn’t a great use of resources.

Zach: That’s exactly why, if you’re a listener and you listened to the podcast that we did in January with myself, Till and Carl, we talked about why custom order tables was not a core priority until now, and why it had to get to a point where there was a swell in the number of stores that were doing that kind of volume. Now, enterprise WooCommerce is a more common thing. Large scale WooCommerce is way more common than it used to be.

Andrew: I remember being at WordCamp Chicago and watching a site that will be unnamed go down repeatedly because a product launched on it.

Zach: Yep, I was there for that.

Andrew: We were curiously trying to figure out what’s going on and offering what help we could. It is a different beast now, because that was six years ago or whatever it was and the market has evolved rapidly since then to where that’s not as much of an anomaly anymore. That was the only site at the time, really, that we had heard of that was having these issues. It’s a big site, it’s a big customer and it’s a big client. We can’t drop everything and work on this right now.

Zach: And now WordPress Core has a performance team that’s working on improving the performance of WordPress itself, and all of that’s going to roll into the performance of WooCommerce over time, and I’m really excited to see, as these developments start to move along, where we end up.

Andrew: I see it moving in a great direction and performance for WordPress is going to benefit all e-commerce sites, obviously, but pretty much everyone, and I’m here for it.

Those fatal error troubleshooting tips

Zach: One of the things that you generally speak about at WordCamps is troubleshooting WordPress sites when they go bad. When something happens, when you get the white screen of death or when you have a fatal error on your site that you’re trying to track down, can you share just a brief amount of some of the troubleshooting tips that you would give to somebody troubleshooting a WooCommerce site?

Andrew: The first thing, don’t panic. It’s super cliche, “Don’t panic, everything is going to be okay,” but it will be. Everything on your site is fixable. You could figure out fairly quickly, normally, what the issue is, or where the issue lies, more. You can be like, “Oh, well I just updated my theme, probably something to do with that,” but if you’re panicking, you’re not thinking rationally, usually. You see maybe the text of a stack trace or something, and you’re like, “Ah, it’s got to be that.” You go to that plug-in’s support and they’re like, “Well, you just pressed update on the theme, and now the theme won’t load. I think it’s the theme.”

I think the number one thing is just chill out. Calm down, think rationally. The next thing is retrace your steps. Your site was functioning yesterday perfectly, what changed from then to now? That’ll help you narrow things down super easily, normally. Some things are hidden. You’re like, “I didn’t touch it. I didn’t do it at all,” and then you look back and your host auto-updated your plug-ins for you and your like, “Ugh, okay, cool.” They usually tell you, “We updated these five plug-ins,” or something like that, or you can get that information. At worst, you can ask their support and they’ll tell you, “Oh yeah, we updated this payment gateway, your theme, and these two not WooCommerce-related plug-ins.”

Then you can be like, “Oh, okay. Well, I see the error on the front end and it’s on the homepage, so it’s probably not the checkout plug-in and it’s probably not the other two, so there’s a good chance it’s the theme.” You can go in and you can look at change logs for the theme and see if they updated anything big that stands out. If nothing stands out, if it’s disturbing your site, you’d probably want to roll back the version to the working version before, and there’s a bunch of plug-ins out there that can help you with that, or your host could do it too.

There’s one called, I believe WPRollback is the name of the plug-in. That does it pretty well. Obviously, you should have backups all the time, but rolling back a backup when you have orders or changes in that timeframe isn’t usually ideal at all, so we can fix it on the code side, normally, by changing the code base of the offending theme or plug-in. In this case, roll back the theme, see if it fixes it, and if it does, go contact support, and if it doesn’t, probably still going to want to contact support at that point anyway, but you’ve narrowed it down at that point to a theme, in this case.

Zach: I think that’s a really important thing, and two of the best tools in my experience for finding issues like that. One, you’re going to want to either look at the logs or turn WPDebug on. The other thing that I find very beneficial is a tool like New Relic to see what’s happening behind the scene. What database queries are happening, see where things are slowing down. If it’s a timeout issue that you’re getting, then New Relic is probably going to find where that timeout’s coming from.

Andrew: Query Monitor has been beneficial too on the WordPress side. The New Relic and Query Monitor stuff is a lot of debugging your own code if you’re writing things, more or less, but if you’re using off the shelf plug-ins and themes and modifying CSS or something like that, most of the time, you just need that help pointing a finger towards something.

If you’re writing any kind of code, you’re going to want something like New Relic, Query Monitor. Health Check is a pretty decent tool. It’s pretty rudimentary, it’s not getting anything deep out of it. It enables you to do conflict testing without disturbing the rest of your site, which is super beneficial.

Zach: System Status Report isn’t horrible either. It’ll tell you a lot.

Andrew: Yeah, it tells you a lot. Let’s say you’re developing 10 sites or you’re managing 10 sites, you don’t remember exactly the PHP version of every single site, normally. Especially if they’re on different hosts. Just being able to one-click look at all the core base features of your site, knowing what PHP version they’re on, knowing what database software you’re using and the version of it. Like, “Oh yeah, I use my SQL for everything and this one’s on MariaDB,” and you’re like, “Oh, okay.” It should work, but there is a difference.

Zach: That’s absolutely one of the things that I would recommend is knowing the environment you’re in.

Andrew: 100%.

Thanks to our Pod Friends Iconic and WP Activity Log

Databases, exporting orders, the harder parts and their mitigation

Zach: One of the other things that I find very interesting about debugging and WooCommerce sites in general is like you said, we have constant database changes happening. We have new orders coming in, maybe customer service is adding new products or marketing is working on new pages, and all of those are in the same table. All those changes are posts. Products are posts, orders are posts. That’s why we’re talking about moving these to their own tables, eventually, but right now, getting a backup that only includes certain things is difficult.

You can export all of your products and then import all of your products, and that works if you have to wipe the database for some reason, but orders are harder, and that tends to be the most important part of an e-commerce site. Have you found any strategies that people are using to mitigate that, other than the obvious, which is make changes on a staging site, not on your live site, and test everything thoroughly?

Andrew: Yeah, I’ve seen two things, and they both work, it’s just how you want to handle it. One is just having a software, whether that’s you or your host or whatever it is, that does a full site backup at least daily. That’s the bare minimum at this point. Ten years ago, it was, “You back up your site every day? What are you some kind of freak? Who packs up their site every day? No, we’re weekly.”

We’re getting the way where people are doing it every time any action runs, basically, on the site. Any time you update a plug-in, it’ll automatically back up for you, which is fantastic, so you have multiple backup points per day. Taking those and using your favorite tool, whether that’s the command line, or… I’m drawing a blank on the SQL plug-in I use, like a match app. I don’t remember, but they’re GUI-based apps that you can use to navigate SQL databases and remove tables and add tables and stuff. You can that to manipulate the database so you only have what you need to re-import. Or you can use something like phpMyAdmin or something to make those changes.

You don’t need to reimport necessarily everything if 90% of your site didn’t change, but you’ve got five orders in. You can do it that way. The other is using a plug-in to just export orders, and there are ones that you can have set on a schedule. You could just say at the end of every day, “Export all orders to CSV or an XML file or some kind of data file.”

It’s not as robust as having just an SQL dump, but if you just want the orders, that’s pretty easy and it’s human manipulatable, where you can open an Excel and be like, “Oh yeah, this order,” which can be very useful.

Zach: Or even import it into a system for reporting. I’ve seen that done pretty frequently, where that daily backup turns into something that gets imported into another big data system that runs reporting.

Andrew: You can just put it on your server and then the other system FTP in basically, and grab it that way. That works pretty well, honestly. It’s using ancient technology as far as the web’s concerned, but it still works. It’s the data. Not everything needs to be super fancy and slick, FTP still works.

The number of times caching is the issue

Zach: How many times does a ticket come in and the problem ends up being caching?

Andrew: So many times. People know they need caching, you see this in all skill levels, though. You see this from a person who doesn’t know WordPress from Squarespace and you see this from a person that’s architected Time Magazine level sites. Obviously skewed more towards the newer folk. They heard about caching or someone installed cashing for them, whether it’s their host or developer, some guy they got off Fiverr, or they set it up and it gets super complex.

We’re having people that are implementing LiteSpeed in addition to every other cache possible. Which is great, but then they forget to not cache the checkout page. You’ll have someone, it’ll be fine for them because they’re logged into the admin and have all the things set up for them correctly to see it not cached, and the first time they get an order, everything’s great because it’s not cached.

The second time they get an order, that second person sees the first person’s checkout details in pre-filled, because it cached after the first person was done with checkout. Either they catch it and they’re like, “This is weird,” or they just don’t pay attention and they fill in their credit card information with someone else’s billing address, and AVS mismatch, and all this stuff.

That was super noticeable because you could see pretty quickly, “Oh, okay, as soon as I go to this page, it’s someone else’s info.” There’s ones where filtering products and stuff, it behaves very weirdly if it’s cached because you have filter queries, sometimes, that are misbehaving, and they’re like, “Wow, the filter plug-in doesn’t work,” and you’re like, “No, it works, you’re just caching the other person’s filtering on kids small, only showing black colors, and only available to ship to Canada. That’s not what you were looking for, but it’s still returning those items because the filter is cached.

It happens a lot. It happens a lot, a lot. People don’t even realize they have cashing, because it happens at the site level, then it happens at the server level, then there’s some really aggressive browser caching sometimes which skew things if you visit it multiple times. It gets weird, but it happens pretty regularly.

Zach: It gets really complicated figuring out where the cache issue is coming from and making sure that you know that you’ve cleared every step along the way, but that’s a hugely important step in debugging with any WooCommerce issue is, “Have you cleared your page cache? Have you cleared your object cache? Have you reset Cloudflare’s cache?” because sometimes you’ll just get caught out with something where it doesn’t show until you clear all the caches.

Andrew: People don’t realize that they have all these caches a lot of times. In what you mentioned, there’s probably three to four dashboards that they have to go to clear everything if they have all the things in place that you mentioned. Missing one doesn’t work.

Zach: What I love is when you have somebody who has minification turned on in their WordPress plug-in and they have minification turned on in CloudFlare, and somewhere along the way, JavaScript is getting borked, which is the technical term.

Andrew: That happens regularly. Minification is great, but there are a lot of things that don’t play well with it in certain instances.

Zach: Especially if it changes the order in which certain things are getting loaded.

Andrew: They’re loaded that way for a very specific reason.

Zach: I’ve been a huge advocate for a really long time about themes being themes and not functional.

Andrew: I’m pretty high on that horse as well. I think it’s getting better. From colloquial, anecdotal data, I think it is getting better, but it used to be a really big problem where the theme would just basically take four plug-ins and stick them in the theme code instead of just bundling the plug-ins or requiring the plug-ins.

We would have a page that just wouldn’t load for whatever reason. Going back to the good old example, the filter just isn’t working on the shop page, and you’re like, “Well, everything looks fine,” and then you’re like, “Oh, there’s a whole filtering plug-in built into the theme.”

Even better is when someone has a filter built into the theme and they add a plug-in that adds a filter, but it doesn’t sound like it should add a filter, and then they add a filtering plug-in and you can’t figure out which of these three things are controlling this specific filter that’s showing on your shop. That’s super fun.

Full-site editing and Gutenberg, what excites Andrew

Zach: We’re getting close to the end of our time here, but I want to throw one more question your direction while I’ve got you here. I know that you love new technology and emerging technology as it’s coming out, and one of the things we’re starting to see is a heavy push toward more Gutenberg-based full-site editing-driven themes. We’ve had a bit of a glimpse into where WooCommerce is heading with that. We’ve talked with people about that direction and where things are going, but with all of this new stuff that’s happening, what are you most excited about with full-site editing and Gutenberg right now?

Andrew: To be completely honest, I’m super excited for people able to be able to tweak their sites to line up with their marketing goals or conversion goals without needing a developer or a plug-in that may or may not work great to make those changes to the page structures. The traditional way is you have a developer make you 10 page templates, and you’re like, “Okay, well I’m going to use this one. I need this kind of layout,” so I select this one in the dropdown there.

Or, use a page builder, and some are great, some are really terrible, but having that be the default WordPress editor is a game changer. I can just say, “Oh yeah, go in and do this,” and it’s going to be the same no matter what you’re doing on any WordPress site. If I have someone come to me for a consulting gig or something, I can be like, “Okay, so here’s how I like to lay out product landing pages. Okay, if you’re using Elementor, you got to do it this way. If you’re using Divi, here’s the instructions for this. If you’re using Beaver Builder, well, here’s the instructions for this.”

Instead, I can be like, “Oh yeah, Gutenberg. Okay, here’s a file. You can just import this. Done.” Having something like that where it’s consistent, and yeah, there’s going to be a learning curve, there is. Anyone who tells you there’s not a learning is just lying to you, really, but I think the learning curve is dramatically overblown by a lot of people that are super resistant to change.

There have been legitimate concerns about Gutenberg ever since it was conceived. Legitimate concerns. Accessibility was probably the biggest one when it first came out, and those are legitimate. There are other concerns that are people who don’t want to change or people who see their business model threatened because now they don’t control the development hours that I was talking about to make page templates and do all this stuff, and I have to teach my clients how to do this now, all this stuff.

I think that is mostly just people being resistant to change for change sake, and I won’t ever denigrate someone for having legitimate concerns, but I think that most of the concerns that I have heard, personally, were because people just didn’t want to change. That’s not really a great reason to not do something.

Zach: How many plug-ins have we seen that have come out just to customize the checkout?

Andrew: Hundreds.

Zach: And now we have the WooCommerce Blocks plug-in that enables new features in WooCommerce with Gutenberg before they make it to WooCommerce Core, and we have had these new cart and checkout blocks that completely change the game with what you can customize, and they’ve only gotten more granular with time. At first you had to go in and there were check boxes to turn things on and off, and now they’re all separated into different blocks, and you can rearrange things and move things around. It’s a completely different experience than what it was before. When I started with WooCommerce, if you wanted to move those things, you had to unhook something in functions.php, and rehook it later in priority.

Andrew: Just to move blocks around took probably 20 lines of php, somewhere in there. Just to move the billing below the shipping address, those blocks. 20 lines of php just to do that.

Zach: Now we don’t need that at all. We can just rearrange the blocks using WooCommerce Blocks. That’s just the beginning of where we’re going to go with this and that’s really exciting to me, and I would imagine from a support perspective that it’s exciting for you as well, because it’s going to make it so much easier to walk people through some of these changes.

Andrew: Definitely. Realistically, any time that we can make something more functional and simpler to use, it’s a double win. The customer gets more functionality out of their existing software and it should require less handholding on top of it.

Zach: I really appreciate you joining us here today. Why don’t you tell our listeners where they can find you on the interweb?

Andrew: I’m not, honestly, super active on social media and stuff, so if you want a really ancient Twitter feed that’s only active when I go to WordCamps, pretty much, it’s slash1Andy, all written out except for the one, it’s the actual numeral one. Slash1Andy, and that’s pretty much me everywhere, Instagram, on Twitter.

I just started at WooCommerce business too, a WooCommerce shop. I sell martial arts gear, usually WooCommerce, which has been a really interesting foray back into building sites for myself. I don’t do site building anymore, really, working in support, so getting back into the actual e-commerce side of, “Oh yeah, now I have to figure out shipping rates again and I have to check out my margins, all this stuff.” It’s been an interesting thing, and I just started in October so it’s still fledgling, very, very small.

Zach: And where can Brazilian jiu-jitsu enthusiasts find your shop?

Andrew: It’s martialartstraining.supply, and don’t judge the design of the site, I’m not a designer. I’m still working with an actual designer to get it looking properly, but all the content’s there. If you’re into Brazilian jiu-jitsu, let me know.

Zach: Awesome. Thank you, Andrew, for joining us this week. We really appreciate it, and we’ll see you at WordCamp.

Andrew: Cool, it’s been fun. Thanks Zach and thanks Bob, for having me on.