How to manage WordPress at scale

Hello, everyone, welcome to yet another Buddy Webinar today we are going to talk about how to manage WordPress at scale and, and we will be talking about a really big scale. So that's why Because personally, I managed a few word presses at the time. But Ryan manages hundreds of WordPress at his company. So that's why I invited him and he will share a lot of tricks, and he will just tell us how to do it in the right way. So, Ryan, welcome and tell us a few things about yourself.

I appreciate you having me here Maciek. I'm Ryan Sullivan, I am the COO of SiteCare. We are a professional services company specialising in WordPress management. Like magic said, we do it at a pretty unique scale. And, you know, we also have a suite of digital marketing services. But you can think of us as a, you know, an outsource managed services, you know, an outsourced managed services provider whose two specialises in, in WordPress, what we I started working in this world in 2012. So have seen a lot of different things. We work oh, and just you know, I am, I'm from Salt Lake City, Utah. So anybody curious about where where I'm located, that's where I'm at. We run just, you know, site care manages by by this time, next month, we should be managing roughly 600 600 clients, websites. And we do that with a team of five developers and three, three clients success reps, so eight people managing 600 sites, you can do a little bit of the math there and go, they must be they must be doing some something to make that scale up from, from a human perspective. And, and yeah, so I've been I've only been in the CEO role for about three and a half months now. But before that, I was leading our client success and development teams and and have kind of been with site care since really the very beginning. So I don't I don't know how much you know, I can I can get in. I'll give you I'll give you a really brief history of kind of how it all came together. But I started a company in 2012 called WP SiteCare, WP for WordPress, obviously. And our COO Drew our CEO Drew Barton started a company called called Southern web in 2005. So really, they were very early on in like the what and their services were more geared toward web design, digital marketing, more traditional agency type work. Web site care was very managed services. We were kind of one of the if not the first company to really provide this proactive you know, maintenance service to to the masses. And in 2018 our companies came together southern web acquired WP SiteCare and We rebranded as SiteCare a few years ago. So that's kind of the very condensed short version of, you know, where, how SiteCare came to be and how we brought all these all these clients together.

Okay, thank you for the even the for the brief history. And my name is Maciek Palmowski. I am the WordPress ambassador here at Buddy and I am your favourite webinar host. And okay, so before we begin, if you like our webinars, do not forget to press the subscribe button on YouTube, we will be always informed about the new webinars incoming. Also, if you have any questions regarding today's webinar, you can ask them in the comment section on Facebook, Youtube or LinkedIn. It depends of course, where are you watching us? So first, let's start with what we'll learn today. So first of all, we will learn how to maintain those hundreds of websites without compromising the quality, we will also learn and personally this is this is the thing, I really can't wait to hear how to convince the clients to follow your flow because I know that the clients are the most problematic part of such a process. And we will learn what are the useful tools in such a process? Okay, so Ryan, yeah, you mentioned about SiteCare. So what exactly do you do at sidecar? What what what services do you provide?

Yeah, so, you know, we, we primarily provide. One part of what we do is, is managed, you know, manage updates, manage WordPress updates managed, meaning they go through some kind of testing process before the live websites are updated, the change, it's not just testing, it's also, you know, change control. So monitoring, as updates become available, making smart decisions about how updates get released, and when they get released and making sure that you know, the clients in the loop on any change control that's, that's occurring with the website that so, so managed updates as part of what we do. Another thing we do is we do a quite a bit of, you know, WordPress development, and the thing that's a little bit here, so, and we do WordPress development, basically, anything that's not building new websites, like we do a lot of feature add ons and integration builds, and, you know, even more simple things like, you know, building landing pages for clients and, and that type of thing. But we, we provide our development services. And that's like on the technical side, oh, and then one of the things that I really can't forget is a lot of performance optimization work. So this has obviously become a much bigger push in the last six months is Google's making changes to how, you know how they measure performance and their whole core web vitals, metric and things like that. But we we do a lot in that world as well to, you know, optimise performance for our for our clients websites. We also, and this is, you know, we also have a full suite of digital marketing services. I don't think we're going to be talking about that much in our conversation today. But I want to get it out there that we do have teams that that take care of the take care of both of those things.

Yeah. Okay. Yeah, because I work at an agency, I had my own agency at some point. And I remember that. I also wanted to take care of clients website, because this is the constant cash flow after doing the website. But in my case, it was quite easier because first of all, I didn't have had the scale of hundreds of website, websites is the first thing and on the other hand, I was always responsible for for the whole code. But I am sure that you are in the more difficult position because first of all, you have much more websites at the time. And on the other hand, you have to fit in into something that is already done or was just I don't know, for example, there was a theme about inventory market and on Theme Forest and you have to do something with it. So how how do you manage it? cuz I know that it can be a real pain.

Yeah, so there's the code variables that you're talking about. Right. But there's also the, there's so many other variables that come into play that we have to evaluate and make decisions around. Right? So like, have our 600, you know, these 600 clients where, you know, those are probably spread across 50 different hosting providers.

Exactly.

And so there's all these different environments that we need to accommodate for and that we need to, you know, decide, like, help the client decide, is this the right place for them? Should they be somewhere else? And then, obviously, this is not really the technical side of things. But there's, there's the financial, like component of this as well, it's like, so yeah, so when we bring in a new client, like, to your point, almost everything we work on is inherited from somewhere else, almost everything. So when we bring on a new client, we go through a list of checks that says, What are the things that are, like going to become problematic for us to manage and maintain the website properly, and we create a punch list at the very beginning. And we prioritise it, we say, okay, they're hosted on a server in their mom, in their aunt's basement, we literally cannot work with this. And we like step one priority one is shift them to better manage hosting. So that's, you know, that's part of it. Another part of it. So we go through that, and we evaluate each thing, step by step, we just break it into the smallest, most manageable pieces. And we take that back to the client. And sometimes that looks like you know, if they have a lot of technical debt, if they have a lot of pre existing issues, if we find that, hey, this is really like, put it like, we can manage this, but it's going to eventually put your business in jeopardy. And here's why would we you know, we have those conversations, literally within the first few days of of them, becoming a client and bring that to them. And then we put together a game plan to either refactor what's there, rip out the stuff that's bad, or, you know, convert it to something that's going to be more sustainable and more maintainable. I love. And I think I mentioned this, like in I was, I got to be the guest editor for the WP als newsletter. And I think one of the things I really focused on there was, you know, this idea of maintenance development. A lot of times as developers, we I say, we I'm not a developer anymore. To be clear, like, I lead that team, there are people much smarter on my team than I am. But but, you know, it's all about features, and what are the cool new integrations we're building? And what are the cool new? What's the new that we're adding? And I think one of the most like nuanced and undervalued skills or talents that a developer has, is being able to evaluate, okay, there's, there's a rat's nest of code here. How do we get this to a place where it can be well maintained? And, and so like, to your point, there's typically when, when a client who hasn't has a site that hasn't been well maintained or well managed historically comes to us, there's typically some upfront work that we have to go through and do in order to get it to a state where we can manage it well going forward. So it's not there isn't a magic bullet, unfortunately, for that there's very much like some some work that we just have to do. But that's, you know, that's that's how we approach that as a new client comes in the door.

Yeah, I understand that and tell me because, as you mentioned, there is there is this list there is this list, you have to go point by point. And how, how do you convince the client to follow this list, follow this flow because as we'll probably jump into this, you aren't just the company that goes to the website once per week and press update and update the plug in you have you will use Git you will use continuous integration. As you said, you have a list so it's important for you the code of the website is at least at some level. So it's manageable by by your company. So how do you convince the client? Because I know that those talks are difficult. And I know that fixing such things, also costs money. So how do you do it?

Yeah, it's, it's a great question. And it's one of those things that is an active, like, even even on the sales side of our conversations, we're talking about a lot of this stuff before they even become a client. So there's no, so I think, you know, part of it is start that conversation early. What we don't do, which I have seen in the industry is bring on a client, and then say, Yeah, we're gonna maintain your website, and then, you know, hit them with a surprise invoice, you know, a week later for three grand for three grand that says, oh, yeah, we have to do this to fix everything. And then we don't do that at all, our sales folks are very informed and, and very much in the know about, hey, there's some potential risk here for technical debt, we're seeing a lot of red flags, and we actually have actually maintain a list of, hey, here's some clues that there might be more than meets the eye here that our sales people are familiar with, and understand so. So even at the very beginning, we, we encourage clients, if they're not ready to understand why it's important, like if they're not, if they're not, if they don't clearly understand why it's important to have a well maintained website, and why this proactive work needs to be done. We are totally fine. If they don't have if they're not quick to adopt that mindset and see the value there. We're totally comfortable with not working with them. But like, and that that happens, right? We very much are solutions, minded, we want to be able to work with them. But I'll be honest, like there's there are scenarios that play out where they just say, there's no like, this doesn't matter enough to me to, to, you know, invest in getting the site to a better spot, the way that if there's any convinced so I think point one is I don't, we don't do a lot of convincing necessarily. We do more, you know, we do more, here's our, here's our mindset, here's how we think about this. And the way that we can kind of help clients really, you know, have that same mindset is to talk about what it looks like, if the site isn't well managed, and well maintained. An example that I like to use, that I think has a lot of parallels is, you know, not doing routine maintenance for your vehicle. Right? If you if you own a car, and you don't change the oil, and you don't rotate the tires, and you you know, don't go through the regular inspections to make sure the fluids are topped up and do all those things. People are able to connect to that pretty quickly and go, Oh, yeah, then then I'm replacing an engine in six months, or nine months or a year or whatever. And I go, that's exactly right. You know, so I think that's kind of a scenario. And like, there, there are different classes of, of client to write, like some come in with. I mean, we have clients who come to us and say, We need to be operating at at least this standard. And they will give us a technical spec that says, here's, you know, here's how change control works. And can you work with this? And can you accommodate this. But that's more for you know, that's more for enterprise level fortune type companies, which which we work with, but it's, to be honest, there's a lot of those clients who are at that level from a business perspective, who do not have good, you know, maintenance practices. So, so we see kind of, you know, we see, we see everything in that regard. But, you know, to get to your point, I think it's just really helping clients understand what happens if an extra level of care isn't taken. I think another example that I've, you know, brought up in the past and this is, this is easy for sites that have a lot of traffic or that have a, you know, e commerce sites, especially if there's some kind of website disruption or some kind of Have a bug that's only impacting a subset of users like a silent killer of some kind. That means it's, you know, that's, you're losing business, if you're if it's a high traffic site like a publisher, they're losing ad revenue, if there's if the site's broken in some way, it's an E commerce site, and the checkout doesn't work. You're not selling products. But even like, checkout being broken is even a, you know, an extreme example, like, what if, like, what if it's just not as performant? As it should be? What if it's just not as fast as it should be? We all know how impatient people are, if I try and check out and the checkout action is slower than I hope, I'll probably go somewhere else and look for it. And so those are the types of use cases or examples that I give to connect clients. And, and and help them understand why what we do has the level of importance that it does. And I, you know, it doesn't always work out, but I think a lot of times it does.

Okay, yeah. You mentioned one thing that you have this list of red flags. Could you share one or two of those?

Yeah, so absolutely, um, you know, we, I don't need to name and shame. But we definitely have a list of like, you know, preferred hosting providers, where, and the big advantage we have metric that a lot of folks don't is we get to see, like our experience with a hosting provider isn't anecdotal. We get to see, okay, we have 40 clients on this web host. And anytime that we contact their support, it's a nightmare. Or anytime that the client contacts their support, it's a nightmare. Or, look, we have data for 40 of these websites that shows even with optimised code, performance is lacking. And we go okay, well, if we take 10 of those sites, and we move them to another provider, look, performance boosted automatically without any other underlying changes. And so So yeah, so that's one of the things we look at is where's this? Where's this website hosted? We do look for honestly, the, we do look at themes, right, like the Swiss Army Knife theme, like you kind of reference like, this is a theme that does absolutely everything, those are those can be a red flag. themes that rely heavily on page builders have also become particularly challenging and problematic, mainly for performance reasons. The, you know, the front end that gets generated has, you know, 1000s of classes on one page, that just makes it really hard to optimise for, for certain conditions. Another thing, but another one that is more recent, is not more recent, but you know, we've seen more of in the last year or so are very custom themes that are actually kind of over engineered, that are put together in a way that's extremely complex that, you know, require. One thing we'll see a lot is a theme that's put together in a very, like complex structure, custom structure. And there's almost never supporting documentation for how it's supposed to work. And like, even if we can get those builds running and working for those very complex themes, which most of the time we can we still run into, okay, well, you know, when this was first, when this thing was first created four years ago, it was using all of these, you know, packages that have either been deprecated, or abandoned or have new versions that have just been ignored, right. And so, so then we're we're scrambling to find what are the replacement packages are their replacement packages? So a very custom theme is another thing that we, you know, brings plenty of technical debt along with it.

Yeah, I can understand it. And as you mentioned, you are not big company. So probably you have to use also some some automation to make your work. Not only easier, I would even just say just possible to do because with so many website, websites, it's it would be just impossible to do everything by hand. So how do you automate your processes are, yeah, just just like, how do I automate everything? Or what do you?

Yeah, this has become interesting, because several years ago, we went down the route of approaching Update Management with a fully automated process. And when I say by fully automated is based on Git, it would go through, you know, we had service workers that would go through and process updates in a staging environment, then it would run visual regression, visual regression checks against any of the unique templates on the site. And then it would, you know, basically give us a pass fail on any of those. No on on the outcome of that, and then we would do some man, we would do some limited manual testing for functional things and, and things that way. And we tried to, basically, it was set up in a way that with these workers that we had running, once a test cycle had completed, we could go through and say, Okay, this all looks good. We're going to push it to production. One of the challenges we came across when we tried to automate it completely like that, is it removed a lot of the intelligence and decision making about how to prioritise updates for a website? Let me give you an example. If a if a WordPress plug in author releases a security vulnerability update, you know that their plugin has a security vulnerability and they want to release a patch. How do you how do you prioritise that and say, well, the bot doesn't know how to identify that differently, right. They, and we could have gone down the route of, you know, identifying security releases and giving them a special type of condition. And, but but that was our signal to like, Okay, well, if it's a security related patch, we have an SLA that says we need to push that out within 24 hours. Well, is that, you know, do we want to bundle that with these other with these other changes that might be present? Not really. So we ended up in this in this liminal space of like, yes, we see the value of automation, but it doesn't allow us to continue to be the expert, if that makes sense. So that was a law. That was a little bit of a long way around. But but now we have a what I'll call a semi automated process, where we still have, you know, where we still have the ability to process updates. Essentially, within staging environments, we can have update checks run daily, they get checked in all of those, you know, all of those are checked in through get, and then we can evaluate on a case by case basis and say, here are the you know, here are the plugins that need to be prioritised or update it. And then there is a person who is manually reviewing, there's a personnel, there are people on our team who do go through and manually view and say, yes, we want to process these updates, push them out, they're ready to be processed. And we tie you know, we tie testing to each of those two, so we do still have the visual regression component, we do still have the, you know, the lighthouse checks and things that way. And we also have automated since we've automated the functional testing. So key actions, like completing a form or completing a checkout or, you know, those types of things we do have built into to a testing suite as well. But it's a it's more of a combination of it. And the other component that we had to account for metric was just the client requirements. So some of the clients they need to have internal review of any changes on their end. So, you know, if we're fully automating the solution, it doesn't give us a chance to say okay, pause Intel blank, right. So we want to, ultimately, updates are still processed by an individual, but with the actual clicking of buttons done in other ways, if that makes sense. We're showing the release, we're controlling the release, I guess is the way is the way I would put it. And, yeah, that's kind of hard to put together.

Yeah, but still still the human, the human is very important. It's not something that you can automate. Fully. And then what? What tools are you using in your, in your every everyday routine?

Yeah. So as far as our I mean, we, we obviously use Buddy, we, we've been, we haven't been using it for long. About a year probably. And, but in that year, it's been transformational for us, the way that we're able to, you know, manage a lot of this, a lot of this change control has been been fantastic. Some other tools that we we use on the development side of things, we do have Codacy, that does, quality reviews, and standards, reviews, and tracks those over time for our clients. You know, I don't know, this isn't necessarily necessarily a tool, but it has become a daily part of our conversations, is lighthouse. And in tracking performance, and accessibility and other, you know, key metrics through through the lighthouse API, we also use Ghost inspector for a lot of that functional testing that I mentioned. And then, you know, on the on the actual developer side of things, you know, the IDE that we use, every, you know, it's very, it's a, it's something that users protect, very much, right? Sorry, the developers are very particular about so everybody can use whatever IDE they use. We do have some standards, some linters. And things like that built in, we typically use the VIP coding, the WordPress VIP coding standards and spec that's been that's given us good coverage for most things. And then as far as the and then I do think most of our developers are using local WP for for their local development for the most part.

Okay, that's, that's great to know, as especially the local environment was kind of interesting, too, because it's quite a common discussion everywhere. What are you using? And why? And yes, and we will jump into into some practical examples. I have one more questions, because I understand that you have many, many types of clients from those who just require the basic maintaining, so keeping their website updated and working. And that's it. But also, you have those enterprise clients that you mentioned. So how does that testing for each type of the client looks like? So, for example, for this simple client? What do you test? And we'll do tests for this high end enterprise one?

Yeah, so it does. It does. We do have different tiers of service. Right. So and we set up our we set up our standards and and what we test accordingly. Typically, what like for a, we do have a mostly automated, mostly automated solution for our, our SiteCare standard clients, that's the entry level tool, entry level tier of our service. Typically, our checks for that are automated visual regression. So was there a significant visual change in anything on the key templates of this site? If no, it's green light, good to go. It's, it's pretty, it's it's fairly straightforward. For the, you know, for the other types of, you know, for the other tiers we have, we're doing visual regression testing, but also, you know, typically pair it with some kind of functional testing, and then we, but then we do have clients who have a accustom level of service right where we We're we're actually building, you know, very unique, very unique deployment pipelines and CI/CD in order to meet, you know, the standards that they that they require. But it's, it's mostly a combination of, you know, a combination of pretty automated to, to very, it's a very custom I, I would, that's the one thing that I think is kind of unique, is, as much as we are a company that operates at a certain scale, we have templates that we start with, but we we don't have a you know, every every site could have a requirement that's just a little bit different than then, than what a template can dictate. Right. You know, there's always some kind of edge case. And that's why I like it. As much as we can automate things. I still love that we have the oversight and the mindfulness of, you know, real humans and engineers who say, Well, this template mostly works, but we need to modify this one thing, because they're, they're using an AWS service that that 0.5% of our clients use, and you know, that there's different, you know, different types of accommodations that need to be made there. I don't know if that really answers your question. Well, but But we, you know, we have different standards and different checklists that we go through four different service tiers, but we also have a good chunk that are pretty customised.

Yeah, I understand. I mean, it's kind of normal for those high end clients that they have something made just for them. So this is this is kind of normal. Okay, so I think that it's time to do you could show us some of, of the pipelines that you are, that you are using. So

I'd love to Yeah, so this is a, this is this is actually the real pipeline for, for sitecare.com. I just want to, you know, I'll kind of walk you through the individual steps and, and what they, what they include. And some of the things we're we're checking for. And, again, you know, this is this is what's been incredibly, you know, incredibly, I use the word transformational, which is kind of a big word that sounds more important than it really is, but it's like this tool has been, has totally streamlined the way that we can, you know, operate at the scale that we do. So. So this is a pipeline that's just set up for our staging environment we've got, you can see, it's connected to this branch that we have dedicated as staging. Our standard Git workflow is to branch off of, you know, branch off of a state off of our develop branch, create a feature branch, merge that to staging, and then, and then once it gets merged to staging, then it'll go through these, you know, it will go through these stages within the pipeline. So the first one very easy, just, you know, it's file transfer just moves, whatever changes have happened to, to that staging environment. When that happens, it sends a notification to slack. We intentionally send this first before these other steps before these other steps take place, because it puts somebody from our engineering team on alert, the changes are made or being made. And we can kind of have still have a level of real human, you know, monitoring involvement. So watch through the end of the deploy process. It purchase the cash at site, purchase the cache at Cloudflare. You can set this to purge individual URLs. But where this is, you know, where this is a staging environment. It's it's not really we just do a full we just can we just purge everything and let it go. But if is the conditionals that we have set up there is just only and this is true, pretty much every time but it's just a condition that says if there were changes in the repository, I mean, the pipeline shouldn't really even start until that's true, but just an extra an extra level of caution there. And then Lighthouse checks are run, we have all of our thresholds set for lighthouse. So these are our mobile scores. And we have another set for, you know, for desktop scores, this is only running on our homepage. But But again, this is just the staging site. So these lighthouse, our production pipeline has several different Lighthouse Lighthouse checks for key pages on our for key pages on our site. And the if condition that's running here is well, there's also a setting here to auto retry if the action fails. So a lot of times if these run too quickly, so for example, the cloud for like, Cloudflare step, you clear out the cache, and it's, it doesn't rebuild quickly enough, the lighthouse scores aren't representative of what's true. So, so if this fails, we have it set to retry at 32nd intervals a few times, just to make sure that we if we get a fail, it's a true fail. And, and we use that. And then yeah, this this, this last stage is to run a, a real user test against against our contact form, our most of the most of our business comes through, you know, a few different contact forms on our website, actually, I think most of it comes through one. And so this is a ghost inspector test that will run with that will navigate to that page, lead the form and submit the form and give us back a score of whether it passed or not. So it will tell us if it failed or passed. So, you know, these are kind of the key actions that we have set up for most of our sites with the exception of the exception of the ghost inspector, this is more for a smaller portion of our client base uses this. But this is what a a pretty, pretty typical pipeline looks like for for the sites that we manage.

And could you show how how golf inspector looks like because I never tested it more? Of course, if it's not the problem.

Um, yeah, let me let me let me see if I can demo that. So the way that it works is I wasn't I wasn't ready for this, but I'll see if I can, what the way that it works is you have a browser plug in. And so like, well, I'll show you what it looks like to create a test, it's actually really neat. So if I'm on, I'm going to create a test with Ghost inspector. And it's, I have this is just a browser plugin, and I just say, I'm going to create a new test. And it's recording me now. So when I go to request a quote and fill in and you can pre populate these values too. So you can have you can have variable testing values, but this is just for the initial you know, recording. And as you record and submit the form and then you go to the plug in and say I'm finished recording and then you give the test and name then once that is created once the test is created, you can go back and you can see the individual, you know, you can see the individual, it captures all of the individuals. And it'll you know, it shows here's the here's the ID, the button ID that was clicked during the test here the values that were put in all of those different things. And you can go through and update those or modify these to insert variables or you know, change the I change what the testing sequence looks like. And it gives, it gives a lot of console output on the test as well. So it's actually the Yeah, so you can, you know, this is kind of what it looks like on the back end, we, we failed, but only because I did my test was on the live site, and the staging site is where this where this test. So But anyway, that's kind of, you know, a very high level how, how it can how it can run up for this, this type of functional testing?

Yeah, overall, it's really great. Especially when you don't have any experience with it, or you just want to start tests testing such things. And such a recorder is something very useful. Also, if you don't want to spend too much time, just creating all those testing suits when you can just record them. That's it. Yeah, it really looks, it really looks amazing. Okay, yeah. So I think that, that we covered that we covered everything. We have some questions from from from the audience. So first of all, when we were talking a bit about security, Viktor mentioned that, first of all, it's easy to handle security updates. His WAF is available on GitHub takes care about the attacks, he also shared the URL, so I will share it with you. So you can you can test it after the webinar. And he also asks, Do you run static analysis like PHPStan?

For some sites we do for some sites we do. It's not the it's not part of our, like, our entry level or baseline configuration, but we definitely have sites that that require that.

Yes, I mean, I can fully understand why, why it's not something required for for every landing page, for example. And another thing, most time consuming part is testing functionality after updates, how do you help save time with this? So you already showed the ghost inspector, but do you have any, any other tricks?

You know, if you're doing so that's our, like, automated testing shortcut. For you know, if it's, it's the type of testing that you're doing, manually, we have, you know, we have some internal configuration options that we, that we configure and set on our staging environments. So using things like environment variables, and, and making sure that because one of the things that inevitably ends up happening, if especially if you're like, you know, maintaining a secondary environment by, you know, migrating the data from the production site, the thing that inevitably happens is, you know, options that exist on the, you know, that exist on the live site don't need to be updated or changed in the staging environment. So we have a set of multi must use plugins that will define all of those environment variables, on a per site level, and we've gone through and like, depending on the plugins that are active on the the staging environment, it will define those values. So like WooCommerce, for example, has a lot of ways to define at a code level. Yes, this is a staging environment, use the staging, you know, use the test gateway instead of the, instead of the live gateway for this payment provider, or, you know, you can set those things at the code level. So we have the set of plugins to manage that. And then the actual, I find that that's the most time consuming part of testing is change, you know, adjusting all of the settings to work to be proper for staging rather than production. But if all of those things are predefined and set, then the actual process of completing a checkout or completing a form or adding products to the cart is a lot more is a lot more, you know, straightforward and a lot quicker. It's, it's all of the other stuff that happens before that, that seems to be the most time, you know, time intensive.

Okay, thank you. And another one. And the last one, I think it's custom plugin repositories for PHP composer what to do if vendor doesn't provide package for API?

Yeah. Have a, this is a great question and something we ran into a lot early on this answer might might get me in trouble. I don't know. But I'll it's something that's worked extremely well for us. So we have a let's see if I can post a comment. I think so. But I have, we use this, we use this library on GitHub called satispress, it allows us to build our own composure live our own plugin repository that we host. And then that can be referenced as the you know, as the code source essentially for, for composure so. And then if there's if there's updates available or updates needed, we just manually you know, replace the the package on our own internal server, and it works out great for as many environments as we need it.

This is this also the way I always use because it was so simple, it was just so simple to use, because that express is nothing else than the the plugin that converts all your plugins installed, plugins and themes installed on your WordPress to a composer repository. It's really amazing and so straightforward, a really amazing solution. And I see one more question from Mwale, could you share three of your favourite hosting platforms to work on bash? Specific specifically for client sites? I'm not sure is this favourite means favourites? Or the least favourite? So go for 3-4 favourites and the least favourites?

Yeah, that's a this question is gonna get me in trouble Mwale. So, no, I mean, the providers that we have had the most success with both from a performance standpoint and a and, you know, being accommodating to workflows, and also on the support side of things like, you know, anybody who's well versed in this world knows that when they, you know, there's nothing more frustrating than being like identifying an issue at the environment level, and going to the host and saying, Hey, here's an issue we're having. We know, it's not a code a WordPress code issue. Can you please like, here's where we're seeing the issue? Here are the logs that, you know, indicate where this error is happening? Can you please, you know, can you please fix this? And having them, you know, reply back with, well, have you tried disabling all of your plugins? It's like, no, anyway, the hosts that we've that we found to be more understanding and more able to quickly identify, this is something that needs to be escalated. And that have good reliable performance, our WP Engine, Pagely, Kinsta, the three of those, and Pantheon as well, I'd also include in the same group, they have a much different workflow, a lot of the things that I've talked about, are definitely doable, but doable in a different way on pantheon. It's, it's a, it's a whole, you know, they they bundle a lot of CI/CD into their, into their platform as well. But those are the probably the four that I would say, you know, we have had the most, most success with over the years.

And the one that gave you the most travel, I will try to force

you just use really trying to get me in trouble. No, I mean, any type of you know, low resource, shared hosting provider. You know, cPanel is a little bit of a swear word around here. Just because not because cPanel is bad, but because it's typically an indicator of you know, this is the company who's trying to cram as many websites as possible onto a server that doesn't have enough resources to run it.

Yeah, yeah, I fully understand that. Okay, Ryan, so at Thank you very much for sharing all your knowledge with with us. Also be when we started the webinar, we asked one question on our YouTube poll, are you outsourcing your WordPress maintenance? And everyone said, No. So

I hope that's true for this audience. Yeah, that makes sense.

Yes, yes, because that's true. Also, I'm also not surprised that this audience is trying to do it all by themselves. So this is something something really normal. Also, in two weeks, we will have a great webinar about documentation, why your documentation sucks, and what to do about it with me. And that's up from exe WP. If you want to stay on top of our upcoming webinars, don't forget to sign up to our meetup comm group. It's called Buddy CI/CD group, you will be informed about every new webinar that is up and coming. And also remember to subscribe to our YouTube channel, you will also be informed and you have a chance to watch many interesting webinars, like for example, this one again, because it was very informative. So it would be great to watch it again. Right. Okay, so thank you. Thank you, Ryan, once again. Thank you. Thank you all to everyone in the audience who listened to us and yeah, I wish you all a great day or night because I'm not sure in which time zone you are all in. So, bye, everyone.

Thanks for having me. Appreciate it.

Thanks. Bye