Insights Into Being a WordPress Product Builder

James: Hey, so I’m James Kemp. I’m from IconicWP. I run Iconic where we make WooCommerce plugins, including Orderable, which is a separate product. I also have a side project app called Setary, which is a bulk product editor for WooCommerce, and I’m in the UK and I’m here with Ross.

Ross: Hi. Yeah, I’m Ross. I’m building the search and filter plugin for WordPress, which I’ve been doing for a number of years. Don’t have many other side projects going, and I’m currently based in Barcelona in Spain.

James: Nice. How long have you been in Barcelona?

Ross: Just over a year. Just over a year. Yeah. Yeah. Where are you based?

James: Near the Midlands, well, kind of around the Midlands in the UK.

Ross: Yeah. Nice, nice.

James: You’re from the UK originally, right?

Ross: Yeah, I grew up in Leeds, did my uni in Nottingham and ended up in London before I come in here.

James: Nice. I assume you enjoy it if you’ve been there a year.

Ross: Yeah, yeah, yeah. The only thing is it’s a bit hot and occasionally you get noisy neighbors. Like we’ve had today.

James: Yeah. You’ve got a timeframe, I guess, to work in until they start hammering again.

Ross: Yeah, we’ve got about a 40-minute window. We’ve asked the builders next door to stop. They’ve been very nice. I’m going to have to get them some beers later, but yeah.

James: Cool. Well, let’s dive in then. I guess, do you want to start, what are you working on? Search and filter, I guess?

Ross: Yeah, so what I’ve been working on is the search and filter plugin. It’s been around for a number of years in different forms. Started off as a little hobby side project to test out what releasing a plugin on the repo would be like eight years ago or something like that. And it’s still going today, which is good.

James: I think that’s how most of us started from that period. My first plugin was 2011, and I built it just to see what it was like.

Ross: Yeah, we had a client requirement for a feature like this and it wasn’t quite there, so it was like, “Okay, let’s give plugin building a go and see what the repo was all about.” This plugin that you’re talking about, is that still around today?

James: Well, actually I think I built a plugin just before that, which was like a Magento-WordPress integration, which was a very hacky way to do things because the two systems just did not work together very nicely, but that was quite popular. But I released in 2011, WooThumbs, which is still our top-selling product on Iconic, which just essentially upgrades your product image gallery, you can customize the layout, you can add video to the gallery and things like that. So yeah, I released that as a customer came to me, they wanted to customize the gallery. I made it as a plugin and I thought… I didn’t go the WordPress.org group. I was like, “How can I make more money out of this?”

Ross: Straight to sales?

James: Yeah, straight to sales. Because I dabbled with add-ons for this WordPress-Magento plugin that I had using CodeCanyon. So yeah, this WooThumbs, which back then was called multiple images per variation.

Ross: Very slick.

James: A very obvious name, which literally back then just allowed you to add more than one image to a product variation, and that was it. And that’s what the client wanted. And at the time I was like, “Would it be okay if I released this for sale?” And I think they were like, “Yeah, that’s fine if we can have it for a bit of a discount.” So we took that route. But yeah, it’s still the top seller. We’ve added tons to it over the years, I think.

Ross: Yeah, that’s the thing with these long ones, isn’t it? If you’ve had it for that many years, it’s almost inevitable that it’s kind of grown and kept growing and growing and growing and has so many different facets to it now.

James: Exactly. Yeah. So yours, is it primarily for searching and filtering content or does it also work with products?

Ross: Yeah, so basically it’s for searching any kind of post type and the associated metadata. So we’ve got WooCommerce integration, we’ve had that for a while. So you can build filters for any post meta or any product attributes and things like that. But then it works for any post type, so it’s super versatile and it just uses all the standard, what you’d expect. Taxonomies, Post Meta, we have ACF integration, Meta Box and all those kind of things. So that’s essentially how it works. It’s always going to return a post type as a result or as a list of results.

James: Does it use any kind of indexing?

Ross: Yeah, that’s something. So we had the free version on the repo for a number of years, just kind of sitting there and I was like, “Okay, let’s go pro.” What can we do with pro? And then obviously once you start selling, people start to get more expectations. And then we came up with these bottlenecks back then as well. WordPress wasn’t as optimized with the queries as it is now, but yeah, I think there was certain types of meta queries where really would knock sites over. So yeah, we built an indexer, so once you set up your search form or whatever it goes through and your requirements and which post types you’ve selected and builds, there’s an index for those so searching is faster.

The main reason really actually for the indexer now though is not because of the meta queries, because a meta query can be, say like, cashed by WordPress, but dynamic fields. So I don’t know, it’s like faceted searches, when you select one option in one field, say product category. Clothes, you want the colors to filter down with the only available colors for the other selection. So it’s like dynamic filtering. So that’s really why we need an indexer because that stuff can be really expensive.

James: That makes sense. We’ve got a product called Single Variations, which we had to build an indexer for.

Ross: Yeah. We’ve come across that.

James: It’s quite complicated to keep on top of the index. There’s so many scenarios where that index could just become out of date.

Ross: Yeah. We’ve got hooks for every single type of data updating, like Post Meta Taxonomy Post.

James: But then you’ll get people that go in and update straight in the database.

Ross: Yeah, exactly. Or the user like an import tool which isn’t doing things the WordPress way, so we don’t get those hacks fired.

James: Yeah. I guess as long as you’ve got a method of rerunning that index yourself, then you can kind of prevent those issues.

Ross: We also had quite a few customers come in with, can you support displaying their variation separately because they’re already using your plugin and they want to be able to use our plugin on the same shop.

James: We get tons of people using our plugin that are using the WOOF filter. I don’t know what the full name of that is, but I’ve seen it written down as WOOF. But their product has, at least last time I looked, has next to no filters or actions that we can hook into truly make it compatible with our plugin. We always find it hard to recommend a search and filter plugin.

Ross: Okay. Well I think that might be an interesting conversation for a later date then, because we’re doing a new version and it’s a complete rewrite and it’s been a few years in the making. And the idea is this time around, we’re doing everything as well as possible, we’ve raised the bar on all the standards in terms of code quality, extensibility, integration options, you’ll be able to create your own filters. So you can use our plugin, but you can use our API to kind of program your own filters as well if we don’t want to use the ones that we’ve made and things like that. And the idea is it’s going to be super extensible. We want to get other developers on board to building products on top of our product. That’s part of the new ethos going forward.

James: That makes sense.

Ross: But one thing we’re doing with the current version, it’s not going to work with your plugin as we mess with the shop query. Because I’ve looked into it before and we mess with the shop query and at the end restrict the post type to product only and not products and variations. So it’s like we do all these calculations and variations and products and then at the end we then just say, “Okay, and now only select from post type products.” So I already know where the incompatibility is on that one.

James: Yeah, because our plugin modifies the query to add variations. Among other things. So you mentioned you’re rewriting it.

Ross: Yeah.

James: I’ve taken that path a couple of times.

Ross: It’s not always the right path, is it?

James: It’s not always the right path, especially if you’ve got a plugin that is the age that some of our plugins are. I think we’ve approached it a few times where we come in and we’re like, “Okay, let’s rewrite this part of it.” And then you start that and then you’re like, “Okay, well, to do that, I need to actually rewrite this other part as well.” It’s compounds from there and you end up rewriting the whole thing. Did you go in with a plan?

Ross: I guess when you’re starting these plugins for the first time, I was a much worse developer, let’s say, back then. And I’d built a bit of a mess, let’s say. I don’t know, maybe it’s the perfectionist in me now.

James: You’ll probably look at this rewrote in a couple of years and think the same thing.

Ross: But I was like, yeah, it’s just too messy and there’s too many things that we get to a stage where there was too many layers and layers of not optimal code and not the optimal way to grow and extend a plugin or add features in a nice kind of componentized way. It was a bit of a hunch punch of things. I mean, it works fine, it’s just difficult to extend and to go forward into the future. So I was like, “Okay, let’s do a rewrite on this.” And when I said that, obviously I underestimated what kind of job that would be. But it’s basically because I wanted to change the whole framework from top to bottom, and then also consider a few other options such as, I think when I started building it, Gutenberg hadn’t been quite out, but about six months later it was somewhere in the background, but it hadn’t kind of hit the mainstream.

And about six months later I was like, “Right, I need to integrate with this.” And I’ve seen how everybody is existing classic plugins, they’re adapting to the kind of Gutenberg era and it’s kind of more of a let’s bolt on a block, a wrapper for our short code equivalent or something like that. And I was like, well, as soon as we’re doing a rewrite, let’s go blocks first. Let’s really think about how to give a good experience for a block editor user. Let’s make their experience the kind of primary experience at the end of the day, that’s what WordPress is shipping with. So there was that all that into consideration we did. And then also I did mention I have a free plugin and a pro plugin, but when I released the pro plugin, I mean I’ve got a list of mistakes that I’ve made that I’ve learned from, but when I first released pro plugin, I kind of left the free version to Stagnate.

It was a separate code base, it wasn’t add-on for the free version, free version was this short code, it still is there as is. It’s a really simple short code plugin, and the pro version of this whole admin UI. And what I decided to do this time around was let’s do a proper premium model. We’ve got like 50,000 users on the free plugin, so that’s good amount of users in my opinion that we can start leveraging and also giving a better experience to, especially now the block editors around, they’re going to be demanding support for the block editor as well. So I was like, “Let’s go to a premium model, let’s leverage some of those users, and then now let’s build our pro plugin as literally an extension.” So the free version is now the framework and the pro plugin is a collection of add-ons, let’s say. It’s kind of totally different framework, but I think it’s the right one going forward.

James: That’s similar to what we do with Orderable. Orderable has a free version and a pro version. And like you say, the free is the base of the product and then pro adds either extends features that are in free or adds additional features on top of free. And I think one of the benefits of doing that as well is that you keep your plugin count on WordPress.

Ross: Yeah, exactly. I saw that idea.

James: You get a lot of pro plugins that replace the free version and then obviously those numbers drop on WordPress.org. So I do like that model, but it does have its complexities. There’s scenarios where you need to update both plugins in order for them both to work, and you could have customers that own the update free and then that maybe breaks pro or only update pro and that breaks free. So you’ve got to have those checks built in to accommodate for that.

Ross: I’ve been looking at some of the big plugins for a bit of inspiration on this stuff as well, and there’s an odd one that I’ve seen, which is Elemental, they keep both their pro and free version numbers pretty much in sync, I think. 3.1, they’re like having pro and free. 3.2 and so on. I’m not planning to do anything like that, but I’m just curious as to why they do it like that.

James: I feel like we do do that, not necessarily intentionally, but it just happens that if we are releasing an update then it’s affecting both plugins and they both get a minor version update. I think they’re pretty in sync anyway. I need to check the numbers. But yeah, it’s a good model. We want to adapt it a bit, so it’s a bit more modular, it’s built in a modular way, but as a customer, I think it would be useful to be able to turn these features on and off. So via some kind of settings panel, if the customer wants product add-ons, they could turn it on, if they don’t have it on, then there’s no settings that show up for it.

Ross: I’ve seen some nice UIs from you on Twitter like feature panels and things like that where you can go and switch things on and off. Yeah, maybe that’s for another plugin, but I think I remember seeing something that you were doing.

James: Yeah, it was definitely I posted that exact scenario for Orderable as an idea quite a while ago now. So you must have been trolling my Twitter.

Ross: Yeah, sorry, a while ago because I’ve got a little placeholder where we’re still going to integrate something exactly like that as well. I think it was Leslie Sim, she’s done a really nice settings for her plugin as well.

James: Yeah, I think SliceWP, he was doing something on that front as well.

Ross: Exactly. Yeah. So it’s loads of inspiration, but I basically want to do something right in line with those. Makes a lot of sense.

James: I think it’s really nice and it feels to the person using it that they’re reducing bloat, you can have a plugin with all these features, which could be seen as bloated, but if they’re able to turn it on or off and the code doesn’t even run if they turn it off. I think that’s a good thing for them. Have you seen, there’s a onboard.io I think it’s called, which is mildly relevant, no, it’s onboardwp.io and it’s a guy, Joshua Wold is basically going through a load of plugins.

Ross: I came across this last week.

James: Popular plugins, and he’s going through the onboarding process and kind of analyzing it, which is really cool.

Ross: Have you got any nice onboarding processes in your plugins?

James: We have a few things. In Orderable we built out a stepped onboarding process, which when you land on the settings page, most of our plugins have a settings page of some kind. So with Orderable, you land on the settings page. If you haven’t got WooCommerce installed, it will install it for you. It then prompts you to configure your store. The kind of plan with Orderable was that someone who doesn’t know what WooCommerce is could come in, install it, and we would set up WooCommerce for them.

Ross: So you automate away those WooCommerce settings?

James: Yeah, exactly. So they’re filling in their shop address, their opening hours, and whether they offer delivery or pickup, that kind of stuff. And we’re configuring Orderable and WooCommerce based on those settings.

Ross: The users don’t get the WooCommerce onboarding screens. Then do you manage to hide that somehow?

James: No, we bypassed that.

Ross: Yeah. Cool.

James: We wanted to make it as straightforward as possible. There’s probably, I wouldn’t say it’s the ideal solution. I think we could expand on it quite a lot more, but the target audience was people who were very non-technical, like restaurant owners who just want to get their restaurant online and not have to pay, just the delivery fees all the time, so they could come in, just install Orderable and have it all set up and working. I think you’ve got to have a level of tech-savvy to use WordPress in general, I think.

Ross: I’m planning to do something similar with search and filters to have a splash page or onboarding wizard, because the plug-in works with, well, it has so many integrations, just presenting everybody with every integration and that kind of stuff via a complex setting page is too much. So I want to do a wizard where we say, “Hey, it looks like you’re using Elementor. Do you want to activate the Elementor features off the bat or the WooCommerce features off the bat.” And that’s the thing with our plugin is just we have to integrate with so many third party plugins because we’re essentially searching their data or their list of results or products. So I think search and filter is a great candidate for something like this just to hide 80% of the options from the users when they first use the plugin, because they just don’t need them.

James: That makes sense. Have you seen WP Fusion? They do something similar to that.

Ross: Yeah, I haven’t actually played with it, but I’ve had my eye on it. I think I’m going to need to be using it on my own site soon enough, but it looks very slick.

James: It’s a good plugin because they integrate with loads of things as well. They have a similar setup where if you’ve got WooCommerce installed, it will prompt you to enable that integration. Definitely, it makes sense to hide irrelevant integration options.

Ross: Yes. It can be overwhelming.

James: Until the point that they may be installed that plugin. Or theme, I guess. There’s probably some themes that you need to integrate with as well. But yeah, with my other product, Setary, that’s a SaaS product. So if you want to bulk edit your WooCommerce products, you sign up to the SaaS and you connect your store to our spreadsheet editor, which is really slick. But what you have to do is install a helper plugin, which we host on WordPress.org, and that helper plugin has zero settings. So what we did in that one was when someone activates it, you get redirected to what’s essentially like a landing page that explains the concept of Setary and prompts them to go over to the Setary website, set up an account. It’s a weird scenario because I’ve not had to explain that there’s no settings before.

Ross: Yeah, it’s quite unusual one.

James: Yeah, it’s a really cool plugin to be fair, because it extends the rest API of WooCommerce.

Ross: Is that how you’re importing the products?

James: Yeah, we’re not necessarily importing, we’re literally cooling the rest API and updating the data live in batches of 100 products.

Ross: Oh, okay. It’s more like syncing.

James: Yeah, exactly. So we’ve had to add, because by default, like the API in WooCommerce, you’ve got products is a separate API to product variations, and the data you receive for those products is different as well as the data you send. So we’ve expanded on top of their API and built our own, which then calls their APIs to actually do the updates. But we do things like as the calls come in, we’ll process the data that we are sending. So for categories, for example, we send a common separated list or a pipe separated list of categories, process it in our plugin to break it up and then find the matching category or create a new one if it doesn’t exist and things like that. So we do a lot of this processing stuff on top of what’s available by default.

Ross: I think I saw one of your guests where you managed to disable all the other plugins on the rest API endpoint. Can you only use it on a per site basis or can you roll that into a plugin?

James: So it’s an MU plugin, so it’s a must use plugin, which if anyone doesn’t know, is a separate folder to WP content/plugins. And the premise of an MU plugin is that they always run and they run before anything really happens on the WordPress site.

Ross: It’s one of the earliest hooks fired, isn’t it? The MU plugins.

James: I think it’s maybe even the second or something. It’s very early. But it’s before other plugins loads. So what we can do is we check whether the current URL or query parameter contains Setary in some way, and if it does, we’re basically filtering the WordPress active plug-ins option to say disable everything except WooCommerce and Setary. I had this one customer that was using Setary and it was super slow because they had so many plugins that were trying to fire and run at the same time. And this was the kind of case study that I used where it was taking I think, well, to save 120 products, it was taking one minute and eight seconds, and then with the MU plugin that I built active, it took eight seconds. And that time difference was crazy.

Ross: We have a kind of similar concern in that when we say do a search on a site and AJAX request, it goes off to, well, the rest API or wherever. We can never make the search faster than the site. That’s something we have to say to the customers often. It’s like your site takes one and a half seconds before time to first bite or whatever, and if you disable our plugin, what is it? There’s still 1.3, let’s say. So it’s like you guys need to, in a way, work on that part of your site in order to improve our search. I’d like a solution what you’ve done there to be possible where you could kind of say, “Hey, let’s disabled all this stuff for this search.” And then the search could be really quick. But my impression is obviously there’s an MU plugin. It’s not something that we can bake into our plugins, but it’d be really good if something like that existed.

James: I have good news for you.

Ross: You do have good news? Good.

James: Yeah. So in the free plugin, there’s a script that grabs the MU file. So we’ve got the plugin as a separate file in the free plugin. It grabs it and it moves it to the MU folder, if it doesn’t exist, and it checks a version number that we’ve added in that script as well.

Ross: Wow. Okay.

James: So if we update it in the future, it will replace it.

Ross: So that’s possible? So maybe it could be something that we add where we’d hide it behind a feature flag and say, “Hey, look, if you’re really looking to optimize your site, try this, enable this feature.” Maybe doesn’t work for everybody, I guess, depending on file permissions and things like that, on the host.

James: It seems pretty reliable to be fair. If you look at, I think it’s Migrate DB Pro, they have a similar file that they move into the MU plugins.

Ross: Cool. I’m going to put a note to investigate that.

James: I can send you the code, but it’s using the WP file system. So in theory it should be pretty reliable, and in most cases, those permissions should be good.

Ross: And if they’re not, the person’s already got a problem that they’re not aware of yet.

James: I mean, the only concern would be if they don’t have the plugin folder already, there may be a permission there that won’t allow you to create it, but it should be fine because the uploads folder is in the same directory and that uses the same logic to move files there.

Ross: I mean, the MU folder is a subfolder of plugins folder, right?

James: So it’s called MU-plugins, and it’s a subfolder of WP content.

Ross: Ah, is it not of the plugins? I thought it was.

James: No, it sits in line.

Ross: Okay. Because I was going to say, obviously the plugins and theme folders will be writeable. They have to be.

James: And it works differently as well. You don’t add folders. You can do it on a folder basis, but you would usually just add a PHP file and it would automatically run it.

Ross: Yeah, you just drop that in. Yeah. It’s like the Hello Dolly plugin, where it’s just a file.

James: There’s no headers to that file either, you would do in a normal WordPress plugin. So it just takes the contents of that file and it just runs them. But if you are building sites for clients and you want to use MU plugins, a lot of the time they’ll have one file that then looks inside the folders and loads.

Ross: The sub folder with the same name. Yeah, that’s right. I’ve seen that.

James: But yeah, that’s the premise of it. So anyone installing Setary now is going to get that script and they’re going to get the benefits of super fast product updates, and it’s ridiculously fast. Even fetching the data is so quick. But like you say, it does depend on how fast their server is as well. There could be bottleneck there as well.

Ross: But I think it might be worth just touching on what started this chat, I think, because we were talking about quick briefly on Twitter about AI. I mean, I know everybody’s talking about it, so I don’t wanted to go too much into that. But you mentioned you’re using something to do with AI and Setary, is that right?

James: Yeah, I think there’s a rush at the moment to get AI into every product. And there’s a lot of clones of like ChatGPT that mildly enhance it or modify it in some way.

Ross: Or even make it worse.

James: Or make it worse and charge you for it. So I’ve kind of struggled with thinking, can I use AI? And if so, am I doing it as a gimmick or will it actually be useful? So for Setary, I think there was a few paths that we could take to integrate AI, and I think there’s another one that I’ll mention in a minute. But the first one that I thought would be useful is… So Setary is like a spreadsheet editor, so all of your products load in a spreadsheet, where each column is a data point for that product. So you’ve got product name, product price, product description, product short description, that kind of stuff. So I thought the first thing that would be useful for people with regards to AI is to take the product descriptions that they’ve already got and enhance them with AI. Not everyone’s like a content writer or knows how to write content that sells.

Ross: AI does.

James: I struggle with that. But yeah, AI is great at that. If you tell it to be.

Ross: Yeah, you tell it’s an expert at writing great marketing materials.

James: Yeah, exactly. And I think that the important thing is to, when you get this content back, to not take it as, okay, that’s the final version of the content. You’ve got to actually read that it makes sense and take it as a bit of an inspiration to what your content could be. So yeah, I added this button to the description fields and the short description fields that when you click it, it generates you three different options for that description, enhanced to make it more markety, I guess, marketing copy. And it does a really good job. So you can choose one of those options and it will stage it as a change, which you can then go in and edit it if you want. And then, yeah, when you click save, it will push all of those lovely new AI descriptions to your products.

Ross: Yeah, I’ve also been trying to look into the AI stuff, but I think AI and search, well, Bing have tried to do it, and I not particularly interested in using AI sitting alongside my search right now as it is today. I was thinking how we could integrate it within the next search and filter, but I don’t really see any options. I want to jump on the bandwagon a bit, but I don’t see many options. I think the chap was building WP Fusion, I forget his name, he was doing some experiments with querying WooCommerce products, using natural language essentially like, “Hey, I want this size, this color, and this size, what have you got?” Kind of thing. But I still think people don’t really want to search that way though.

James: That was based on a conversation I had with him actually. We’re looking into building a product, which is essentially a shopping assistant, so it would take your natural language queries and give you suggestions for which products match those, the query that you have. And I guess the difference there is that you’re not explicitly checking off options to filter existing products, you’re doing it in a much more natural tone of voice, I guess.

Ross: Yeah. I mean, I can totally see that there’s definitely some potential there. I’m wondering what the kind of next level is that makes it super accessible, or maybe it’s just familiarity with things like that, using websites in that way. Maybe that’s the bridge that makes that seem kind of awkward to use.

James: I think there’s potentially ways for you to utilize AI that aren’t customer facing as such.

Ross: Analyzing searches and kind of analytics.

James: Even backend stuff, but for the customer, knowing what they’ve filtered before or what products they’re looking at and suggesting filtered results for them.

Ross: Yeah. Yeah, that’s a good idea actually.

James: Like, “Hey, I noticed you’re looking for men’s shoes.”

Ross: Frequently.

James: “All the time. Have a look at this query.” Something like that. Or analyzing search data. Like reporting on what people are looking for. For a store owner is massive.

Ross: That’s the kind of stuff I’ve been thinking about where it’s seems like something I might be able to action. It’s kind of an analytics integrations, interpreting data, basically.

James: Yeah. I think that would actually be very straightforward. If you’ve already log what people are filtering and what people are searching, analyzing that data with AI is-

Ross: It’s kind of this main use case.

James: Yeah, that’s what it does. So yeah, I definitely think that’d be a good way to go. Awesome. Well, people listening, if you want to catch up on Twitter, I’m James C. Kemp, my websites iconicwp.com, orderable.com and setary.com.

Ross: And if you want to catch with me, I have an awkward handle on Twitter, which is rmors_, and my website is searchandfilter.com. Thanks.

James: Awesome. See you soon.

Ross: See you soon. Take care.