 Oh, hello. I think we've got sound now. Perfect. Cool. So I just wanted to start with a quick introduction to myself. My name is Chris David Miles, as she said. And as far as these slides go, feel free to take notes. But also, I published all this information on my website. You can just Google my name, Chris David Miles, and pull it up. So yeah, one of the questions that I get a lot when I go out to WordCamps with Bluehost is I've found a lot of people are actually introduced to WordPress because it's such a great platform for editing and managing content. A lot of people are introduced to it at the step where they're taking over a website. And I've found a lot of people, hey, I learned about WordPress because I'm going to be in charge of this website now. And now I need to figure out how this works. So it's kind of like learning to drive. But imagine if you were learning to drive and the car was already barreling down the freeway. That's kind of the experience. So it's a lot to take in. But before we get started, I have three questions for the group. So raise your hand if you've used WordPress before. All right. Have you ever built a website before? And are you inheriting a website soon? Cool. I just want to get to know the group a little bit and see where we're at. So now I know you guys know me. Awesome. So first, the most important thing, I would say, is don't feel overwhelmed. And everything that we talk about today are just some things to consider. There's not a one-size-fits-all recipe. There's not one thing that you definitely need to do 100% of the time or the reverse. So this is certainly not gospel. But there's plenty of things, no matter what the handoff looks like, that won't matter. So the first thing that we're going to want to do is do a lot of investigative work. This is when you're probably going to turn into a little bit of a detective with this website. There's a lot of things to find out so that you understand the responsibility that you're taking on. So the biggest thing initially that you need to understand is what exactly is being handed off? And just a website is probably not enough information because there's a lot more to it than that. For example, who owns the domain name? Is it the owner of the business? Is this a business? Even if it's just for a friend, you need to know who it is so that six months from now, when it's ready to renew, it's not a surprise and it doesn't suddenly go down. Who owns the hosting? What third-party services are in use for this website? Are you using a shopping cart that needs to connect to PayPal account that maybe needs to be renewed? Are you using a paid theme that needs to be updated periodically? Are you using analytic software or monitoring software that needs to be checked on? So you need to know what accounts exist, who set them up, so that it doesn't belong to the last developer of the last person that worked on it and you're hunting them down six months from now. So if you know all of those things going into it, it's going to be a lot lot easier and a lot lot faster. Another one that people often forget about because it's not directly related to the website is the email address and the email address associated with the domain name. So think about if I've got chrisdavidmiles.com, I've got to think about all of the email addresses that end in at chrisdavidmiles.com, contact at admin at. Who owns those? Who has access to those? Because if it's the old developer or if it's the previous owner, if it's whoever it is before, are you able to get into the website by resetting the password? And if it goes there, they can still get in. So those emails are often an avenue back into whatever level of access. So make sure that if it's a business account or whatever it is, that you have access there as well. And a lot of these questions, you're going to find yourself talking to the original owner if that's possible. Sometimes it's not. And the handoff itself, ideally, should be something like this, to where there's still work going on, there's still a plan, there's a handoff. Everybody's on the same page. But I've never seen a handoff that looks like this. Most of the handoffs I've seen look kind of like this. But the good news is that no matter what the handoff looks like, the process of accepting your responsibility is relatively the same. So as much as possible, try to cooperate with whoever had these responsibilities before. But you can't always. So find out what you can. Talk to the previous owners. Talk to whoever the stakeholders are for this project, this website, this app. And see what you can find out about access and make sure that whatever you're agreeing to, you know what you're agreeing to. You know what you're signing up for. You know what your responsibility level is so that there's no surprises down the road. So with the handoff itself, that is oftentimes somewhat tricky because you need to coordinate some very secure things between people. And one of the biggest mistakes that I often see are people emailing passwords to each other. That's not the worst thing you can do, but it's certainly not the best thing you can do either. There's a lot of services that make handing passwords off a lot safer and a lot of ways you can encrypt your passwords. Things like LastPass and things like that to where you can share passwords with people without having to email them. Because if you're emailing them, even if you update them or things like that, they're stored in a place where people can intercept them over the wire. And it's important that all of those things get updated, however you pass the information, all of that access gets updated as soon as you get it. And don't think of it so much as that you don't trust the previous people or that you're trying to lock them out. That's not what it's about. You're trying to mitigate the risk of this site or this project getting hacked. Because if whoever owned the website before, if their email gets hacked or if their access gets hacked or their computer, whatever it is, your project is now at risk because they have that old password that still works if it hasn't been updated. So the principle of least privilege is you only give the sort of access that grants the exact level of access needed for everyone to do their job. So if somebody's just a subscriber, make sure they're only a subscriber in WordPress. Does everybody need to be an admin? Probably not. And only the level of access because it's not just are these people gonna do something bad, but if somebody that isn't them or somebody that shouldn't be logged in gets access to their account, how much privilege do they have? So if you minimize the amount of access that exists in the world, you're minimizing your risk. So it's not about locking people out. It's about protecting your project and protecting the site that is now under your control. So be sure everything gets updated. Change the passwords, change the access, whatever you need to do. And that's more than just the WordPress access. Although that is important, yes, definitely change the passwords for user accounts and things like that. Change the WP admin main email where the resets go, but also stuff like hosting, right? Stuff like email, stuff like the registrar, the domain, all of those things. If the passwords don't change when the person is handing them off, then you've essentially doubled the risk because now two people can get hacked, right? And so, you know, then walk through and just sort of audit all of the security. What are all the ways? What are all the things that you have access to? Does anyone else have access that probably shouldn't? Right? So once you've executed that handoff, once you have all of the keys to the kingdom, then the first thing I would recommend doing is taking a backup right then and there, right? Before you've made any changes, before you've really made any improvements, you want a first starting backup. This backup is going to be very important, perhaps more important than the backups you take in the future, right? And the other thing is you're gonna wanna test this backup. You're gonna test this backup in a way you probably won't test the rest by trying to restore it, right? Try to use it. And by restore, I mean actually try to use the backup. Imagine you have to take the website from whatever state it's at and use that backup to restore. And the reason I suggest trying and going through that process is you wanna make sure your backup is useful, right? If you go to restore your backup and all you've got is a zip file that you're not really sure what to do with or if the backup is a huge hassle and it's all this process or if you have to call someone or if you have to do something to get that backup restored, you need to know what that process is, right? So that it can be streamlined. And if it's so complicated that it takes hours and hours to do or if you don't know how to do it, that system of backing up isn't probably gonna work for you because your backups are only as useful as your ability to restore them, right? So test the restore process. See how useful it is. See how easy it is. Hopefully it's just clicking a button, right? But maybe it's more than that. And if there are problems that come up, you know about it then and not when you actually need the backup, right? Because by then, hopefully it's quick. Versioning is another thing that you can do with these backups or you have different versions and you can write down what you've changed with each backup that you take. That way, if you need to restore just parts of things, it's a lot better. Not everybody has to worry about versioning. It matters a lot more if you're dealing with the code itself, right? But at least if your backups are either labeled or organized in such a way that you have a date associated with them, that's gonna be the biggest thing because you can even just have a document that's separate where you say, hey, I took a backup at this time. So the backup that happened on Tuesday the second is the backup that happened right before I changed the theme. You can write that down and then you know in the future when you need to go back what that backup is for. So after you have that first backup then you're kind of in a safe place because no matter what happens and of course you've restored it at this point you know that the restore process works. You're kind of in a safe place because no matter what you do you can always go back to that point, right? And so you can be a little bit more creative and you can be a little bit more adventurous at this point and you can start making plans for improvement. And the reason I say plans plural is because there should be more than one and it should be available to change, right? So things are gonna change, requirements are gonna change and your ability to work on the site may change, right? The amount of time that you have invested now may not be the amount of time that you can invest in the future and that's okay, right? So it's okay to be flexible but it's also important to have plans for improvement for your website and oftentimes I find that when transferring a website to another person or whenever there's a handoff it's because something has changed. Either the owner isn't satisfied with what's happening with it or the owner, you know, the previous developer no longer needs to do work on it. Whatever the reason is, usually it's because something to do with improvements or maintenance needs to happen, right? So you have an opportunity here to make things better. So one of the things I like to do when I'm preparing slides, when I'm doing things is I look for stock art and I look for the corniest stock art I can find. This is, I think, the corniest image that exists in all stock art and that is somebody taming the concept of improvement. So I just thought I'd throw that in, that was fun. So once you have an audit of all the accounts that exist, you have an audit of hosting and your domains, decide if everything's a good fit, right? Does it make sense to be hosting your website where it's being hosted? Does it make sense to have your domain where it's at? Is your domain in your hosting in different places? Some people think that's a good decision. Some people think that's a bad decision and it's a case by case thing. So don't assume anything was done the right way. Oftentimes when things get built, compromises are made, shortcuts happen and sometimes things are just a preference of whoever built them, right? So look through what you have and see why are these things this way? Does it make sense to have my domain here or is this just what the last person that knew about it had heard of, right? So the next thing to think about is look for ways that you can optimize. Look for ways that you can improve and this is when you really start digging in. This is your biggest audit that you've ever done on anything, right? So you start looking for ways to make things faster. You start looking for ways to make things more scalable. You go through and look at all the plugins. Do you need all those plugins? Maybe you do, but maybe you don't and maybe they're not the best plugins. Look to see if your plugins have been updated recently, right? If this is a plugin that hasn't changed in five years, maybe it's not a good one. Maybe it is, right? Look at the review. See if it's still working or if it's been tested with this version of WordPress. Look through your theme. See if there's any updates available. At this point, it should be clear where your theme is from because if it's from WordPress.org, the last audit would catch that and if it's a paid theme, we should know about that account and at any point you still might find more things that somebody in the past paid for or more licensed things or stock art. You might even find something that's copyrighted that maybe shouldn't be there in your audit, right? So you'll still find those things and add them to your original audit. But as you're going through, just see what can be improved. Check on the analytics if it's there. If there's no analytics, add analytics. You're gonna need it. Add monitoring, right? So that you can know if and when your website goes down. If you've got a shopping cart, add monitoring to your shopping cart so that you can know and you can get a text message. You can get notified when, hey, suddenly nobody on phones can check out. Something happened, something changed and you can go in immediately and do that. So monitoring is gonna help. Check your SEO. Can you find your website on Google? Just try searching for it. Can you find it? What are the things you're trying to rank for? Check on the site map, the robots.txt, all of that stuff. Audit your content itself. Is this a store? Or is this a blog? Does the content that you have make sense for this? And so after you go through all of your content, all of your plugins, your themes, and you're cleaning stuff up, you're making things faster, you've got all these things. You don't have to make too many changes, but you've got somewhat of a plan. You know all of the ways that you would improve things. And you've got a perfect image in your mind of I know exactly what I'm gonna do. Well the next step is going to shatter all of that because then you're gonna talk to all of the stakeholders and you're gonna hear all of their ideas of what needs to change. So maybe the only stakeholder is you. If that's the case, then this is really fast and this is really easy because you already know what you want. But a stakeholder is anyone impacted by the success or by changes in your project. So talk to the owner. Talk to the people that are going to be working with this, the people that are impacted by this and tell them about your plans. Tell them about what you plan to change, what you plan to improve. Get their feedback about what they think is the most important things, what things you might wanna do first, what things maybe don't even really matter as much as you thought. So that you have a way to measure the success of whatever you've been hired on to do. Or even if this is just a favor, if you know that one thing matters way more to the person you're doing this favor for, you know that that's the more important thing to start with. So yeah, as you're discussing these things, revise your notes, revise your plans. So that that way you know exactly where to start and where to begin. And then next we have staging and deployment. So with staging, who's familiar with what staging is? Okay, yes, so with staging, and if at any point you have questions, feel free to raise your hand. So staging is when you change something about your website in a state that doesn't actually affect the real one. You can make a copy of your website, right? And that copy is the one that you work on. And there's more than one way to do that, right? Sometimes you can make a local copy that's just on your computer for your website and you can work on that. And as you're making these changes, if something goes wrong, if something happens in a way that perhaps you don't expect, that's okay because it's only the copy that you're working on, right? And this goes back to kind of the versioning and the backups as well. If you know what you're changing and why you're changing it because you've been talking with the stakeholders, right? You've been, you know, you have all of your plans outlined, you know what it is you're gonna change, right? So one way is to start locally. There's also a lot of times online ways you can do staging and deployment, right? There's free tools out there, there's paid tools out there. Oftentimes, if you've got a very WordPress-centric host, they will offer staging as part of what they do, right? And you can set up this copy of your website and work on it and show it to your stakeholders, right? And you can show it to the people that you're working with and see is this what you want. Recently, there was a change in WordPress where you can actually make changes in Customizer and save that as a version and save that as a draft and give people a URL that they can go and look at that version of what you changed, right? It's a very simple kind of rudimentary version of staging, right? With a more complete version of staging that you can get with more third-party tools, you can do that with the entire website, not just with Customizer, right? So as you're making these improvements, you can know what to do differently. And when you're ready to deploy, then that staging copy replaces the original, right? Now, at any point, your monitoring is going to be telling you about your success and your analytics are going to be telling you about your success. So there's a way to test things and have that different versions of your site and some of those things, you can have your audience test it for you, right? Because some of your stakeholders are going to be the actual audience, the actual viewers of your website. And that's called A-B testing, right? You guys have probably heard about that. That's where you show a portion of your visitors one version of a website or one version of what you're doing, right? A portion of your other visitors will see the original version. And you can compare with metrics what the differences are, how people click through and how people do that. Google Optimizer is one that I use and there's Google Optimizer plugins. There's also other third party tools that will let you do this, right? So that way, if you're able to make small changes to your website and you're able to make these small improvements, then you will know what performs better because you can say, oh, well, in this version of the website, 15 more people, or 15 more percentages of people have clicked through to the cart. This converts a lot better. This doesn't convert as well, right? And you can test selections of people and say, okay, so for this group, I want to market things this way. For this group, I'm going to have a different landing page, right? So if you understand what the audience is and what the impact is of the different plans that you have, your staging and deployment will look a little bit different with this A-B testing. So another thing to think about is what you're going to do about security and how you're going to audit things. So now you have an additional audit. You want to go through, and now that you know where all the accounts are, you're going to want to go through and check on how are the ways that people can interact with and enter this website, right? Because now it's your responsibility to make sure that it doesn't get hacked, right? So there's a lot of things you can do there, but you're going to want to check, you already know who's allowed to log into the hosting account. You already know who's allowed to mess with the DNS settings and all the stuff with the domain names. But what are the other things inside your website that let people interact with it? And what you can do is you can either, you could actually set up automated malware scanning on your site, on the front end or the back end, right? And there's a lot of different companies and services that will provide this. Some of them are free. And you can look for WordPress plugins that do this. You can get professional services that do this. And they're going to be scanning your website for malware, and they're going to be looking for different vulnerabilities that will allow people to come into your site. So when you secure things down, you're not going to get hacked. But if you do, you'll be okay because of that first backup. So at any point, you can always go to that first backup, right? With a store, it's a little bit more tricky because you have problems like order history and you have things like that. So you want to make sure that whatever you do that if you have information that has to stay current and that has to say that's sensitive, that that's either not stored on your website or that that's backed up in a different safe way so that when you do restore from your backups after a hack or after something like that or after a version change that you're not overriding that information. So one other thing to think about too when you're executing a new website is try to think about the way that it looks and the way that things convert based on how it looks. The theme that you have is a theme that was chosen probably based on the previous developer, right? So the previous developer decided what they wanted to build, how it was gonna look. Maybe there were stakeholders involved or maybe not. But at this point, you have the ability to test and see if there's something better, right? You don't know if it's necessarily the best choice. So when you're looking through does this make sense for your audience, right? Does this make sense for your content, right? Different types of websites are gonna require different types of themes and different types of interactions, right? If this is a website that is not compatible with mobile, you're gonna be missing a whole bunch of your traffic. So make sure your theme is compatible with mobile devices. Another thing that that's gonna impact is SEO because Google will only show certain results on mobile and they'll show certain results on desktop searches, right? Some of that will overlap, but if you're on a desktop device or if you're on a mobile device rather and you search for something in Google, those mobile websites are going to rank much, much higher. So it's something to think about after the handoff. Is this compatible with mobile devices? The automated testing that we talked about before, one of the things you can do is you can have the testing set up to check from different types of devices. Because sometimes what happens is the different types of services, the different types of interactions will be different for different connection types and for different places in the world, right? So if a majority of your users, right, let's say you're marketing to users that are primarily using phones, well then it really, really matters that your users can access this on a phone. It really, really matters that you're mobile responsive. If your users are of a certain demographic or certain age, it really matters to your monitoring that it's accessible from those locations. So from there, something else to think about is that with all of these things, it's going to take time and it's not all going to happen right away. So make sure that when you're discussing these plans with the stakeholders that they understand what the timeframe is so that you can adjust things, because after the handoff, as you're making your plans and improvements, after your versioning things and after your planning for improvement, it's not all going to happen right away. And one thing that I think is very important, especially if you're new to WordPress, is that you don't get overwhelmed because there's a ton of stuff to think about. Even just this couple of things that we covered in this talk, it's important that you don't feel like you have to know everything and that you don't have to solve everything right away. There's always time. You always have your backups to go back to, right? You have the different versions of your site that will help you out. So you don't have to know everything. You don't have to know everything all at once and your users will actually tell you what you need to change, right? If you have enough feedback and if you have those analytics, that's what those numbers do, right? So even if it feels after this handoff, like the whole world is kind of weighing down on you and all of this responsibility is on you, don't be afraid to reach out for help. And that's probably the most important thing that I can say for people that are just getting started with WordPress is don't be afraid to reach out for help. There's a ton of help resources that exist. WordPress.org is one of my favorites. It's open so anyone can contribute. There is also services. Professional services that exist where people can help out with WordPress and your users will all tell you what's important. Your users will tell you what you need to do, what you need to change. There's about 10 minutes left. So I'm gonna open things up for questions but you can do it. Don't be afraid. It's gonna be a little overwhelming at first if you're new to WordPress because there's a lot of things to learn. There's a lot of things to think about. But you can do it. So Q&A. Yes. And why don't I actually bring you the mic so that the rest of us can hear as well. Touching back on staging and deployment. I have a local WordPress installation on my computer but it's multi-site. Does that make things more complicated to develop in a local environment and then send it live? Yes, that's an excellent question. So with multi-site, for those who are unfamiliar with multi-site what you can do is you can have multiple kind of installs of WordPress that are all in the same install. So you have one master site and sub-sites from there. If you install a plugin on one site, you're installing it on every site. You can activate them separately but changing things in a multi-site environment is a little bit more tricky. So what you're gonna wanna watch out for is plugins that are activated network-wide and the changes that you're making. See if the changes that you're making are going to affect all of them. If they're all using similar or the same themes, changes on one theme are going to impact all of them. So even if it's a more logical thing like functions.php or something like that, you're gonna wanna make sure this works on everything. So if you've got a multi-site, hopefully your backups are encompassing all of those and your versioning encompasses all of those. Yes, so you can set it up to have multiple databases. You can't even have just one site that's not multi-site be sharded across databases but in the cases of any types of backups, in the cases of any types of restoring, it's important that both your files and your database are restored together because otherwise you're gonna have kind of a mismatch, you're gonna have things missing. One additional thing to think about with that though is that if you're storing information that needs to stay current, that that's always part of your restore process if it's stored in the database because otherwise you're gonna restore and some of your posts are outdated. Otherwise you're gonna restore and some of your store items are outdated. So it's just something to keep in mind. The best thing I can recommend is to test it and see how it works on your local setup. If it's not something that works, change what you're doing. It's certainly easier to manage from the perspective of versioning. You can do just about anything with WordPress. There's almost nothing you can't do. I have my own question but a follow-up question to his too. Do you, this might be a little bit into the weeds but with multi-site, I have not found a staging system where I can stage a change on one site and then push it live without overriding anything else, any new work that had been done on some of the other sub-sites. Do you know of a way to do that? That's my related question. With that, what you're working with is actually just a symptom of multi-site that a change, certain changes to one site on multi-site are going to impact other sites. That's going to be the same with backups. That's going to be the same with restores and that's going to impact everything else that you're doing. It's just one of the hazards of multi-site is that it's set up so that they all share common themes, common plugins, and there's a lot of shared functionality between sites. Just an example of this, if anybody else cares and hopefully somebody does. I have a team in Madagascar working on a site. I have a team in Cambodia working on a site. If we're gonna do some changes on the site where we're working in staging, I have to embargo changes in every country. We have to say, don't do any changes because we're working on a staging and we have to make sure. So that's the solution I'm looking for. I'm looking for a solution to that problem. The other question is, if you inherit a site that has a lot of plugins, the previous person was this plugin crazy. There was, they didn't find a plugin. Yeah, they never saw a plugin they didn't want to try. And lots of design work. And you're trying to coordinate the design, bring some sanity to the design. But it's a site with a long history. I haven't yet found a great methodology to make sure that when you do site changes that you can clean the previous content and get rid of dependencies and sort of track that. So with that, I wanna make sure everyone heard. If you inherit a site with way, way too many plugins and there's a whole bunch of stuff, there's several things I would recommend. One, after you take your initial backup, there are tools that will help clean things out of the database. WP Sweep is one that I particularly like. But there's things that you can clean out to make sure that that's no longer in the database. But also, see if there's ways you can simplify. If there's a plugin, usually the plugin name will say what the plugin does, or the description will. And if you can find a simpler way to do that, then that might be better. And look into why those plugins were installed. Not so much what they do, but why they were there in the first place because they might be solving a problem that no longer exists. Or they might be solving a problem that no longer exists in WordPress. Sometimes WordPress changes in such a way that you no longer need certain functionality or you no longer need certain things. Because WordPress is a lot better now than it was in the past and it's gonna continue to get better. So there's plenty of reasons why you wouldn't need a plugin now. But if you have a staging environment and you're able to do all of the testing to go through everything that matters with your site, be that a cart or loading up pages or whatever it is, you can always test things, take away plugins and see what still works, right? And simplify that process down to where maybe you don't need all those plugins. Maybe you can do some of these things in a theme. Maybe there's something in a plugin that should be part of a theme. Or the reverse is something I've seen a lot more or something in a theme that should probably be a plugin. But it's just part of your audit and what you're trying to do. I think we have time for maybe one more question. Hi. Back at the time where you went through the three-step process, audit, looking for ways to optimize talking with stakeholders. And you made a decision to do, let's say, 20 changes. And you go ahead and you implement 10 changes. Do you ever make a backup in the midst of that? And then with your backups, do you ever journal your changes? And also the plan that you're writing up, does that ever act as a checklist? And then also once everything's done, the backup that you make at the end to preserve what you've completed, if you can talk on those. Thank you. So just really quickly, because we're almost out of time. Backups are a good idea for any time you make any major change. Any change that you would want to revert, any time something happens, a lot of times they can be automated such that they're automatically running every period of time, right? But with what you're saying about major changes, it is good. The reason in the list, you wanna make sure that you're talking to stakeholders before making these changes is, you don't wanna use your backup because of a lack of communication. You wanna use your backup because something happened that we didn't think was gonna happen, right? So it is a really good idea. I liked what you pointed out about journaling and versioning your backups so that you always know what each of these backups are because as we talked about previously, a backup is only as useful as your ability to restore it. If you don't know which backup does what, they're not really that useful to you, right? And that at each of those points, once you get it to a state where you've accomplished some of those goals, excellent time to take a backup. Does that kind of answer your question? Yeah, you don't always have to backup 100% of everything all the time, right? Sometimes it's smart to only backup certain changes, right? I think we're out of time. Thank you.