A Practical Playbook for Auditing and Simplifying Complex WordPress Sites | Matt Dorman

[applause] All right. Thank you so much. So, yesterday I was uh moving my youngest son into into dorms up in CU Boulder and it was 98 degrees. I thought it was hot and now now we're here. Um so refreshing to be in the air conditioning obviously, but going to kick it off with um kind of a raise your hand approach. Um, if you let's say raise your hand if your site has more plugins than you can name from memory, not not just, you know. Yeah, exactly. Right. And and you know, maybe keep them up and do you know what every one of those even do does even us? I'm assuming. Um, so first to introduce myself, the the introduction covered covered most of it, but I've been working in WordPress for quite a long time and I've dealt with, you know, I guess adopting or inheriting sites from from other places a lot of times. So this talk is really about getting a new site, whether you're you're inheriting it or looking at your new site from from a fresh perspective and going through that process of of kind of isolating what plugins we might be able to remove. This isn't about auditing, you know, plugins to bring in. These are more about to get get rid of some things. So, we did we ended up doing a little bit of a case study, but I'm not going to name names because we had two sites um ca came into us before before the talk into me that I was auditing. And basically, you know, this we we we go from plugin or sites that have, you know, 10 plugins, awesome. Um in this case, 50, 60, um not so great. But we've had even up to 80 plugins sometimes. And I'm sure a lot of you have have dealt with the same thing. Otherwise, you wouldn't be here and you you know, trying to find out more. Um, so it's not it's not a, you know, abnormal to get a a WordPress site with 50 or something plugins, but these were were a little bit interesting because, um, as you'll see, um, they weren't really 50 needed plugins. Um, and this is kind of that process. So, how how does a site get that way, right? As you know, like a site that you build, you're going to have only the plugins needed for that build. But sites that have been around for a little while, uh there's a campaign that comes out and needs a popup, as I mentioned, maybe a new SEO um audit comes in over the years, and they need something else done. So, this plugin does it, but this plugin doesn't. We don't want to remove that other plugin. So, now we have two SEO plugins and then a third. um maybe uh the new developer comes on board and they want it done a different way in a form and now it's added but then of course either that developer leaves or a developer that added a different plug-in leaves and now we don't know what to do with those plugins so why does nobody ever clean it up right you know these sites live out there's WordPress powers most of the internet essentially and there's a lot of these type of sites out there why why does no one ever clean it up well it's it's it's complicated Um, the biggest thing is what a breaks, right? What's the biggest fear of removing a plugin? Well, it might break something and and not knowing what it might break or how important the thing it might break um breaks. A lot of plugins, you remove them and they actually don't seem to break anything, but then a year down the road, we realize it broke this one page of the site. So, going through a process that actually can kind of clean those up would be helpful for for most people. Um sorry reading reading some notes as well. So the the biggest three reasons would be the fear uh turnover of people. Um and then another thing is that inactive so let's say you have a whole list of inactive plugins which one of these sites had quite a few um doesn't necessarily mean it's safe to delete them. I don't know if anyone of you know that, but there's obviously ways of programmatically um enabling plugins on certain p or activating certain plugins on certain pages, right? So, if there's code in there that you don't know that's doing that, um you might be breaking a page that doesn't exist or it maintained a set of tables or short codes um maybe even rest endpoints and things like that. So, just because they're in inactive doesn't mean they're they're quote unquote safe to delete. So, none of this is solved by trying harder. um is really needs you really needs a method. Um and that's what what I want to go through here today is the method that I've kind of adopted over the years of cleaning up these sites. Um and you're going to leave with that with um also a plugin. Uh kind of ironic. I'm going to give you a plugin to remove plugins. Um this plugin is meant to be added and then removed. Um it's not a long plugin and it's not on WordPress.org um because of that. It's just on a GitHub repo. Um, it's also not meant to be, you know, standalone. It's re really meant to be, you know, we've been doing this, my team, I have been doing this for a long time. I've used scripts. I've used all these things. Um, and there was other plugins out there as well that kind of do some of this, but kind of putting it into one place that's a really usable function. And this talk isn't about the plugin. It's just that'll be the tool that you could use um today if if you want to walk away with it. Um, so every number in this deck came from these two sites that that I'll be mentioning throughout. I'm not going to mention the actual sites, but two sites of an audit that we we went through. Um, so what's the first step? So, you got to get an inventory. So, if you're if you're going to go and start to remove plugins, you really need to say, um, get the entire picture. So, the goal shouldn't be, all right, find a thing, find a plugin, and delete the one plugin, find the next plugin, and delete the next plugin. You need to step back and do what whether you want to call an audit, an inventory, um, and get the numbers. So, in this case, I mentioned 100. That was the total number. So client A or site A had 53. The other one had 47. Um you would you know based on that number alone, oh they seem like two complicated sites. Then we got started getting into the weeds a little bit and realized well you know on on the one site there was 43 active that means there's 10 that are inactive. Pretty simple math there. Other one 37 that means 10 also. So again, similar looking sites, but then we started getting into the custom um number of plugins, and those were not just numbers, but the things that those were doing. And I'll get a little bit more detail into those a little bit later, but you don't get to that level with by going plugin by plugin by plugin. You really have to take the whole breadth. Um, and whether it's looking at the plug-in directory, um, that's one way to do it. Um, or you know, doing using AI maybe. Um, I'm not going to mention AI a bunch of of this talk, but I have used AI to do a lot of audits. And the one problem with just throwing AI at a site and saying, "Please audit the site," or, "Please look at the the plugins to clean up," is that you will get a different result um, every time on the same site. Not every time, but pretty pretty substantially. So, I can look at a site one year, and I kind of have done it over the years of the same codebase and then send it back again, and it's going to look at it in a different way for some reason. um obviously we have new models and things like that but it's not it needs the data accurate data I would say to then make the make your decision- making possible so this plugin or this a set of code that'll actually pull these types of numbers and then tell you what each one does is what's really going to be needed to to let AI augment your kind of decision tree and decision- making so what did counting actually turn up right well three and 10 30% did nothing useful at all. Um, we talked about the inactive ones, but there were so many in here as we started isolating the custom plugins. Um, but also we started looking at a little bit deeper level and I'll talk about that in a minute about you know duplicate things. Um, so we had roughly three and 10 were doing nothing at all or nothing useful rather. Uh, 20 deactivated they were still deployed. Um, a product discontinued by its vendor in 2019. Uh, two closed on WordPress.org or so weren't supported at all. Uh then a helper uh function or helper plugin for a calendar that uh the actual calendar plugin wasn't installed anymore. So a dependency relationship that didn't exist um even though it was still being able to be installed. And then one was was a fun one. Um not a fun one, but uh it was a plug-in directory. So if you look at the plugins directory, you see all the names. Well, it was empty um just the directory alone. So at some point it was clean cleaned up, but not fully cleaned up. Um the the the biggest or the funniest one I think is of the next one where um there was 11 years since the oldest active plugin was updated. Um and it was tested 4.2. Um but I think I put a note in here that that one yeah the readme said that it was a temporary fix. Um and it was still still available. Um and still it had never been updated since the first time that temporary fix was in place. Um so counting is the easy part. uh grouping now is where I think it get gets interesting because again we now have numbers we have the idea of you know what kind of general highle buckets we have for all these plugins but we need to get a little bit deeper um I mentioned the forms plugins right so we have um some redundancy here um it's only going to start to become visible I mean naming conventions are one thing like some plugins are named exactly what they do but some some are a little bit generic especially custom plugins um they can be like you of feature one, feature two, um, feature 17. Um, so the redundancy only becomes visible once you start to sort by the functions inside of that. And that's where it gets to the point where it's almost impossible for a person to look through file after file. Obviously, AI could could augment that. Um, this plugin does a little bit better job of parsing through through that or the code that we had that we then put into a plugin. um it it it parses through the the the actual functions of the functions. Um so we had three in this case we had three admin branding plugins. Um we're an agency that doesn't white label anything, especially our WordPress admin. Um we like WordPress to look like WordPress. Other people like it to look like their their company. That's not a bad decision at all, but three agencies at some point all decided to use a different plugin um before we we took it on. Um, so obviously that for us we didn't need even need one of them. We could we could eliminate three there. Um, there were two form builder plugins, right? Uh, in this case, so we had two different I kind of mentioned before, maybe a developer came in had a new form builder that they wanted to do. don't really know the history, but we had two here and once we once we did this audit, um the other one was more kind of apparent and it took a little bit bigger of a fix was there's once we started looking at names and functions and got the the results back, we had three accordion plugins. So accordion plugins, FAQs, they're big for for GEO and things like that now because you want answers and questions and answers, but this one had three different accordion implementations plus the details block as well. Um, so four essentially uh implementations of the same general functionality as far as a user and that's because you know every UI came up with a new one. Um, so we were able to to centralize that into to one accordion and then in this case it actually was one of the accordion um plugins was a paid one that was no longer paid for by the client. So it was no longer supported and it was one of those that needed to be updated or removed. Um, so the limit of this the tool and by the tool I mean again it's a plugin set of code that you could you could modify but putting a a set of code together um it really can do um the data. It can show you the data uh but it can't in my opinion you're not going to get a plugin and AI well it'll try it'll tell you that it's going to help make decisions but it's only going to flag the things that you might be able to do. So going through this categorization part part is really just to label out um what these categories are these broad level categories you know forms admin um maybe user input things like that but they're not saying oh well there's three admins so you have to remove them well that's a decision you have to make um so the tool is going to do that for you um it's not going to make the decisions and we'll get to that in a little bit um and the next step is really grouping so or we already talked grouping. So, turn up something that really wasn't expected once we were grouping. So, here's the the big one, and I'm a performance nut a little bit. Um, so as we went through this process of cleaning up the script and and looking at because we've almost always looked at the options table and like, oh, you know what, there's a lot of stuff, those settings, you know, we'd add and remove plugins. And I knew this myself. Um, and we we sometimes clean this up, but I've I've never had a site like this where 62% of the options that are that are actually autoloaded were not used ever. Um, these these sites had obviously been around for a while. Um, so, and this was only one site, so we're talking 231K. So, if you're not familiar with options, they do get cached, right? So, they get loaded, they get cached essentially, especially if you have on certain hosts, you'll you'll be able to cache it. but on let's say search results pages or a lot of admin most of the admin pages are going to be constantly loaded. So it's constantly database queries and to build this up but regardless of that you're talking about 231 kilobytes passing back and forth um for HTTP requests and again never used um hadn't been used for probably a few years. Um the 145 was um oh so this is one option one option record alone um was 145. So over half of of it was just one that had never been used. I've just never seen something quite quite egregious I guess. Um to think about quering in this way. So now this this will will show that for us. Um so counting and grouping got us here. Uh now what do we do? Right? We've got these we got the data. We've got you know the number of plugins. That's kind of interesting, but that's easy. You could you could have done that with a oneline CLI command essentially. Um, you could group them by kind of generally getting an idea. But if we got to this point where we now have an idea of like containers of types of plugins, that's kind of the the third step. So, what do we do next? So, I like to score things. Um, scoring doesn't have to be exact. Um, it just gets you to a place where you're now understanding like which ones are the worst offenders or which ones are the ones that I really need to get rid of. This is a typical audit, right? You're you're scoring based on am I ever going to use this plugin again? So in the in the top ones, um is anyone else using it? So is anyone using on WordPress.org? It'll get you the the updates and the install base. Um maybe it's been abandoned completely. Um that'll give it a certain score. Is it you go through security, right? So in our case, again, we adopted or inherited these sites. Um, I'll get into a next screen, but there was obviously security issues, but just looking at in general like what do they do and how many times have they required CV ease or have they been flagged for CVS or are they types of plugins that provide enough functionality um that I actually would want to continue to use them. Uh, and again, I'm performance nut, so I would go into into performance. Um, how much is it actually pulling in? So, in this case, um, I look at how much is it showing to the end user. uh is it you know is it a form plugin that you know I'm again I'm evaluating two plugins in this case so so which one is the most performant maybe I look at that and decide which one's gonna going to do do the right thing um all of that kind of gets superseded by the last one is it replaceable at all um or in one case is it replaceable by core because a lot of these have been around for so long that core is obviously advanced but is it replaceable by another plugin that does it better faster um more efficient is it does it have all these other things scoring really well. And again, this this nice plugin will will give you that kind of number, but this is a process that you'd want to go through regardless of having this plugin or not. So, getting the the the numbers of the scale of the of the site, knowing what it's doing, and now I'm I'm kind of weighing each individual plugin and I can understand like, oh, how good generally is is each plugin. And then the next thing I mentioned the custom plugins, right? So all of this like getting there's no download kind of install base of a custom plugin because it was built by someone that in this case doesn't doesn't exist at least for support. Um another evaluation goes deeper into that and there's a like custom plugins can mean anything like it could be the right way to do things. I like to do custom development a lot. Typically, I like to do it more in the theme, but in this case, this developer liked to do it in plugins. And uh this was 21 different plug-in files um all doing kind of individual functions. And if you look in the some of the details, uh there was 21 uh single file uh single author plugins on the site. Um that means that it had a PHP file and that's it did one set of functions within that PHP file. Um, and that meant if I was a human developer, I would have to go through all of this. Hopefully, my IDE is really good at like indexing and figuring things out. Luckily, we have AI a little bit more to to go through it, but it's really a bad kind of situation when you have that many different plugins. And I I'm probably preaching to the choir essentially, but um being able to condense 21 into a different number is a longer term um kind of kind of step. But we had so we had one executing arbitrary PHP for menu items. That's pretty standard. Um one that was just doing rewrites from HTTP to HTTPS. Like you don't need a plugin to do that anymore. Um that can either be on the host or all kinds of different ways. Um and then what was the other one? Oh, one one fixes addresses for for a calendar plugin. Again, I mentioned this before. It it didn't even exist anymore. So the plugin the custom plugin shouldn't have been maintained. So we had 19 megabytes um in a single directory. Um and that's not because the code was doing a whole lot of things. It's because it was shipping PHPUnit. So if you're not familiar with what PHPUnit, it's really for local development um local tooling and should never be put into a produ and this is code that was on production. Um should never be put into code that's on production, right? Um we had oh and full composer or the dev tree for another one. uh basically 1,800 files um for for one of them that that was a should have been a one file PHP plugin in that case. We had legacy plugins and things like that. Um another number we found in here was 15 of the 21 could be one version controlled site plugin. Um and that was just based on looking at the code and seeing what it did. Um and again going through at this point almost line by line but uh also just auditing the the features and functionalities of the site and how that feature map worked. So next up if you've gone through all this process and got finally got through the custom plugins maybe maybe you're you [clears throat] didn't actually have custom plugins that would be great but almost any legacy site's going to have some custom plugins. Um now this is the part that actually would keep I mean keeps me up at night a little bit. Um the security issues right? So again, this would be even though it's this far down in the slide, um these are the first things you would actually look because these are the things you need to immediately remediate, but maybe you're taking a step back and because it would be one thing to just upgrade these, but in this case, we were able to eliminate a couple of them. But these were these weren't like egregious. They just weren't updated for long enough. And I think the biggest reason was because the sites were so bloated. Um how could anyone really manage updates to the site, right? So you might be fearful of updating Elementor because you had no idea what even Elementor would be, you know, or those other custom plugins would be would be modifying in Elementor. So I can't update it. Um but once you get to that point where you're able to like condense and and eliminate as many as possible, these become a no-brainer and the you know security updates are just done. Hopefully automated but in some way right right away. So on the first audit, we did find five in five active plugins that had known CVS. Um and and here's some of the versions, but these are kind of relatively normal plugins. Like none of these would be something I would remove for any other re well I would update them, but they weren't things that I would remove. Um but like the ultimate branding was the admin branding that we didn't even want um anymore. So that was just a removal. Um and we wouldn't have known that by just looking at the at the these numbers. So you have a scored list. What order do we work in? Right? We've talked about this kind of in in somewhat in an order, but we need to look at it uh going through kind of because you can't do especially a site kind of this complex, I would say, or relatively complex. You can't just or I wouldn't recommend doing it all at once because you need some things you need to get done right away. So some quick wins would be the inactive and unused, right? We we evaluated it. We were very confident because of the plugin that that we had or the code that you have now. Um you can say that it's not being used by anything or we've removed the short code. So we remove those and and maybe do a deployment and maybe you wait um if you have if you haven't done those security ones or if you've done the security ones already um the consolidation. So going down this list, right, you're going from quick wins where we have a really high degree of confidence that we we're not going to affect the site, we're not going to change functionality. And that's the that's kind of the order I like to see things in. Right. So the next level, there's some consolidation. So I need to know that combining the two form elements, I know exactly what decisions were made for those two. So you might need to bring someone else in. Um or maybe there's a judgment call and someone says, "No, just go for it." But that's not something you're probably going to make on your own. So you're gonna have to bring in another person. The migration um there's a little bit different stuff because you might um not want to touch production. you might need to schedule it on a certain time, right? Um, but also the migration isn't just cleaning up the database. It's because of the consolidation that went into place. So in the uh the accordians, right? All those accordians, they all had three different short codes. So those had to be migrated into the same short code. So that's a that's a script. It's written. It's it's done, but it has to be deployed and it has to be followed up with all those other conversations that you had before. Um, so that's why I put it a little bit lower when when ones require a migration. And again, the idea of doing these steps is that you're deploying things, you're letting it sit, maybe you're you're evaluating things, and you're you're going about your business because you're probably not only fixing a site, you're all day long. You're probably fixing or maintaining other sites as well. So, this is kind of on the side anyways. Um, and then the last one is to continue to monitor. Um, so the by monitoring I'm saying like go ahead and deploy it because again my my my ability to like say it's 100% and not going to do anything is you know maybe 99.99% of the time just to throw out some numbers but there's not a 100% certainty that I made the right decision. So you're going to have to monitor it and you know make sure that it doesn't break. If you're on an e-commerce site that's a huge risk. Hopefully you have some other development environments. Um, yeah. So, so some of the numbers on the right, uh, you know, again, just by doing some simple things, we we're able to get those down to to 52, but it's 52 times two sites. So, we're we're at I mean, I know that they're maintainable now because we do maintain them, but we're talking about 25ish plugins on each site. Um, relatively complex sites with large like hundreds of thousands of pieces of content basically, but just just different showing it. So, so it's much easier to maintain now because not only because the number is lower because the number is one thing. Um, it's now that we have an actual document that describes what everything does on the site. And that's one thing that to come away with any types of these audits is that you now have a full description of the site. And I would say that that's kind of the best if you're not already doing it, whether you want to do it now or or in the future like or have something in place, make sure you've updated the existing ones. um because you quickly get into a state like this um as a new person comes in adds a thing or or whatever if you don't have that step in workflow. So one more finding because it explains why all this happens in the first place. I kind of alluded to it um or or or what we found um we found and this isn't a knock on any caching plugin. Uh, I haven't tried to knock any plugins at all, but we found that I think there were five um I think five different caching kind of ways of ways of doing caching. And again, old sites, they were probably moved from different hosts, different platforms that had different abilities. Uh, these were not none of these were or these weren't all active and these weren't all breaking. They were just files that existed in the repo. Um, they were named slightly different. They were commented out. they were in readme files that were referencing certain things. So, we were able to kind of do an archaeology of looking through everything and seeing like, well, that that explains a few things um right off the top of the top of it when we see all these different um caching plugins alone. Um again, I like I like caching plugins, but I like to limit it to doing only the things that need to be cached and hopefully keeping only the things dynamic that um aren't slowing the site down. um with what was it 100 or 200 and something kilobytes of options. Um so audits they they don't they don't exist to judge decisions. I again I'm not judging any plugins or any decisions made by the the team because I think this is one decision after a next not a whole set of decisions that were made all at one time. Staff came in and out. It's just the reality of whether you're taking on a site or you're sitting on a site that's been you know in a team for 10 years. these types of things happen um without some type of kind of step back and and overlook at the whole thing. So, which brings me to the the one thing I actually want me to remember. Um so, everything that that made this audit fast was automatable, right? So, again, I I went through this this well, I'll link you to the plugin. That plugin um is kind of automatable, right? So, it gives you all the data, all the numbers, and kind of gives you uh it digs through the site a bit. Um, but everything that's going to make it right, all those decisions are going to be made by humans. Maybe they make them wrong, too, but at least it'll be a human in the mix um to make those decisions and talk to other people. Um, and you're not doing it in a vacuum. So, the plugin will be a flashlight. It's not going to be the judge. And so, again, this is not a talk about this plugin. It just happened to be it's like, oh, why don't why not throw it all into a plugin that actually some people can take away. Um, it's just going to be on my my my personal GitHub, but you know, some things it's going to get right off the bat. I talked about the data. Um, in the middle, it's going to be some things that it's not going to be conclusive, but it'll at least give you some ideas. There'll be some false positives, false negatives, even a little bit, but just listing out the things that you might want to look at. Um, and then the right ones are just what you would do next. Right? So, it's not going to delete anything. It's not going to decide what. Well, I'm saying it doesn't delete anything and it doesn't, but don't run this on production. I guess I should put that note. Um, well, don't run it first on production. If you have only access to production, maybe do a development copy. Um, I should say that in the footnotes or something, I guess. Um, but yeah, it's not going to delete anything. It's not going to decide make any decisions or remove or try to clean up anything. Um, it's just going to give you all the data that you might need. Um, and kind of walk through that that process, the four the four steps. So, go ahead and run it. Um, if if you get to it. Uh, I haven't run it on I haven't run this plugin on a ton of sites and I put I'll put another one up there as well or another link, but I'd love to have some feedback. I think this is something that could be used um for you to like modify or or think fork and things like that. Um, I don't think it's going to solve all the problems everywhere. So, I don't know that it's going to be like a maintainable like keep keep growing, but it is something you can throw in, do a quick audit. Um, it'll tell you how how good the site, especially if you have a site like we did with, you know, 50 or 60 or 70 plugins. Um, it's going to be a diagnostic. It's not going to be the surgeon that's going to fix every single little problem. Um, and there is no and there never would be a fixed button. Um, I'm not really a big fan of those that just fix all the things. Um, because they tend to break things. So, the QR code hopefully is live. I actually I think I tested it, but look me up on GitHub, Matthew Dorman. If if it doesn't doesn't pull up. Um, so again, I told you to install a plugin, but every plugin that you install is a decision to maintain forever. Um, or a decision someone else gets to make, um, when you leave. So, run it on one site, find me, um, send me a note. Here's my LinkedIn, and we can jump into Q&A on this topic, on any any plug-in topic really. Um, please come up to the microphone with questions. I have a question. Um, how do you deal with the sort of the the scripting the the script plugins that let you write PHP code in your admin? Do you address that as part of this? >> So, I don't know if that was in this plug. That's a good question because I don't know if I added that into this plugin. typically would do a database scan for all PHP scripts um as a security scan of of sites. So I So yeah, so you'd want to scan all of typically they're in the options a lot of times. They're in settings. Um but they're also potentially in like they're going to output generally render something in some of the older versions of WordPress and it'll render either and JavaScript also I guess. Um yeah, I don't know if this plugin looks for the database um scripts. It looks for the database for the options. It looks for to figure out which is enabled. Um that's that might be a good good first feature. Um but they're they're there. So if you don't know uh any C any open source PHP CMS allows you to over times it's allowed you to add PHP into the database. Um and sometimes that's for very small sites and very good reasons but typically um it can do very bad things as you can imagine very quickly. It's typically how people take over sites. Great talk. Thank you. Um, I do a lot of plug-in audits myself and uh I find that uh short code finder >> and uh find my block are really helpful, but >> how do you manage there? Two questions. How do you manage um like knowing that a plugin is actually being used? I'm thinking of maybe Jetack gets really complicated to know if it's actually being used on the site, >> right? Yeah, that that was I mean that's one of the things that we had to throw into this plug because there's so many different ways that a plugin is being used, right? So with with Jetack it's kind of almost there's some of the it's like service requests sometimes, right? There's so many different ways that are activating a plugin or a piece of a plugin. Um because that's where it gets really complicated is that it's one thing to know that the plugin's being used, but a plugin like Jetack that has so many different modules and so many different features. Um what piece of that this doesn't go through that depth of like finding the the different libraries within the plugin I would say. I mean this is not a like we we've never done done that level of audit of of the features of like a jetack. Um, but it does start search through all the short codes and that's again where we where it finds, you know, when there are no short there's a short code in the database somewhere, but there's no existence of that in the code anywhere. And that could be theme or plugin. Um, and that means that it flags and it tries to do it tries to find where the plugin is. I don't know if it does a great job of that yet, but at least tells you that there was a short code used and it's kind of a an orphan. So, that's one side of it. And then the other thing is, well, there's a short code and it maps to this plugin. Well, therefore, it's being used. That's where I was mentioning like maybe it was deactivated, but like it wouldn't still render if it was deactivated, but at least you know that I probably shouldn't just delete it. Um, right. >> And um the repo, it's a Python script. >> So there's a Python script in there to to do on the Yeah, sorry. I'm I'm a developer. I'm used to like doing a build. Um, so you do a build and it it pulls in some some files. Again, this is a more of a local development tool and not something can run. Yeah, because it has to do a lot of search text searches. Um, yeah, not not all not pure PHP. It probably would never be a WordPress plugin because of that. First of all, I've been doing what you're doing for the last 10 years and it's like the most fun thing ever. It's like a every time you open a new site, it's like a cross between crossword puzzles and crime scene investigation and it's just >> yeah, >> it's the best job ever. But um does your script have >> Are you serious? >> I'm dead serious. >> Okay. >> I I would do it. >> I do like it a little bit, but yeah, [laughter] >> if I won the lottery, I'd do it for free. >> Nice. >> Um the worst site I ever saw was a you know, they paid extra because of zero plugins. >> Yeah. >> But there was a uh this is like two or three years ago. uh the genius programmers who had done it had stuck all of ACF into functions.php and it was a version from 2015. And does your script happen to look at >> and and by the way I don't say that I hate custom code. I only see the bad websites. If somebody's website runs and they're happy with their developer, I never get to see those. But I do get to see the ones like that. >> Does your script look at >> functions.php? >> Right. It does. Yeah, that's a good It will have to because similar to looking for PHP in the database, these are things that I don't didn't think about anymore because hacking WordPresses on a security scan, which but that's a good point of like this could easily search through the WordPress files um in a few different ways, right? It could look at the fun like it could look at the files that it's expecting in a current version of WordPress and it could look at like identifying where someone partially updated WordPress and even think about core type things, right? Like you could easily look through different versions of the WordPress core files and like well that doesn't even exist anymore. Why is it there? I mentioned the empty plug-in folder. There was other f other ones that had file and naming conventions. But yeah, that's a good point. So, does your plug-in like we we have a custom theme and it has code like roots >> growing through the foundation from some of the plugins. >> So, not the roots theme, but >> no. >> Yep. And and so if I wanted to change to a different search plugin, it I'd have to find all the roots in the PHP function, >> right? >> Every function. [laughter] >> Yeah, that might be. So I'm I'm not like I've been along the path long enough that a lot of themes are built that way with class files and includes and and things like that. So all the features and functionality are in the theme. Oops. and and sometimes it's a really good way of building sites. Um, sometimes it's it's hard to and complicated for people to to look through that and all the code in in the theme. Um, this one does it. It looks through the theme, but it's more focused on the plugins directory looking for what's there, what's not, and is it being used inside of the theme or is it being used inside of the database? Um, and not helping clean up. But that could be something it it could do as well. it could better kind of define what's in the theme and what functions and features are there in a similar way. >> So, it's kind of like it it calls a function name and I don't know if that function is a is a core function, if that's a plug-in function, if that's a custom plug-in function, if that's somewhere else in the theme, it's like I don't know where that function goes or where it came from. Unfortunately, I'm going also down the path of being a dumber developer every day and I use Claude more and more and I would ask Claude to Claude code to to evaluate where that where that's being done. I mean there's other ways of doing it but it might be the best use of of AI to do like a quick question. Sorry. >> Hello. Um, the question I have is how do you balance and and like which way do you uh tend to lean? Do you allow plugins and everything to do auto updating >> or do you more or less pin it and have to make sure that it's each version is approved before you go? Because it's like a balancing act between like all these zero day exploits that we're seeing, >> right? And we're also getting all the news of like, oh, this plugin's been compromised and an update has gone out to everybody that has a back door in it. >> Yeah, if you didn't if you didn't follow it up with that last one, like, you know, two or three weeks ago, I would said our process is always we have dev, staging, and live. And we h and we run through automated updates in each of those environments. Um, but yeah, some of them are coming out so quick now that they need to be updated. Security updates need to be updated live. Um, I don't have a new answer for that yet. I mean core most plat most hosting platforms are updating those right away thankfully and and doing a very good job. Plugins um I don't know I might lean more towards maybe we need an a different way of like setting the auto update for security only but they do seem to be coming out with serious issues um relatively frequently all of a sudden. Yeah, because it's also a nervous thing of being like, well, do I just make the whole file system read only and then have to like update with >> WP CLI? >> If you can if if the if the file system you write other than uploads um and then you can define that it doesn't get you know no PHP files get evaluated in there. I mean if you're if you have have control over your environment. >> Yeah, I have that all locked down. But it's it's been a big thing because I had a bunch of sites hacked over the last week. So, >> yeah, I [laughter] bet. >> And you weren't doing nothing wrong. Like, it just came so quick. >> I'm another nut job that likes getting handed a total mess of a website. Um, it's oddly satisfying to kind of turn it into a total mess and something lean and clean. Um, but my question for you was not related to your plugin. Um, for after you've, you know, offloaded all these plugins, deleted some, consolidated others, etc., etc., And there's all that leftover database bolt that you talked about, you know, the autoload, uh, extra options and things like that. Um, how do you go about cleaning out the database? Do you do it manually? Do you use a plug-in? Do you have a system that you follow for doing that? >> Yeah, I do. I definitely So, we I talked about having multiple environments, a local, even dev, then staging, then live. So, almost everything I do is scriptable. Um, so in a a lot of times a CLI I'll I'll write a CLI command that that will I'll then run um in those environments. Um, that's typically my approach so that I can then run the same thing, run one command and have it, you know, do one a bunch of things basically. Um, because it's repeatable then um, you know, it might fail and then then it's a uh oh type, but but typically it doesn't fail and you can't rerun it. you typically can rerun it type of thing. >> Thanks. [snorts] >> Hi. So, similar to him, I also inherited dozens of sites that were built from who knows where, somebody's uncles, cousins, dogs, fiance or whatever. Um, at what point, and I feel like this is going to be super useful. I'm really excited to try it, but at what point is it like you can polish a turd, but it's still a piece of crap, you know? So, I mean, at what point do you just decide I it's going to be easier and more time-saving for me to just start over? >> To start over. >> Yeah. >> At what point? Um, well, so so I did mention we're still stuck with a bunch of custom plugins that were kind of the the nice thing is that project is going through a redesign. So, that's the definite time to do and we're going to start from scratch on that site. Not because it is so bad, but why not? if we're doing a full redesign of the of the site. Um, you know, AI provides a way of building out some of this functionality, the custom functionality, um, in a way that we never had before and migrating content um, that we never had before. So, that makes it somewhat of an easier decision. The problem is that similar to the kind of going down the line, you're now involving more and more people. So, a rebuild involves a lot of people for for a lot of sites. So, you're investing a lot more than the developer time to do it. you're now investing the owner of the companies, the everyone all the way down the chain. So that has to be thought through of if it's if it's worth that time um and investment. Um or do we need to redesign anyways? Um >> thank you. >> Yeah. >> All right. >> All right. So my next question, so you did this plug-in audit, you removed stuff, you cleaned it up. Um what were the performance implications of doing that? Like besides just generally cleaning up, were the sites faster, better? >> Yeah. Yeah. The uh so the the options alone um again on any dynamic page um and on any page that had to pick up the the option uncashed um it was significantly in the in the realm of I'm used to dealing with mill like hundreds of milliseconds improvements and that's a win. This was seconds um on some of the pages um because it you know it it wasn't just the one was big and that was a big data thing but it was so many other ones that it was read you know get option get option get option get option over and over and over that many times and it has to load it all up. So that was a big win. Just the number of files though was um again on some of the more dynamic pages of the ones an e-commerce site it was seconds um on some of their pages not on every page because some pages are cachable. >> I'm not I'm curious I'll run your plugin but I inherited a site where a guy combined most multiple custom plugins. So, will this give us data or results on maybe what part of that? >> Yeah, it it'll attempt to go through. So, it's it's going to go through every plugin. It's going to go through kind of dumb. It's not going to it's not going to say, "Oh, this is a WordPress.org, so I'm going to just use whatever's the description." It's actually going to look through the files anyways. So, it's it's built to actually go through the files of every plugin um and then help you kind of define of what what it's doing. So, does it have an admin functionality? Does it have does it is it trying to build forms? Is it trying to um I can't remember all the all the categories off hand, but it's trying to categorize those into so even if it's a custom one, it'll attempt to. >> Awesome. >> Um >> yeah, because some of those features that were built and one of those that got combined is no longer needed. And so I I just want to condense some of that bloat. >> Yeah. So, I mean, the the part that this will do is it it'll look through that and it if there's short codes defined, if there's endpoints defined, it'll see if there's anything else referencing it at least. Um, if it hasn't, we can fix that, too. [snorts] Okay, great. Yay. Good timing. [applause]