 I'm going to get started in just a second. Give everybody a chance to sit down. All right. So welcome. This is going to be a talk about WordPress workflows. It's geared towards beginners, but I'm hoping that there'll be a little something for everyone. I'll take questions at the end. I have quite a bit of material to go through. So if you don't get to ask yours, definitely come and find me afterwards and we can talk about this. I'd be happy to. All right. So just a little bit about me. But you know, who's giving this talk? My name is Anne. You can find me at redrambles on Twitter. I'm a mom of four, two in their 20s, two under eight. I don't know what we were thinking either. I'm a self-taught developer. I teach and I like to mentor a lot and I believe in that relationship. I think that there's a lot to be gained both as a mentor and as a mentee. So that's something that I strongly believe in. All right. So before I dive into the workflow bit, I'd like to share a story with you of how I got started. So I got started with WordPress several years ago now, and I think it was a fairly common beginning. I had a small business. I needed a website. So I did a bit of research and I quickly settle on WordPress as the best solution. So I read some articles, I look at some videos, try to get the lay of the land until I feel confident enough to go ahead and get a site up on a live server somewhere and start working on it. So I get a little hosting package with a one-click WordPress install. So they set up the files, the database, the link everything for you and they just hand you the key. So I log in and I carefully choose my theme. It was one of the first responsive ones. I remember that. Then I lovingly enter all my content in my images, all six pages. I was very pleased. I get my custom domain, I hook everything up, everything's going swimmingly. I guess just as I'm about to break out the bubbly and call all my friends and say, check out my website. I did this thing. I was like, there was this one line of text in the footer. That was really annoying me. I just could not figure out how to change it. I wanted to either make some edits to that line or just take it out. I hadn't found a footer field anywhere in any of the pages that I had been editing so far. So being excruciatingly aware that I was very new to WordPress, I figured I just missed it. So I do a little research and I find out about this thing called screen options. So I make sure that all the fields are visible in all of the pages that I had been editing so far, but still no footer field. So I tell myself, okay, Ann, you're are going to look at every single menu item before you send a post somewhere or an email to make sure that you didn't miss this thing. So I click on every single thing, a child menu, a sub-child menu, click, click, click, click, click until, well, at some point, look what I've found. I remember being like, what? There's an editor? How come I didn't find this before? Has this been here the whole time? This was before the days of the big warning. Now, if you click on that link today, you get a box that comes right out at you that says something like, whoa, whoa, whoa, you sure? You want to do this? I'm paraphrasing but more or less, that's what it says. But there was no such thing back in the day and I was, so I clicked on it and in fairness, I did hesitate. I had a moment where I was like, oh, I feel like I'm intruding on a private moment or maybe, I'm witnessing the underbelly of WordPress, maybe I shouldn't be here. And so I was about to bail, but then my eyes slid down the page and they fell on the word footer.php. So you understand after all that, I wasn't gonna leave that alone. Of course I was gonna click on footer.php, so I did. And okay, it wasn't a huge file but there was a lot in there that I hadn't seen before but I did find that sentence, it was there. And so I was like, yes, problem solved. I make a little change, I save, I refresh the site. The good news is that that particular sentence was totally gone, not there anymore. The not so great news was, so was my entire footer. The whole thing was gone. No more cute little footer widgets. That little footer menu I liked, it's totally gone. So I was like, okay, what happened? I didn't go in there and trash everything in that file. So naturally I go back, I go back in the editor and I try to undo what I did and that doesn't work. And so I think I lose my mind a little bit there. And I start to click around different files inside the editor, making little changes. Of course, by the time I refresh the site a second time, that's what I get. A big ol' nothing. White screen. And I remember frantically refreshing and refreshing and hard refreshing, clearing the cache, different browser, incognito, my phone, anything that would deny this white screen and alas, it remained. And I think at this point, it's probably when I made a strangled, mulling sound, because my partner ran into the room and was like, what is going on? And what is going on, everybody, is that my workflow sucked. It was really bad. So we're gonna talk about workflows now. So that hopefully you are spared such a situation. So that was my intro segue. So these are the items we're gonna look at today and disclaimer, any one of these could warrant a full talk. So it's going to be a brief, higher level overview. But my goal is that you are going to understand what these are, enough about what these are and why they deserve a spot in your workflow. All right, so let's get this out of the way first. Like, what is a workflow? What does that mean for me? It's a process by which you make edits to a live site. So it could be just getting that site up there, live to begin with, but every subsequent change that you're going to make, the how you go about doing that, that's what I consider part of your workflow. They vary a lot. Some of them are very simple, two or three steps only. Others can be a dozen steps or more. So it'll really depend on what kind of project you have, do you work with a team, how comfortable you are with many of these tools. So we're gonna look at one that's a pretty solid middle-of-the-road workflow. So again, this is what we just saw before in little icons. I'm just gonna take a breath, thank you. So we're gonna look at local development environments, solid text editor, the command line, WPCLI, Git, GitHub, staging sites, and a recovery strategy. Okay, why? Why would we wanna use a workflow? Well, if my little story didn't convince you, it does make you more efficient. Fewer errors slip into production, which is a big one, and it increases your confidence as a developer, which is probably my favorite reason. Let's begin with local. A local development environment, so what is that? It's a server environment that exists on your computer, right? So WordPress uses PHP. PHP is a server-side language. You need a server to work with WordPress. This allows you to set up a server environment on your machine instead of having to use the one that's provided by your hosting company. Okay, so why do you want one on your machine? Well, because what happens on your computer stays on your computer. So that white screen is between you, your computer, and the bottle of wine. Nobody else needs to know about the white screen. You can just take a breather and then fix it and then come back to it later, and it's all good. It's a lot faster, right? So you have direct access to the source files, you just edit them in your editor of choice, save, refresh, and boom, you can see whether or not you've been successful instead of having to move things over to a server. You can work offline, so for some people, this is a big one if they travel a lot or if they work in other areas, cafes, or places where Wi-Fi may be a little shoddy, so this is a plus. You don't have to pay for hosting, this can be free. There are some local development environments that will cost, but most of them are free. It allows for a much wider range of tools, some of which we'll discuss today, and it definitely helps grow your confidence as a developer, so you can break things, fix them, you can experiment, right? What happens if I comment this out or if I change this template tag for this one or what if I remove the WP underscore footer tag, bad idea, you'll see what happens. On your local environment, you can do that. So it gives you that safe space to grow your skills and deepen your understanding and knowledge of WordPress. You have a lot of options. There's some that are more beginner friendly, and there's some that are more advanced. The ones that are advanced are basically, they need a bit more configuration and they usually heavily rely on the command line. So you can find these, most of these are free, and if you're not already working locally, I would, I'm happy to help you with that if you want later on. If you were to press me as to which of the steps that we're looking at today were the most important, this would be the one that I would choose. All right, next up. Okay, we have a nice, safe, private space to work, but what are we gonna use to work with our code? We need a text editor. So I presume that most of you already use one, but it's such an important part of the workflow that I'm just gonna take a moment to talk about it. So text editors are IDEs, which is short for integrated development environment, which is basically a text editor with superpowers, a bit more functionality. It just allows you to edit code. And if you are either thinking of picking one up, if you're just getting started as a developer, or if you're thinking of maybe switching to another one, there's a few different things that you might wanna keep an eye out for. Cross platform is always a plus. Rich plugin package environment is nice. Speed and lightweight is particularly important, at least to me. I really dislike having to wait on the text editor to open something, save something. It interrupts the flow of my thinking and you really want that text editor to be sort of like an extension of your brain. So you wanna have something snappy. Customizable, some people really like. Git integration is very handy, but there's a little asterisk here. I don't know if you can see it, but down there it says does not replace the command line. So what I mean by that is that text editors, I'll use the git integration to have some general overarching information. What branch I'm on, what files have changed since I last committed that sort of thing. It's super useful, of course, if you need to resolve merge conflicts. But anything else, any git command I will be using in the command line. And last is terminal integration. So you actually can just work in the command line in the actual text editor if you'd like. Some people like to remain in one environment, so this one might be something to consider. Lots of options again. Here's a few, we've got visuals to your code. That's what I'm using right now. Sublime text, Atom, Coda, PHP Storm, that's an IDE. Brackets, there's lots more. But so basically you'll just wanna consider when you're choosing this, which of those points are most important to you and make sure that they meet those standards. Quick recommendation, when you do make a choice, try to stick to it for about three months if you can. I know it feels really long. Because there's always like a shiny new editor that you might wanna try or something that your friend is using that looks cool. But you wanna get out of the where is this thing again or how do I toggle the sidebar or where's the fuzzy search and all of that stuff. You want to be able to just have that be second nature so you can truly be productive with your text editor. And that only comes as a virtue of time. So you need to give enough time for you to feel that mastery of your text editor. There's a lot of tips and tricks and best practices out there like a stunning amount. People who have been using your text editor for way longer have written stuff about it. Lots of gems that you can find that helps you level up and leverage that knowledge quickly and put it to use. And if you do a search again with that in mind but with your particular language like PHP for example, again you're gonna find some really good tips. Like this is a great theme because the syntax highlighting is awesome or whatever. Lots of good things that you can find with that that allows you to leverage the strengths of your editor. Okay, we have a safe space. We have something to work with. Now we're gonna jump to the command line. Why bother? So I get a lot of pushback about this sometimes because folks think there's so many great GUI apps out there. Why would you bother with the command line? So GUI is short for graphical user interface so what you would typically use with the mouse. And the truth is that understanding the basics of the command line is absolutely essential to becoming a skilled developer and being a WordPress developer is really no exception. There's a lot that you can do in the tunnel so like a ton, basically nearly everything. But we can look at some of the most common things so it is the most flexible and powerful way to interact with your computer. You can manipulate files extremely quickly. You can download things directly on the command line. You don't even have to open your browser. Use SSH so that's gonna be really important depending on where it is that you're hosting. Search features are excellent. You can do things like turn on or turn off hidden files on a Mac and little things like see what's running on your computer if it's getting really kinda slow or sluggish. You can run a quick top and then see what's eating up all my memory and then maybe kill that process if you need to. And all right, really why bother? Well, there are some things that you can only do in the terminal so some of those like you will need to install software as a super user sometimes. You might need to run some quick scripts but things like bash scripts, package managers or tools like WPC-LI, you're going to need the command line in order to use. So here's a little joke that I'm hoping you get. Yay, some laughter. For those of you who may not get this, sudo is short for super user do. It's kind of like the nuclear command. It's like telling your terminal you really, really, really, really mean it. For me, it's kind of likening it to when my mom used my full name for something. You know, she'd be like, and clean your room. And, and Jennifer Cascarano, clean your room now. And I knew I had to move because I'd be in trouble. So sudo is kind of like that. They really mean it. So it's not all business. There's a few fun things you can do. You can have your computer speak out loud, even sing, kind of. If you use this, if you use a Mac, this is for a Mac. I highly recommend that you pop this in. I'll have slides to share later. It's very funny. You can also ask the kids to do things with the computer voice, which seems to be more effective at times. Pro tip. You can play games if you like these types of games. So that can be fun too. So this is just my attempt to woo you to use the command line if you do not already. All right. Next up on our list, WP CLI. How am I doing for time? Okay? Okay. WP CLI. So what is that? It is a command line tool, see, useful, for interacting with and managing your WordPress sites. So here you have just a little example, very simple command, WP theme list. That's exactly what it says. It lists the themes that are on that particular site. It shows me which ones they are, which one is active. If they need updating, apparently they all do. What version they are. And you can do a ton of stuff, but this is what it's gonna look like, the output of WP CLI in your terminal. So this is one of the best arguments in favor of using the command line with WordPress development. So what can you do with that? You can check which plugins are active, update core themes, plugins, export your database, run a search replace, which includes serialized data. Yes. It creates, you can create a user, update a password, delete all the comment spam in one command, create a child theme. You can do an enormous amount of stuff with WP CLI. I also have a couple of tips. I'm not sure if you can see them well, otherwise on the slides later you will be. Aliases here are super useful because some of these commands tend to be quite long. So if you have one or two that you keep using, you'll wanna map them to an alias, and an alias is basically kind of a shortcut. It's a name that you give, it's like a variable, right? It's a name that you give to a long command and you could just use that name instead. I have a couple here to show you examples that I use pretty frequently. The first one is just to check everything that might need an update. So I have an alias that will map to this command and it'll just immediately tell me, does core need updating, does do my plugins need updating, do my themes need updating, and I'll know right away. Backing up a database, also nice, you can give it some different options, like I'm excluding a couple tables there, but there's other things that you can do. And I also have an alias for that command. So if I were gonna run that command right now, the result of that would be something like success exported to backup underscore 2018-08-11.sql. So that'd be pretty handy, I use that one a lot. And before running a search replace, just to double check what's in the home or the site URL field in the options table. A quick query of the database, again, WPCLI can do that for you. All right, moving on to Git. We have a pretty good workflow so far, but now we're gonna add Git and it's gonna be, it's gonna get even better. So what is it? Distributed version control system. Basically, it keeps track of your code history, right? Git's number one priority is to protect the integrity of the history of your project, so it tracks changes. It takes multiple snapshots of your project at different points in time, points in development. It's very, very light and fast. It's not gonna eat up a bunch of space on your machine. How does it help you, right? Why would you wanna use Git? Well, you can save snapshots of your project at any point in time. I know I just said this, but let's just think about that for a second. This is kind of like a checkpoint or a save point in a video game. You get somewhere, your character is the way it is at that time, has the inventory they have at that time, the experience they have at that time, and then you make progress. You continue with your character. But let's say you make a whole bunch of really bad decisions, and then, I don't know, the villagers run you off a cliff and you can decide, okay, let's go back. Let's go back to this save point and instead, I'm gonna make some different choices, you know, like maybe don't burn down the mill or whatever it is that you did. And you can just go from there. So this is, you can do the same thing with your code. You can go back to a previous version, take it into a different direction. You have a lot of control, and these save points are called commits, right, in GitLand, and you can have as many of these as you want. So that's an extremely powerful feature. You can isolate changes by creating branches. So that is something else, probably the second most important point. Let's say you're developing a feature that you know is gonna take you a couple days, maybe longer, maybe you're not sure how it's gonna turn out. Maybe you don't know if the client is going to approve. You don't want to input this code or add this code to your master branch, which is basically your main deployable, ideally bug-free code because you don't know where you're going with this code yet. So you create a branch and you basically develop there in parallel with the master branch that can continue to evolve. And on your branch, you can sync up with the master branch as you are working. And only if and when everything goes well with this feature, then you can merge it into the master branch. So it allows you to really just have that extra safety net of not polluting your good code with something that might break. It makes it easy to collaborate. So that's also a huge, huge thing. If you're not working, if you're working as a freelancer, might not be that important to you, but if you're working with a group, get is essential. It can be used to deploy instead of FTP. So this is a lot less error prone. It's a lot faster. And it also means that you're not going to accidentally overwrite other people's changes. Super important. And can be used to just reveal a massive amount of information about your project as a whole, right? So how did this particular file evolve over time? It can tell you. What are the differences between this version of the project and this one? Or what changed over the course of two weeks? Git can give you all of that information. So it's really, really good just to gather that kind of data. Some considerations. Git is not GitHub. This is often kind of mixed up at the beginning. They're related for sure, but GitHub is a service that will host your repositories. This is what makes collaboration really great, but Git is that version control software itself that we were just talking about. You'll want to use a git ignore file. So that's something, again, you can spend some time researching. There's a lot of opinions about this. There's a lot of examples that you can find online. I kind of like to think of Git as like the eye of Mordor, you know, like sweeping the value of your code with its burning eye. Does anybody know this reference? Please say yes. And then Frodo in his invisibility cloak, that's our git ignore. You're like, nope, not this, not this, not this. So the eye won't see those particular files. So one example would be your wpconfig.php file. You don't want anyone to see that. That's not something you version control. It's also environment specific. You don't want to be moving that around somewhere else. So there's a lot that you can put in that or there's a little, it depends what it is that you're versioning exactly, but you will need to use one. There is a git workflow, meta workflow in workflow. So yeah, if you are working with other people, they are going to have a particular way that they like to work with Git. And they're going to basically, it's going to be one of the first conversations you're going to have with them. Are they going to use feature branches? You know, are they going to be using pull requests? I mean, these are different ways. If you're working alone, that's 100% your call, you decide how it is that you want to work with Git. But if you are in a team, you're going to have that to consider as well. And stick to the command line. That is my opinion. I know not everybody agrees with me on that one. There are some really, really great guries to use git like tower, source tree, Kraken, I think it Kraken. There's some really, oh, git Kraken. I just got it. There's some really, really good ones out there. But the terminal is the only tool that's going to give you the full breadth of Git's abilities. It was made to be used on the command line. And if you are using these GUIs, the problem is that you're not really learning how Git works under the hood. They abstract things, right? So you're going to click on something to have this happen, which might actually involve two or three or more Git commands under the hood, but you're not aware of that necessarily. So then if something goes wrong, it's difficult, it's thorny to try to undo and find out what it is exactly that caused the problem. So personally, I would recommend if you really, really want to use a GUI for Git, get to know it first. Use it in the command line first. Know what you're doing, and then move to the GUI you'll probably use it for more kind of run-of-the-mill commands and go to the command line anyway for something that's more specific. But that's what I would recommend if you really want to use that. But otherwise, the command line is great. It can be your friend. All right, time is still good. Thank you. We are now at staging sites. So what's that? It's a clone of your live website sorry that lives on the same server. So it's not necessarily an exact clone. You might still be working on things there and that's fine. But the point is, is that it lives on the same server. It's the bridge between your development, which is your local development environment and your production site. Now I'm aware that there are some that will use more steps. There'll be local another development environment as staging and a production sometimes more. We're just gonna go with three for now. So you would traditionally go from local to staging to live. But sometimes it looks like local staging, local staging, local staging and then live. But generally that's the flow. All right, why? We already have a local development environment. Why do we need the staging thing? Well, it can test in the same environment as your production site. So even if you're using a very advanced, configurable local development environment where you can make a bunch of choices about which version of PHP you're using and all these different things to try to emulate the server as closely as possible and that's great. It's never gonna be as good as being on that server. Just to be 100% sure that what you're testing is actually what you're going to get with the production site. It's a space to get feedback. So your staging site can be accessed by your client or whoever else that you're working with. And so they can go there and click around, test things and then give you their opinion so that you can keep working on whatever it is that you're doing. You can password protect it. It's fairly easy to do. So if it's something that you only want to open up for your client at certain stages in your development process, that's totally fine. And you can just keep it behind a curtain for the rest of the time. It's also, it's another full backup, which is good to have. Okay, last step, recovery strategy. What if something still goes wrong? So it's unlikely we have a really, really solid workflow right now, but it can still totally happen. And if it does, you want to read it. You want to have a plan. You want to have a strategy in place to make it as effortless as possible to just restore the site and then find out what happened. So in order to do that, you're going to want to make sure that you have full regular backups. So by full, I mean the files and the database. Regular depends on you if you want to make them daily or less. I like the daily thing, but I know not everybody agrees. So you'll have to make that call according to your site. You want to automate the process so you don't want to have to babysit this because it will definitely slide at some point. So you just want to make sure that it is happening without you having to intervene and test it. For every environment that you have, test it at least once because it's not when the thing goes down that you want to kind of find out whether it's going to work. You want to know that it does. Some recommendations to consider with recovery strategies are managed hosting. So a lot of these will have recovery. Solutions for you in place. They'll make daily backups, for example, of all your environments. There are plugins that can do that for you too, such as UpDraftPlus, for example. Having a backup off server is also a good idea because even though they're very good nowadays, they're not infallible. So knowing that you've got something that doesn't depend on your server is a good strategy. And if your local development environment is up to date, that also acts as a backup, something else. Quick, quick word about hosting. Managed hosting and unmanaged hosting in both of these environments, you can use that workflow that we talked about. It's just that for manage is going to be a little bit easier. They already have a staging site out of the box for you in most cases. Git deploy is made easy for you in most cases. And they have a dependable recovery strategy. Whereas if you have an unmanaged hosting platform, you're going to want to have to do a lot of these things yourself. Do your own staging site. Subdomains are usually a good solution there. If you have SSH access, you can set up Git deploy. Otherwise, you can still use Git, but you'll need to use FTP to move over your files. You can do your own recovery strategy, again, probably with a plugin. So it's totally possible to do it then. It's just going to take a little bit of work. My drawing skills are abysmal, but we are now done. We have an awesome, very, very solid workflow. And if you do implement all of these steps, you're in great shape. There are a few things that we did not talk about. Task runners, right? Dependency manager, such as composer. Unit tests, preprocessors, CDCIs. So these are all things that in my mind belong in a more advanced workflow, but if you're interested and you want to fold some of these into your current workflow, there's no reason why you can't. The main takeaway then for today, workflows are incremental, okay? So you do not have to sit down and be like, I gotta do all these things now. You can just pick one thing that you're not doing and then give it some time so that you're comfortable with what it is, fold it into that workflow and test it out, get used to it, become comfortable with it. And once you're good there, incorporate one more thing. So it's something that you can do a bit at a time and then you win at life. Thank you. Thank you. Thank you. Thank you. Thank you. Okay, great. I guess I sped through that faster than I thought. Yeah. Any questions? Does anybody have any questions? Yes. What's your workflow involving changes made to the database? Because for files it's simple to me, but what happens when both your client works with his website and changes stuff like font colors or whatever and then you have made changes to the database too. Okay. So you're making changes on the live site both of you at the same time? No, I mean... Are we too close? Maybe. Let's say you make changes locally as a developer to the settings of the WordPress site. Okay, yes. Because you have changes to make. The website is already live. Okay. So you grab a copy, work locally. Yeah. And then you want to put the changes in place. Yes. But your client already made changes at the same time after you made your backup. Okay. And worked on the backup. So what's happening with the database? How do you, what's your workflow? So like that tiny window, there's still a possibility that you guys are making changes at the exact same time. Yeah, well it may be a few days. Yeah. So I'll always back up the live site first and I'll just, I'll compare and make sure that there haven't been any changes since I last made changes. I'll usually let my client know too, like, hey, I'm going to be doing this in the next 15 minutes. Could you please not touch the site? That's not like 100%. Great. But then I'll make a backup. I'll do staging. I'll make sure that it's okay. I'll have them check it. And then I'll move from staging to live. So generally by then, if there's anything awful, have found it out before it gets to live. But everything's been backed up first. So in case there's anything, we can just always go back. But usually, yeah. Usually that's pretty foolproof because you're making, I'm making sure that it's not different from the live site. And then I'm pushing to staging. The client and myself are looking at it on staging. When I get the approval, staging goes to live. Okay. Any other questions? Yep, over here. Thank you, Megan. Hello. Hi. It's a very solid work floor. Thanks for the, I just have one question you spoke about WPCLI. So what would change? Because now we have like a WordPress admin where I can, there's a page where I can see all the updates and then update everything. What's the different, why should I use like this one versus what WordPress admin is already giving me? So like in terms of workflow, like. That's a great question. I mean, it is just on its own. It's a lot faster than having to go into the admin and click, click, click, find what it is that you're looking for. You can find it much faster by just running the command in WPCLI. But there's also a lot that you can do with WPCLI, like just directly query the database to find some information about something specific. And these are things that you can't do unless you're like messing around PHP, my admin or whatever it is that you use. So, and I strongly recommend that you take a look at the documentation because every time I do, that was in my little like bubble on that page. And it was like kind of small to read. But every time I do, I find out this new amazing thing that WPCLI can do that I now fold into my workflow. But it can do a lot for you and it's not just about making things faster. It can do things that you wouldn't otherwise be able to do easily in the admin. Thank you. Any other questions? Well, thank you very much, everybody.