[00:00:00] Matt Cromwell: Hey

[00:00:11] everyone, welcome. This is WP Product Talk, the place where we talk about WordPress products, the business of it the wins, the losses, the lessons learned. All the fun stuff. We do this every single week and it's normally me and my co host Katie Keith. She's out on vacation right now. But she's gonna be back next week.

[00:00:30] And this week I'm excited to bring on two friends of mine that I've known for quite a while that are pretty awesome folks. And we're going to be talking about the subject of why you might want to consider refactoring your WordPress product. Here they are, Devin Walker and Kevin Stover.

[00:00:48] Hey guys, welcome. Hello.

[00:00:50] Kevin Stover: Hey, how are you

[00:00:51] Matt Cromwell: doing? Doing good. Kevin, tell the world a little bit about yourself.

[00:00:55] Kevin Stover: I realized I look a lot younger in that picture that you put on the thumbnail. I appreciate that and I feel bad looking at it now. No I'm Kevin Stover. I'm one of the co founders of a company called Saturday Drive, which is the company behind the Ninja Forms WordPress forum plugin.

[00:01:13] And a few years ago, we had a very major rebuild where we refactored all the things, and refactor is probably a bad word for it even, because we just started from scratch. And built a new plugin. So I think that's why I'm here.

[00:01:27] Matt Cromwell: Exactly. Exactly why. Cause we talked about that in the past and I was like, Oh my gosh, this is a great story.

[00:01:33] I don't know if you feel like it's a great story, but I love it. It is a great story

[00:01:37] Kevin Stover: now. It's a great story on this end of it. And now that we're several years past the rebuild, Yeah, it's good. Previously, maybe not.

[00:01:47] Matt Cromwell: Yeah. Devin, introduce yourself.

[00:01:50] Devin Walker: Hey Devin Walker in San Diego, California. Co founder of GiveWP with Matt Cromwell right here.

[00:01:58] And been in WordPress probably 10 plus years now and have refactored. We refactored GiveWP in version 2. 0 which was an interesting experience. I think with refactors, sometimes they go a little longer than you anticipate. That might be one of the things we chat about here today, but other than that also have Experience with rebranding, which is some form of refactor as well.

[00:02:26] And I've. Written quite a bit of code that needs to be refactored. So yeah, I'm excited to be here today and looking forward to the convo.

[00:02:35] Matt Cromwell: And I'm Matt Cromwell, also co founder at GiveWP and now doing customer experience and marketing at StellarWP. Where we get to break a whole bunch of stuff.

[00:02:46] They keep asking us to do more and more things like iThemes and SolidWP, which is super fun lately. And ideally we're, breaking the right eggs. Yeah,

[00:02:56] Kevin Stover: Can y'all talk for for a minute about the change from iThemes to SolidWP? Cause I find that's interesting.

[00:03:02] Matt Cromwell: Yeah, one thing about it is that iThemes is like one of the oldest brands in WordPress.

[00:03:07] And I feel like I really have to treat it with a ton of respect because it is really unique in the WordPress space. And so going into this whole thing, I was like, wow, we really Really have something unique here and we want to do it right and do it justice. So it's been interesting and fun.

[00:03:22] And part of the whole experience we decided on together was that we want to talk about this whole experience publicly out loud. So we're rebuilding and refactoring in public right now. So Devin, what's your take?

[00:03:36] Devin Walker: Yeah, I'd say we're taking a step back and looking all at all the products and how they could work better together and be a more unified experience.

[00:03:43] And that's a different approach than this brand has taken ever in the past. I think if you look across the products right now, a lot of 'em have their own individual. interfaces and interactivities that don't coincide with one another, and we really wanted to bring it together more a lot more.

[00:04:03] And so that requires a whole lot of UI, UX redesign, and then of course a big development refactor. Some of this code's been written 12 plus years ago that we're looking into now. So we're talking about things like dropping PHP 5. x compatibility in our backup solution, which is a sensitive topic because typically with backups, you want to support as much as you want, but we're limited now because when you support that far back, it's also a security issue, which we do have a security plugin as well.

[00:04:38] So interesting interplays that we have to take in consideration with this rebrand, but if you get Before and after with some of our interfaces and actually use them now. It's really impressive where we've gone in just a short amount of time.

[00:04:53] Matt Cromwell: Yeah. Cool. Cool. So yeah subject today is refactoring.

[00:04:58] Why you may or may not want to do it. One thing we thought would be important upfront is to talk about what exactly refactoring is. I want to give a quick shout out, everyone. If you are watching on YouTube right now, you can hit that chat sidebar and you can ask questions and we will put them up on the screen and answer your question live.

[00:05:16] Bring them on. Or if you're on Twitter watching us live right now, then use the hashtag WP Product Talk and I'll be paying attention and try to bring it into the show. Yeah. First off What is refactoring? There's lots of different types of refactoring. And, or, there's lots of different ways that people use the word refactoring.

[00:05:33] What's your take, Kevin? What what are some different types of ways to approach a refactor?

[00:05:39] Kevin Stover: Yeah I think it depends if you're talking about code, right? You're talking about a business, right? Identity. You could even like refactor business model, right? Like we're going to go back and rebuild our whole business model from the ground up, right?

[00:05:51] Like how we collect money, what we pay or what customers pay for, whatever. I think at the heart of it for me, when I think about it in this context of a business or a product, it is, we're going to take a We're going to take a look at the fundamental pieces of the business, or the fundamental pieces of our code, or our product, right?

[00:06:12] It's stepping back and taking a hard look and making hard decisions about, is this the best thing for the customer, for the user? And if it's not, if it's not, are we at the point where we have to make very difficult decisions about how to proceed? Does that make sense?

[00:06:30] Matt Cromwell: So the

[00:06:30] Kevin Stover: idea is beyond just beyond the kind of what features do their customers want.

[00:06:36] In my mind, it's stepping back and thinking about fundamentals in a way that, Honestly, we all should on a more regular basis, right? I think we put the foundation in place of the fundamentals and then build on top of that. And sometimes you need to go back and look at the fundamentals again and think about those again.

[00:06:52] Does that make sense?

[00:06:53] Matt Cromwell: Yep. Yep. Yep. I think maybe from a really tactical perspective, I might shout out a couple of different things that I think Kevin is alluding to. For example, I think presenting your customer with a whole new visual experience of the product. I think that's a bit of a refactor, which is essentially a lot of what we're doing with SolidWP.

[00:07:15] When from one day to the next, you're going to have this one experience, you're going to upgrade, and all of a sudden, Like your whole visual experience of the product is going to feel significantly different. That's, I think one type there's also like the type where basically there's not a huge fundamental visual experience that's different, but everything underneath is different.

[00:07:36] Those are more, I think a little bit more common in the WordPress space. Especially when we talk about like breaking backwards compatibility and things like that. Sometimes everyone, small folks have to do it. Or they try to avoid doing it. I don't want to. Spoiler alert too much on Kevin's story, but but that one's a significant one.

[00:07:54] I think one other part that you highlighted there, Kevin, that's interesting to me is basically you were really highlighting how it's the, how the business serves the customer. Is there another type that you're thinking of specifically on that front?

[00:08:05] Kevin Stover: For, for business and serving customers, you mean?

[00:08:08] Matt Cromwell: Yeah. You're like, you said essentially If it's, if the business is not serving the customer the way we want to then there has to be a change. Yeah.

[00:08:16] Kevin Stover: Yeah. So I guess it's, if you were in a situation where you realized that a majority of your customers weren't using X feature.

[00:08:25] And you're spending a lot of time working on X feature, but it's not actually being utilized, right? And could you put that energy somewhere else and serve your customers better somewhere else? Or, our customers really come to us for this feature, but man, we get a hundred thousand support requests for it, because it doesn't do what they expect, or the UX is terrible, right?

[00:08:47] Or it's buggy. I think of all those as potentially sparking refactors but mainly because they're not serving the customer well. This is a little bit of a spoiler too, but I think a bad reason to refactor is that you don't like the way the code looks.

[00:09:04] Matt Cromwell: Yeah, that's

[00:09:06] Kevin Stover: good. I'll leave that there.

[00:09:07] I'll leave that there and we can circle back to it.

[00:09:09] Matt Cromwell: Yeah, that's it. We'll definitely need to highlight some bad reasons and good reasons. That's a good one. Cool. Yeah,

[00:09:15] Devin Walker: I've seen developers get into that refactor perfection loop before. We'll touch on that again here.

[00:09:24] Matt Cromwell: Yeah, absolutely. So first topic as always every week is essentially, why does this subject matter for product owners at all?

[00:09:33] Like, why should anybody even be, like, ideally, we don't have to deal with this question at all, right? Ideally, we write perfect code that works for forever. But in one way or another, every, budding, growing product at one point or another, it's going to have to wrestle with this question of why is this so important?

[00:09:51] Devin, do you want to jump into that?

[00:09:53] Devin Walker: Yeah, I think there's multiple ways to answer this question. I think the first I think the first thing that comes to mind is old code gets slow and eventually starts breaking down and showing its age. And you have to always. Go back and make sure that your house is tidy, right?

[00:10:13] Like you can't just clean your house once every 10 years and expect no dust to settle And that's exactly what happens in projects The third or the second thing that comes to mind is refactor, move slow to move fast, like you have to go back and refactor in order to soup up that engine, like for instance, if you built your platform, your plugins, SAS, whatever it is to be Very closed off and you wanted to open it up to third party APIs or to third party developers. You'd likely have to go refactor different areas of your code to, to work and interact in that way.

[00:10:52] So if you wanted to open it up and move faster down the line, you have to go back and do that work now in order to do that. And that's one of the, it's a painful business decision to have to do that. Cause you do have to spin your wheels for a while. But if you make the right decisions to refactor, it can really lead to.

[00:11:11] It's really good things for your business down the line. So I think those are two things that immediately come to my mind on why it's important.

[00:11:19] Matt Cromwell: Yeah, absolutely. That's a good one. Kevin, what's your take?

[00:11:23] Kevin Stover: Yeah, I think that's a great point that Devin makes about how the code itself. Over time gets stale, right?

[00:11:30] I'd also say that things move around your code, especially if you're working with WordPress, right? PHP versions get released, as Devin was mentioning earlier, the struggles of supporting PHP 5X, right? PHP changes and you're going to have to change your code. to match that. And sometimes that's going to be like small changes.

[00:11:53] And sometimes that's going to be major deals, right? Major refactors. It's not just the code that you write that becomes unstable. It is the world around it changes. The ecosystem changes, right? Like everything around WordPress changes. WordPress deprecates functions, removes functions, right?

[00:12:11] Adds new stuff. You have to be able to keep up with that. And sometimes it's not as simple as adding a line of code. Sometimes it means refactoring how your code actually handles stuff on a fundamental level.

[00:12:24] Matt Cromwell: Good stuff. I think for me another one that Devin highlighted was go slow in order to go fast.

[00:12:30] I think that one's in many ways, the one that, that for me, I want everybody to be thinking about is that at one stage or another, your product is just going to get in the way of your progress. That's how I see it. There's going to be a stage at which you're like, I really want to do X, Y, and Z, but I know in order to do those things, the product itself has to change fundamentally.

[00:12:52] Or else I'm just gonna be piling, new code on top of bad code and it's just gonna get kind of Frankenstein y. And I feel like WordPress products end up like that often because nobody wants to rip off the band aid of refactoring. So you end up just keep on patching new things on this old code base until it all feels a little bit like Frankenstein y, like I said.

[00:13:14] That's the big one in my mind is like, if you want to do those big future, new, big things, sometimes you got the only way to do it is to set up a new foundation to build on, especially even Kevin, what you mentioned is like the environment changes itself. Now we have Gutenberg. Everybody was doing shortcodes and widgets and whatnot in the past.

[00:13:32] And now it's like, why would you ever build a shortcode? But there's still reasons why you would, but everyone has to make sure to do blocks.

[00:13:39] Devin Walker: Yeah, now we have block backward compatibility to have to contend with within our refactors, right? That's fun.

[00:13:46] Matt Cromwell: Yeah, exactly. And yeah, I've heard lots of developers complain about how Gutenberg itself isn't perfectly backwards compatible.

[00:13:55] So maintaining that compatibility is hard.

[00:13:59] The next segment is story time, and I feel like we all have some more stories to share. So this is, I want to make sure we have enough time for this one. Essentially we want to share our personal experiences with this. And Devon and I, of course, have very different experiences. Similar experiences from different perspectives on the same products.

[00:14:15] We thought Devin might talk a little bit about SolidWP. I'll talk a little bit about what we've been doing with GiveWP. And Kevin, of course, gets to talk about NinjaForms. And I want to lead with Kevin if that's all right. Tell us, Kevin, why did you jump into refactoring NinjaForms? And what went well and what are like some lessons learned?

[00:14:35] Kevin Stover: Yeah I'll start off by saying that it wasn't really a refactor. Because we used very little code that we had written for the previous version of NinjaForce. It was almost completely rebuilt from the ground up like blank canvas and everything. The reason we did it

[00:14:52] Matt Cromwell: That's actually a good clarification because there are some folks who decide the team to do that, but they even make it a whole nother product.

[00:15:01] And it's oh, you want this product. We're not doing this anymore. Go over here to get the new thing. But you didn't do are reasons

[00:15:08] Kevin Stover: to do that. There are reasons to do that, but we didn't do that. So Ninja Forms 2, the previous version of Ninja Forms, is something that I wrote. by myself when I was also doing a master's degree in ancient history.

[00:15:22] And so it was something that I wrote as my second full time job that I was just cowboy coding essentially, because I didn't know anything about testing, so I didn't build any testing in, right? This was back when I had first started developing really. And so we realized that as a foundation for where we wanted to go, and you made this point earlier, Matt.

[00:15:44] It didn't provide us the proper foundation for where we wanted to go. And where we wanted to go was the ability to build new integrations quickly and easily, the ability for it to be to have hooks and filters, because there was very little extensibility built into version two. And we wanted to redesign the UI.

[00:16:06] Like we wanted a whole new, UI, because we had ripped off the old menu UI. I don't know if you're old enough in WordPress to remember when the navigation menu builder was new, but that's when we started building Ninja Forms, and so we just ripped that off, just verbatim. And we realized that we needed a new UI as well.

[00:16:25] And all of that together was enough for us to say, yeah, it probably makes sense to start over, rather than trying to build all of this on top of two you're talking about building it on a bad foundation, so we decided it's better to just start over. And build the stuff from scratch with an end goal in mind, right?

[00:16:48] The end goal being having it be more extensible, easier to build from, and a new UI. A new UI that we had professionally designed. So we went to a UX company, design company, and they designed the user interface for NinjaForms, and then we built it out to that. to that spec, if that makes sense. Really, the driving decision for us was we wanted to go somewhere and we knew that the code base we had couldn't get us there.

[00:17:15] It couldn't get us to the, to where we wanted to go. That was really a combination of the environment changing, right? Because the UI that got us to that point wasn't gonna take us to the next level. If we wanted to be, if we wanted to move from a two person You know, supporting product to a product that supports a team that we have now.

[00:17:39] We knew that they would have to move from the parochial UI we had to a better UI. Honestly, like that's at the heart of it. That was the driving factor. If the UI wasn't going to change, we might not have gone so Extreme, but because the whole UI changed, we decided to make that jump.

[00:17:59] Matt Cromwell: Yep, absolutely. So what went well?

[00:18:04] Kevin Stover: What went well was we had some great team members. One of our engineers, Kyle, works with y'all at GiveWP now. He was instrumental in helping to make sure that got finished. And he and I had a lot of late nights where we were just hacking things together.

[00:18:22] Neither of us had kids at that point. And so that was a lot easier to a lot easier to get away with. So he and I did that. So I would say the team went well, if that makes sense. I know that, that does it. That's an answer to your question, but not about the product, if that makes sense.

[00:18:37] Matt Cromwell: No, yeah, it's still part of the experience, because those folks are gonna remember this for forever.

[00:18:43] Yeah, that's the most

[00:18:43] Devin Walker: important thing to do well. If the team doesn't do well, Refactor's probably not doing too well. Yeah, Refactor's never gonna get done. Yeah.

[00:18:52] Kevin Stover: It's true. So we had all the team I mentioned Kyle cause he's with y'all now, but the whole team was very good at testing and making sure that everything was working as well as we could write, making sure that all this stuff was working as well as it could.

[00:19:06] So I would say the. What came out of it, the end product, what worked well is that our user interface turned out really well. And we were very happy with the way that it turned out and we had at the time a very I think cutting edge way of doing things like columns because you didn't You just drag the item into the column you want and you're done Like if you want to make more columns you drag it make a new column And there wasn't anybody else doing that kind of stuff.

[00:19:34] So I think the UI Bye And the way that the customers and users interact with the forms was a major upgrade from where we were before. So that was a big, that was a big win. And then the extensibility and being able, because we were able then to pump out a lot of new add ons much more quickly because the action system and all the systems that we had in place are now hookable where they weren't before.

[00:19:58] Matt Cromwell: Yep, and what kind of like lessons learned do you have from that experience? Oh,

[00:20:05] Kevin Stover: I don't know that we have enough time. I'll give a couple and then I'll pass the mic so that I'm not bogarting the whole thing. One is, Whenever you do a refactor of anything, remember you're trading known problems for unknown problems.

[00:20:22] You're trading known bugs, known issues, for things that are totally new, right? For our support people, or any support people who are used to your product, when you refactor, you're basically resetting their knowledge. Like you're resetting the knowledge of the support people, you're resetting the knowledge of developers, right?

[00:20:45] You release this whole, we, in our case, we released this whole new codebase that had not been battle tested, and it was replacing something that had been in existence and used for years. So even though 2. 0 we thought was ugly, It had lots of warts. We knew what the warts were and we knew what the shortcomings were, right?

[00:21:05] When we released the Ninja Forms 3, it was brand new and it went to everybody. We went from over a million installs using 2 to now over a million installs using Ninja Forms 3 and that switch happening we tried to gate it, like we tried to make that rollout as slow as we could but then eventually we just had to flip the switch and when we did, we found a whole bunch of issues that we hadn't found because no matter how much testing you do, you can't replicate every server, every plugin configure it, like you just can't, like you can't replicate that.

[00:21:42] I think one of the major things that I learned is to set your expectations properly. When you do a refactor, especially if it's a big one, like the thing that we did set the expectations to say, we don't know what's broken yet. And we're going to spend, we're going to spend months discovering what's broken and what needs to be fixed and setting that in your brain and making that your expectation, right?

[00:22:06] The expectation should not be. To, our old thing was crap. This new thing is amazing.

[00:22:12] Matt Cromwell: That's

[00:22:13] Kevin Stover: a bad expectation. That's a way to set yourself up for failure. Because this new thing is going to have a bunch of bugs and problems with it, and you're going to have to solve those. And if you're thinking about it as the savior, then you could be very disappointed and sad and depressed about the new thing you launched.

[00:22:30] But it makes sense, right? You're replacing something that's battle tested with something that's not.

[00:22:35] Matt Cromwell: Yeah, absolutely. No, that's really good point. Good call out for sure. Thanks so much for that story, Kevin. I really think that hearing these types of experiences from folks who have done it is just really super valuable.

[00:22:47] I'm hoping anybody who's on the cusp of a big refactor is listening in right now. Devin, I'd love to hear from you a little bit about what we're doing with SolidWP. Like how would you describe this refactor that we're doing? We're basically talking about three products and a brand and a website.

[00:23:05] How would you describe it? And how did you go about like thinking through the process of refactoring all this stuff?

[00:23:13] Devin Walker: Yeah I would say I'd if I were to coin it I'd say a strategic refactor, right? We are pretty strict on the timeline of when we want to get the rebrand done, which means we can't do all the refactoring that we'd wish we could do, right?

[00:23:32] I think the majority of the refactoring that we're spending time in is and mainly our Backup Buddy Plugin, which we're renaming to Solid Backups, because that has been not getting as much development love over the years as security has. Security is actually It has the most amount of

[00:23:53] Matt Cromwell: dust.

[00:23:53] Devin Walker: Huh?

[00:23:54] Matt Cromwell: It has the most amount of dust

[00:23:55] Devin Walker: on

[00:23:56] Matt Cromwell: it.

[00:23:56] Devin Walker: So much dust. Yes. So for instance, we had for the backups, you can have offsite destinations, right? It could be your own server. You could email it to yourself. You could have it on Dropbox or a dozen other different third party services. Over the last 10 years, we've added many of these services and deprecated quite a few.

[00:24:16] So there were Several different versions of Dropbox's SDK's and API's compatible in there. Amazon, there was even like Rackspace Cloud Files, which I don't think a single one of our customers uses. One of the refactors we chose to, I was like, just get rid of everything. That's not. The current version of the core, main platforms, like we're talking Google Drive, Amazon S3, and Dropbox.

[00:24:44] I think those are the three core. We might have one or two others, of course FTP or SFTP and these other ones. But not only the UI is getting much more. Digestible, because you can choose from a main set of options. It's also making the development experience much much simpler. And those SDKs added so much bloat to the plugin too.

[00:25:06] We're talking massive SDKs that we were pulling in. So it's making it a lot more lightweight as well.

[00:25:12] Matt Cromwell: Just

[00:25:13] Devin Walker: a simple change. So that's a big thing to hack off with, it only took us a week or two to get rid of those. And it makes testing a whole lot easier now. So moving forward, we have a core set of offsite integrations to test with.

[00:25:26] So that's one good example of where I think we were really strategic on where we refactor. We do have a lot of old methods and code for backing up files. And a lot of that is not performance. For instance, our incremental backup. Service that we call Stash Live. We are, we're not renaming that.

[00:25:47] We're rebranding it a little bit, but what we're going to do is also modernize it and ensure that the performance of it is more reliable because to be honest, that thing's. If you have it on the right server configs, it'll work well for you. But if you tweak certain things not to the code's liking right now, you're going to have a little bit of a frustrating time with it.

[00:26:10] So we're going to try to make that as reliable across. the main server environments that we choose to support, which is, you've got to be running at least PHP 7. 2 plus. I'm probably moving forward, maybe 7. 1.

[00:26:24] Other than that we have a Laravel platform that's running our Sync Sass, which is our website maintenance and update.

[00:26:32] Management platform. And that's actually coded pretty decently. It's running Laravel 8. Of course we could be like let's upgrade to Laravel 10. Upgrading Laravel is not as easy as WordPress. You don't just click the button, right? So that's a refactor in itself. So we're going to be fine on, on Laravel 10.

[00:26:49] It's using React. What's that? Laravel 8, sorry. Yeah. I would love to refactor the CSS to use either Tailwind or a similar type of framework. I saw Uno CSS came out, but long anyways, we need to refactor the UI so it looks much more modern. That platform looks a little dated now, and we paid an agency like four years ago to do a pass on it, and they did an okay job.

[00:27:16] But it's not nearly where we want it. So refactoring the CSS. And I think that's the big one we're doing there.

[00:27:23] Matt Cromwell: Yeah. I think that, that example you gave about Laravel updating is similar to what Kevin was saying earlier about don't just refactor just because you don't like the code like we totally could just, Be like, let's do Laravel 10.

[00:27:36] But really, is that really going to benefit anybody at the end of the day? Probably not today, at least at one point, Laravel 8 is going to be more or less deprecated, but and we'll have to move on, but yeah.

[00:27:47] Kevin Stover: Yeah. I think that what what most people have a difficulty with there is that there's always more to do than there is time to do it.

[00:27:55] There's always more to do. And you have to we have to pick and choose what are the things we're going to do, cause there's always more to do.

[00:28:02] Matt Cromwell: Yeah, absolutely. And sometimes it's let's get the big strategic bulk things done now and plan to do these other iterative things later.

[00:28:10] It doesn't all have to be done all at one foul swoop. Yeah, Devin, it's been really really amazing watching you and the dev team whip these products into shape lately. And if anybody's paying attention Devin and I are doing a video series on the SolidWP channel all about this type of stuff.

[00:28:27] We're trying to, Build in public, rebuild in public and talking about these things publicly. We have one video that I just saw in Slack a little bit ago. I got the first draft of, yep. So hoping we'll get that published probably between today and tomorrow.

[00:28:41] Devin Walker: One thing Matt, I know you're moving to GiveWP, which is great.

[00:28:44] And I hope we can talk about data migrations in regards to refactors. Cause especially in WordPress, that is a fun, fun topic.

[00:28:53] Matt Cromwell: Fun, fun in what you mean by not fun yeah, so a little bit about GiveWP. We did a couple of different things along the way. But if anybody's paying attention to GiveWP world lately, we are doing this big next gen visual donation form builder that's going to be built on Gutenberg.

[00:29:10] And we did some Fashion that after the way the Gutenberg itself was rolled out and which is essentially that we're building a feature plugin that folks can install and test out themselves. And it has a big prominent tell us what you think, feedback. tool inside of it.

[00:29:24] So we'll be getting live feedback from folks for all that kind of thing. And then once we get enough feedback and we feel like it has reached stability enough, it's going to go into, we're going to give core, which we're going to then call that GiveWP 3. 0. But what I actually want to talk about is actually how we got to the point at which we could do the visual donation form builder because that was a bit more of a code refactor.

[00:29:48] But it was something that our lead developer, Jason Adams, schemed up, which was almost like a refactor in private, nobody knew that GiveWP was being refactored, but it was like for over about a year and a half we were suddenly silently building new APIs into GiveWP underneath in the code and shipping those APIs sometimes and not even using them yet in order to use them later and to slowly get the old functions deprecated over time.

[00:30:17] And this was Jason's whole approach to trying to slowly bring our whole user base up to a new Codebase without introducing a whole bunch of disruption. Now I was a little skeptical because I felt like one thing it does is like spreads out the kind of introducing of new code against old code over a longer period of time and over a course of a lot more releases but truthfully overall, I feel like it actually was helpful and beneficial.

[00:30:46] And we did all of that in order to be able to have the correct APIs in place so that we could do this Gutenberg powered visual donation form builder. It, none of this would have been possible in with with the old code base the old way that we were building our forms at all.

[00:31:02] In some ways, this was a refactor in private. It was a behind the scenes underneath where nobody was really seeing it, it was definitely in the changelogs and things like that. So if you are, a real serious developer and inspecting people's changelogs, you can go back and check it out.

[00:31:17] And see how that's reflected in the give code, in all the change logs. But but then, so that's two different refactors that we did is that private one. And now coming out finally with this brand new form builder. And instead of being like, here's one day where you are doing forms the old way and next day, now it's a whole brand new, crazy different way we're introducing that feature plugin approach so that folks can try it out.

[00:31:43] They don't have to use it. They can just test it, ship a a form and test it out somewhere. Ah, I don't like it. Trash it, turn it off, keep using your old form. That's all fine. It'll work just fine. But over time, as it gets better and stronger, eventually it's going to be the default way that we do the forms going forward.

[00:32:03] So two different approaches to refactoring that we've been doing without really telling anybody about it. Devin, did I hit all the right points? I'm, I'm, I was a developer forever ago. I haven't been a developer quite a while, but I,

[00:32:16] Devin Walker: I think you're right. I think. Yeah, I've seen some of those APIs go in core over the years And okay, when are we going to start using these was a bit tough from a stakeholder standpoint.

[00:32:27] We all wish we got there faster, we also had to continue building and moving forward our 2. X version while we're doing that. So I think I think you hit most of the points for sure. Yeah.

[00:32:40] Matt Cromwell: Yeah. Cool. You want to, we have one last segment. Do you want to touch anything on data migrations?

[00:32:47] Devin Walker: Yeah, I would say just the big refactoring. I remember when we were doing, going through the 1. x to 2. 0 GiveWP refactor, that's when we sat down with Ninja Forms and really talked with Kevin and team quite a bit about what landmines should we watch out for? Where can we really make mistakes?

[00:33:10] And one thing I think we did really was be careful about testing and things like that. But one, we didn't anticipate how difficult it was to migrate data in WordPress. And we thought we had the best data migrator that would update you over time and you could leave the page and come back and it would be compatible about it.

[00:33:32] MySQL version 5 to 8 and as much testing as we did, it took us a long time to get out of the woods on database migration. Our support team was not happy with our development team for quite some time because the migrator would just stall out in certain environments. You could go in and click a reset button after we refactored that to have a reset button.

[00:33:59] And then eventually the reset button wouldn't reset. So we had to refactor the reset button. It just went on and on until finally I think. We had to refactor what we, it was like five different refactors to get to the point where we're at now, which I think is a semi stable database migration pathway.

[00:34:17] We were building,

[00:34:19] Matt Cromwell: yeah, we were building like tests into the live code for people to be able to like, figure out. We were working on the migration and figuring out whether or not something was broken in the migration or not. It was all kinds of stuff. Yeah. So our log tables now are, yeah, our log tables now are like gorgeous and beautiful because we needed them so badly to figure out if something was wrong.

[00:34:39] Yeah,

[00:34:40] Devin Walker: logging. That's a good point too. We built in logging based on that, because for support that was be actionable, but for those looking to do data migrations in WordPress, take a hard look at the action scheduler, blur library, I think from WooCommerce, and then take a look about at how we do it, but we took a lot of notes from WooCommerce and how they did it.

[00:35:02] Matt Cromwell: That's a good point. I'm glad you circled back to that.

[00:35:06] Kevin Stover: Yeah. I think WordPress in particular makes that difficult, right? Like the fact that we're building products for a distributed platform rather than a SaaS, right? If we were running completely SaaS companies and all we had was our stack, then refactoring is a lot easier, right?

[00:35:23] Because your surface area for. Breakage is a lot lower and you know about the breakage. The problem to me with data migrations is we don't see it. I don't see it. I don't see the person upgrading their submissions table.

[00:35:39] ,

[00:35:39] right? That happens away from me whenever the user wants it to happen, right?

[00:35:46] And so it's not only that you have to migrate the data, but your code has to be able to handle both data types. So for example, what if someone upgrades to the new version of your product? Someone goes to the front end of your website and fills out a form while that is being updated, what happens?

[00:36:03] Or you crash in the middle of your update and what happens then, right? So it's what Devin was saying. It's those catching those, figuring out a way to catch those edge cases. But that's what's so scary about it is that it's distributed and we don't get to see it, right? Like we don't get to see it.

[00:36:21] You don't get to visually inspect their GiveWP submissions to make sure that all the data transferred correctly.

[00:36:28] Because for us one of the things, surprising things for us was we prompted people when we upgraded their data, we prompted users to say, check your data, check your stuff to make sure that it trans that it transferred properly or upgraded properly.

[00:36:43] And if it didn't, click this button and it will revert, and then submit a support request and we'll figure it out. I can't tell you the number of people, Said, yeah, it looks good. And then came to support and said, Hey, my data's all messed up. And this is like months after they have done the, after they had done the upgrade.

[00:37:04] So now we're having to figure out, okay, here's your new data. We don't want to lose that, but here's the point at which it's stuck, so yeah, I agree with you, Devin, the distributed environment and the fact that it's unattended, that is. That's huge.

[00:37:20] Devin Walker: Yeah. How nice would it be to just put all our sites in maintenance mode, flip a switch, like a SAS, and to be able to control everything. Is this the SAS world? Like you can simulate everything. You can test everything. Cause you control it all. Like you

[00:37:35] Kevin Stover: control the whole stack. You can roll out. And we've got certain features to certain users, right? So you can say, Hey, we're going to roll this out to 10 percent of our user base, 20 percent of our whatever, but in a distributed environment, that's really hard.

[00:37:47] Matt Cromwell: Yep. Yep. That's a can of worms. Cause I know that you experimented with that specific thing too. We did a last segment. If you are out there listening in and being like, oh man, these guys are telling me I should not refactor ever. We have some best advice for sure. We've been there. We've done that.

[00:38:05] We've broken stuff. We had fun, according to Devin with data migrations. But but we have some advice too. If you are thinking about doing a data, a refactor in one form or another. What are you going to tell somebody? They come up to you at a WordCamp, you're at Orlando, you're at Kansas City, wherever Kevin somebody's I'm going to do a refactor.

[00:38:26] What do you tell them?

[00:38:28] Kevin Stover: I think the first question is the same question I ask for almost everything. Why? Why? Articulate to me why you want to refactor and lay out the benefits and then think honestly about the possible drawbacks, right? Because I think sometimes in software development, it's easy just to jump in and start writing or to jump in and start refactoring and not to step back and say, okay, why am I doing this?

[00:38:57] Like, why? Why? Because if you know the why, then you can set goals. And if you can set goals, then you can keep the refactor from growing into a monster. Because our refactor grew into a monster because we didn't set goals. We didn't set the appropriate goals that said, this is the goal that we want for our refactor, and therefore we can put dates on it, we can put metrics on it, right?

[00:39:19] We can measure it. If you don't know why, how can you measure it? If I'm refactoring because I don't like the code anymore, how do I measure when I'm done? When I like the code? You know what I mean? The why. So to me, the first question is to seriously think about why. And if you can't, if you can't succinctly articulate why, then think about it.

[00:39:40] Maybe it's not time to refactor.

[00:39:43] Matt Cromwell: Excellent. Really good one. The tandem on that a little bit, I think like the Y on the GiveWP, the API one was because we need to enable the ability to do forms in a new way. That was really clear. And then the Visual Donation Form Builder, part of the why was that we want people to be able to do a Visual Donation Form Builder, like just that feature by itself, but also because doing it this way opens up new capabilities for how forms are done visually.

[00:40:14] We want to be able to do like form templates and things like that in the future. And we couldn't do that without doing this. It's like taking off

[00:40:21] Devin Walker: the, taking off the blindfold from the user, right? Like before they were Like fiddling in this box of options. And then they had to like, open the door to like, take a look at what it looks like.

[00:40:31] And now it's there's no more door you are like doing what you're painting the canvas now.

[00:40:37] Matt Cromwell: Yeah. Devin, what's your best advice?

[00:40:42] Devin Walker: I really do to start with why are you a Simon Sinek guy? Yeah. Yeah, that's a good one. In lieu of that, I would say probably the how, once you identify the why, then it starts with, okay the how, right?

[00:40:56] You have your goals, you have everything ready, but so how are you going to execute it? And I'd look at my team and say do we want our best and brightest and most productive on this, or can we, Focus them on building, more profitable projects, or do we need them because that's, they're building the future.

[00:41:16] It's a tough decision. And then also, the world's going crazy versus AI now. I'd be guilty if I say I didn't plug in a bunch of my old methods and functions in there and be like, make this better. Because it's really good at refactoring code. And I've had I just had a new plugin submitted on wordpress.

[00:41:34] org that got accepted. It's a block plugin. And I refactored quite a bit of that when ChatGPT 3. 5 and 4 came out. Just for fun. Just to see how much better my React code could get. And it went really well. So I would love AI. That's awesome.

[00:41:53] Kevin Stover: That's a good, that's a good, that's a good tip.

[00:41:56] Matt Cromwell: I think my advice, if somebody came up to me at WordCamp and said I need to refactor my product, my advice would be don't.

[00:42:03] Literally I would say don't, just don't. Or, It would be don't unless you absolutely have to because it's just, it's really not worth it. I really think most of the time it's that thing of perfect is the enemy of done in many ways. Similar to what you were saying before, Kevin just because you don't like what it looks like under, under the covers or under the hood doesn't mean that it needs to be refactored.

[00:42:24] Um, I would want to beat that question up a ton. I think I'm piggybacking off of the why.

[00:42:30] Kevin Stover: Yeah, I think it's also important to think about if you're that developer, like wanting to refactor your code and not liking the code that you wrote, a while ago is good. That means that you've grown, that means that your development chops have gotten better like that, that impulse in and of itself is not bad.

[00:42:50] Matt Cromwell: But

[00:42:50] Kevin Stover: I agree with you Matt giving into that impulse just to give into it. It's probably not really helping you.

[00:42:57] Matt Cromwell: Yeah. I think if though, it's no, it really does have to be refactored. I would probably go about an MVP approach. I would say like, all right, then what is the MVP of your refactor look like?

[00:43:10] And make sure that you try to make this refactor as small as possible. And not think since we're doing it, why don't we do all these other things too? Don't

[00:43:17] Kevin Stover: do what we did, which is rebuild the whole thing from scratch.

[00:43:22] Matt Cromwell: I don't know, I honestly, I don't know if there was any other way you could have done what you did.

[00:43:26] I don't know. I

[00:43:28] Kevin Stover: lose sleep at night sometimes thinking about that, but maybe not.

[00:43:32] Matt Cromwell: But yeah, so try to think about the smallest possible way that you could do that. And the most, the least disruptive way you could possibly ship this new thing out there. And I think there's always ways, maybe break it up even into three.

[00:43:45] Small refactors instead of one giant one. Something like that because especially with WordPress when, if you have a hundred thousand users, a million users last thing you want is go disrupting 10 percent of those, even you disrupt 10 percent of those users, you are hurting your business in a serious way.

[00:44:03] So yeah. Good stuff, game. I really appreciate it. This is great. And I hope everyone listening is trying to hit that subscribe button. Cheesy stuff, I always got to say, because we're on YouTube. That's just how it is. And I hope that everyone is going to tune in next week to a topic that is yet to be determined.

[00:44:20] I'm going to figure it out between now and then. Thanks so much, Kevin, for being here. Thanks, Devin, for being here. And everyone, have a good one. Go break some eggs.