 All right, everybody. Hi, again, I'm Eileen Violini. If you can find me online at underscore iViolini. And today we're going to talk about upgrading your WordPress workflow. And if you're, can I see a show of hands? How many here are designers? Good, a lot of designers. How about developers? So people actually work. And how many of you use a local development environment currently? OK, so a lot of what I'm going to introduce to you today is a basic local WordPress development environment moving through staging and then on to production. There are lots of different ways that you can do this. This is a bare minimum way that you can start and begin to work with this type of workflow in your development processes. There are other more geeky options. And I'd like to think of it as a gateway drug. So once you start here, you're going to want to explore other options with command line and different tools. So when we talk about cowboy coding, that's when somebody is, who knows what cowboy coding is? Ken. Donik. Yeah, I think all of us have done a little bit of cowboy coding. So cowboy, yeah. So when cowboy coding is when you are not using a workflow for development that is going to protect your production site from going down. So you might be out on the South 40. You know you're on the South 40 and please raise your hands here if you have done this. If you make changes to the style.css file in FileZilla and push that directly to production without using code editor, yeah. You might be on the South 40. Go ahead, raise your hand. If you open the index PHP file on production in the WordPress dashboard editor, and yeah, there's a typo there because I did that last minute. And you make changes and hit update. So you're making, yeah. It's just a live site. You might be cowboy coding. And if you think EnQ is a type of fancy barbecue and you make changes to CSS and the customizer, both hands here. I do this every day. And he yells at me for it. So yeah, you might be on the South 40. Getting off of the farm and upgrading your WordPress workflow is going to save you time. So you can be making changes locally and uploading a whole bunch of files. How many of you have been working in FileZilla? And you hit that upload button. And it's uploading everything. And it's like the old days of the Mac when you could walk out, smoke a cigarette, have a cup of coffee, come back in, and your computer was still booting up. That's kind of like what uploading your WordPress site through FileZilla is like. Getting everything set up and working locally, you'll be able to cut that time down. It goes faster. You can keep track of your changes better and roll those changes back. If you need to redo something, a client has decided that they don't like it. And you're safe. You're ensuring that your production site is stable and you're not pushing things up there that are going to break it. So for terminology, when I talk about a local environment, it's a server that exists on your computer and it's not anywhere that anybody else can see it. It's hosted right here on your own laptop or desktop. The staging environment is hosted on a remote server somewhere, so wherever your host is. And it doesn't have a publicly known URL. So if you're, it might say staging or it might have a bunch of numbers in it or you can throw any type of jargon in there to kind of dissuade people from being able to look at it unless they actually have the URL that you give them. And the remote environment, also called production or live, it's the site that's seen by the public. It's your final site, all your final code, settings, everything, that's what everybody goes to visit. So the big picture is developing locally on the server that you set up on your laptop or desktop, pushing to staging and testing so that you can see what is happening to your code in the server environment that it's going to be living in because there are changes. There are things that don't always work the same way. And then finally moving that staging into production. Tools, to get started with this, you need a local development server with a WordPress install. There are lots of different applications that you can use to get set up with this. Local by flywheel is one, desktop server is one, MAMP for Mac or WAMP for Windows or other options. Geeky options include Docker, VVV or Lando and Calibox. Those are not for the faint of heart. When I came into WordPress, I was a print designer and slowly began to learn more about code and the very first word camp that I ever went to, I attended a contributor day and there were two options. You could go to training and help the training team or you could go to testing and help the testing team. And I thought, well, I already do a lot of writing. I think I'd like to try something different and testing appealed to me because, hey, I can break anything better than anybody. So I figured, let me do that. I spent my entire day trying to download things like Homebrew and set up things through the command line and terminal and set up VVV and this is many years ago. There's a better system for that now so please don't be scared. Go to contributor day if you can. But at that time it was very, very painful and it took me a really long time to get up to speed with these things. I kind of look at it as a rite of passage to be able to get all of these environments set up and working correctly and it's still something that I don't know how to do very well and I always have to ask a lot of questions. So if you start down the road of using this type of workflow and you get stuck, don't give up, just keep asking questions. Some other helpful things in this process, you're gonna need some migration and duplication tools. So DB Migrate Pro is a paid plugin that will migrate your database files and duplicator or WP clone or we also use updrafts plus to be able to take a entire snapshot or backup or clone of your site and version control Git, specifically using GUI tools like Git desktop or source tree and then a repository to put those files. So all of the code files that exist in not the WordPress core but your theme files, your plugin files, everything that's in WP content and admin, all of those things would reside in your code repository and a hosting environment that works with Git. So, oh sorry, that's the staging. So using command line interface and using some sort of configuration tool can also help you get those items from local and staging into production correctly. So for your local environment, it's just like any other WordPress environment. It's a standard WordPress website configured with a PHP version, a MySQL database and a clean WordPress install. It allows you to work offline so you're not connected to the server if you travel a lot or you don't have access to the internet at that time. Having a project that you're working on on your desktop can be really helpful so that you don't have to wait to get online to make changes. You can see the changes quickly and immediately you're not waiting for that time to download that file through FileZilla from your server, make changes, re-upload it. You hit refresh and you can see what CSS changes you've made or in some of the tools, they will allow you to create a blueprint. So if you have specific things that you work with on a regular basis, you can tell it to spin up this site using the same items and plugins and options that you already use in other sites. And I like local because we can put an old version of WordPress up and test and see if so when a client comes to me and says, my site broke and I don't know how and I updated recently, then I can go back to a version or two versions before to see what it looks like in an older environment. Your local site will have a different type of URL than your main website. Local by Flywheel appends dot local at the end of those files and MAMP uses localhost forward slash site name. Your staging site then will have staging or development or QA or whatever subdomain you put in front of your site name. So setting up when you're when you're setting up your, after you set up your local site and you make changes and you have everything maybe partially ready to go or maybe you're taking, you just need to check one feature and you or maybe you wait till the very end and you just put the whole site up, you're gonna have to move it from local to staging. And then you'll want to make sure that you set after you have your local environment set up that you're setting up a staging site and you're doing the same routine. So it's a brand new WordPress install. It has the, it should have similar PHP versions. It should have a database. To make it easier on yourself, you'll want to make sure that you name the database. It has the same kind of table prefix in front of it. You can fix it later on. If it doesn't, you can change that but it just makes it easier starting out if your database tables have the same prefix name. You'll also want to change in the config file to turn on WP debug so that you can catch any errors that are happening. So define WP debug true. That's just a little helpful tip. And you have two options to move between local up to staging. You can do it the old fashioned way using FTP. And this is a shot of the FTP and maybe you're just pulling over. So this is your local, all your local files here, the individual files that you're working on. This is pushing out to the site that's on the server. And maybe you only have one file that you made changes in this page template file and you want to push those up and you can move it over to the corresponding file. Doing this creates a lot of agita for me on a regular basis because I never know if I'm getting the right file if I'm getting it into the right folder where it needs to go and it does break sometimes. I like to have everything set up so that I don't have to do that heavy thinking because I'm thinking about other things and I don't want to hear them fire a moment where everything goes down. So taking a little bit of time in the very beginning of your process to set up a sync with Git is gonna save you time later on where you're not worrying about did I just move the right file over. So this is not a talk to walk through how to set up a local environment. But if you're working in MAMP, you'll need to go out and get the latest version of WordPress or whatever version of WordPress that you're working in and install that in the MAMP process. If you're working in a product like local, local will give you options that you can select and you just click through some buttons so it makes it really easy. And then when you're setting things up for your staging site, you'll want to use a tool maybe in the C panel like Softaculus or other hosts like Pantheon or WP Engine will walk you through a wizard to be able to set up those environments for you. But the idea is that once you have something in local, then you're mirroring it out on staging. And when we say we're gonna hook it up to Git, what that enables us to do is that brings version control in. So how many of you have had a client? I've had this happen to me. You make changes in the menu. They get a whole new menu, all different kinds of dropdown, lots of JavaScript actions happening and they're like, oh, I don't know if I like that or not. I think I really want to go with that other version. And you put that other version up there and you don't save the code. And the next thing you know, they're like, oh, I like that old version. And then you gotta go back and redo everything. So that's a lot of time wasted. Version control will allow you to create a branch and save those snippets and versions of different aspects of your website so you don't lose that work that you've done. What is Git? Git is a free and open source distributed version control system. This is the main Git link and there's an online web book here. So if you're really interested in finding out more about Git, this is the place to start. This talk is not about Git. It's a very high level introduction to it. Git itself also, besides being version control, there's a place where your code is stored. So it's stored in the Git repo and that's a remote storage bucket that you have access to and you can use it to share your code with other team members so you can collaborate together. It's important to note that Git itself is the version control and other products like Git Hub or BitBucket. There's some others out there as well. Those are specific types of remote access to, so Git is the version control and then BitBucket or Git Hub are different products that use Git version control. They use other types of version control but that's where you can use Git and you can use that version control through the command line or through a GUI interface. So like Git desktop or Source Tree and it provides you a way to be able to see what branch you're working in and what changes you have made. If you can note here, there's some red fields in the back here and some green fields. The green field indicates that there's been a line changed in this code. Something has changed here. This is the old version and this is what is being pushed out new. So your Git account, you'll create a Git account there, you'll create a repo there and then you'll push what code you have locally to that repo in Git. So whether you're using GitHub or BitBucket, you'll push the code out there. The big difference between GitHub and BitBucket are private accounts. So BitBucket will allow you to have a free private account. You can get private accounts at Git Hub that you have to pay for at first. I think Git BitBucket stops you at like three private repos. But it's the same sort of process that you're working through in terms of you're making changes to your code locally and then you're putting it out into the repo. And then once you are, if your host allows this, if they're set up to do this, so like SiteGround, your very base level is just regular hosting and you have to move up a tier or two to get the Git sync or the geeky options, they call it. But you install an SSH key in your, you create an SSH key pair in your repo and you sync and you use one key in your Git account and one key on your server. And when you push changes out to your Git remote bucket, it will, you'll see those changes happen automatically on your website. So you've just eliminated that whole step of going in and moving one file from, through FileZilla from one place to another. I'm not gonna lie, this is hard for me to do. It takes a little bit of, there's a little learning curve. You would, it would be to both. So initially you wanna make sure that you're going into staging and you're getting everything in staging first and then staging would roll over to production. Usually you wouldn't wanna push changes directly into production. It's more from just taking that staging site and then making changes to that so that it becomes your production site. And the last step is the database. So dotting your eyes, once when you're in, when you're in, when you're local and you push those changes out to staging, whatever's in local stays in the local environment. So think about it in terms of if you have a database on your production site and your client is making changes to it. They're putting in new pictures, they're putting up new blog posts. If you took everything that you had locally and you just pushed it out into production, you would overwrite everything that they have done in the past, whatever it is, since you've taken a snapshot of that site. I've had that happen to a place that I was working. So that all that, all those files and everything, you know, all that work and everything is just gone. Using a tool like DB Migrate Pro, you can sync the database, you can either pull what's in production and pull it down locally or you can push the files, the database files, posts or images, media files and push those out. But that's really a separate, you wanna think of that in terms of being a very separate deliberate step so that you're not overwriting something somewhere where you don't wanna do it. And again, what happens locally stays locally. So you're in there, you're creating a theme, you're making all your theme changes to CSS and you're pushing those posts into your repo. It's being version controlled, it's being saved in a place other than on your desktop. And then that sync is happening between those code files in the repo and the code files that are being stored on your server to be displayed on the front end. But all along that process, no database files are getting crossed. It's just the code files. What happened to my plugins? So this is something that I always get tripped up on. I make a push and I go to check something and the change isn't there and I don't know why it's not there. And I'm like, I know I did this right. And the first thing I do is think that I've done something wrong in the code. I go and I look in the code. Well, 45 minutes later, I go into the WordPress admin dashboard and it says this plugin has been disabled or you go into the settings and the settings aren't correct. And that's because those settings in your plugins aren't getting transferred over. So I actually have a sticky note someplace that reminds me to go check those things first so I don't waste 45 minutes. And that's a real pain point, I think. And it's a pain point for most people is what you're left doing is when you have a plugin with all of its settings and if you have a lot of plugins, I do a lot of work in Paid Memberships Pro and there are a ton of add-ons to that one main plugin and lots of settings. So that's really tough to be able to keep up with all those changes and things that I've made. You can use a configuration management tool. This is a new area that I'm exploring in terms of trying to eliminate areas in my workflow and my process that create a lot of friction for me. And I'll be honest with you, I haven't gotten there yet, I can't share with you how that works. A friend of mine, Tessa Crissel from Pantheon, she has a talk, I have it in my resources here on configuration management. So that'll be the next area that I'll be exploring. But like I said, it's a gateway drug. When you start doing this, you're gonna be looking at doing more and getting better, or at least that's what I'm doing. Some of the resources I have for you, I have a couple things here on how to use Git. Like I said, this wasn't a talk about Git, it was just the broad concept of it. There are oodles and reams of pages and posts and information on the internet about Git and Git branching and how you should use Git version control and that's not what, that could be an all day long conference, but this was more just the very high level type of thing. For my studio, what we'll usually do is look at having a feature, so different branches. We each will have our own branch that we'll work in, but we will also version out branches, so we might have a branch that's the menu upgrade or a branch that's the adding in the CSS upgrade, so things like that, and then once we've tested those branches and they look good, then we merge them into the master branch. But there's lots of different ways and lots of different thought processes about how you should branch Git. And there's Learn Git branching, Git for WordPress development, WP pusher. This is a tool similar to the configuration management tool and it will allow you to keep the settings synced. It's something that I haven't tried yet, but the WordPress Git course that he has online, you sign up for it and he sends you a different video every day, that's a really great introduction. There's the configuration talk and this is what's available in the Codex for starting and setting up a local development environment. So do we have any questions? Yes. So if a hosting company doesn't have a specific staging area where you can just click a button, which is, can you do, you know, set up a subdomain or something? Yes. And then that will work the same? Yes. You can just manually copy over. Right. And you'll want to check that you have enough space in your account and bandwidth to be able to do that, but that's exactly what you would do. So something like staging or QA as a subdomain off of your main URL, that works. Yeah, Ken. If you have images on your production site, does your staging site have a duplicate of those images or are you referring to the production site images? So you don't have to duplicate the saving space? I'm probably, I think in my workflow at the moment, I'm probably duplicating. And I should, yeah. Think about, yeah. I should really think about doing that differently. But yeah, that's probably how it works at the moment. Yeah. With staging, I'm getting the occasion where you go, I'm using content errors because the same content is in a staging environment and it's in production environment. Although it's temporary in staging, that is a short-term hit on the CEO because the same content is in a few of the forums. I don't know if you have any workflow or any tricks to get around making a site overall with one quick fix and saying this is not a searchable site. We would do robot tech settings. Yeah, in your settings, in the general settings, under. What I'm doing is protecting it behind HTSs. So there is a password known of that component in staging as it says. That's what I can say is that I've been planning that the setting isn't always, doesn't, yeah. They don't have to serve. Yeah, they don't have to, right. But the hd access would be the other answer denied. But the answer to Ken's is you can use the same database and then just change the two options. If it's a new database, like option one and option two are the URLs, if it's an old database, it's one in 36. Just, so the staging URL, you're changing and then everything else would be production URLs and then you can leave all your things there. Oh, okay. All right, I seem to recall reading an article on it and of course now I can't find it. And I think it's by the people made DB Migrate Pro that I thought they had something that I just can't find it. So if you do that, do it in the database first. Just make those two changes. Otherwise your staging set wouldn't resolve. Right. Okay. But then that way the references, the images are going to production and I don't have to look at what's then saved in space. Right. Okay. All right, thanks. Well, what happens if you post up the problem in staging, is it gonna? No. No, don't do that. You have to do it in one. No, so if you post, so in this case you could test something locally. I mean in staging, right? And it would use those, the staging URL and anything that you could add it to it media-wise would have the staging URL. But you wouldn't take that database and put it up. You never put the database that way. You only take the database down. You only take the database down, never up. Unless you're on your side. So, and if you're... On your life side, but those are, that's files. So those are, you're gonna have to do that in both places no matter what. You're just talking about the database and it's really just references to images. That's why the issue is... So you're doing it in both places. That's what you're saying. Updating plugins in both places. Right. Okay. Jason. She was more about saving space. Right. Right. With images, yeah. Just gonna ask if you probably work with clients with a lot of different hosts. If there's hosts that you feel do their staging site better than others. So... Individual features of how they do staging that you like and dislike. Recently I had the opportunity to put a client out in Pantheon and I really liked how quick and easy that was to be able to install their migrator plugin on my client's live site. Hit that migrate button. It generates a machine key and you throw that into the plugin and you have to keep the browser open. But you hit that migrate key and it just goes and it just does it. And I don't have to do all of these different steps and stages. So that was a really big time saver for me and I'm gonna look at how I can replicate that type of thing in my own workflow. It's... Yeah, that is open source. So Updraft Plus has a migrate button like that and it'll work between live site to live site but it doesn't work from if I have to take my client site and pull it down locally. So what I'll have to do is I create a package. It breaks it up into theme files, plugin files, uploads different, it gives you four different packages and then you download those, install Updraft Plus locally and it will, you hit the restore button and it goes and it grabs each of those packages. It makes the process a little bit easier for really, really big sites because it's chunked everything up for you but it's still time consuming. I want just that click, the button, magic thing. Local by Flywheel and their local environment and their hosting is a really, really nice, tight integration. There's a button in there, you hit connect and it goes out and it sends all the files to your site there on that host. But, and WP Engine, I've worked with WP Engine and that's also been very smooth. So any other questions? Does anybody else have a different workflow that they use? But I basically repeat my steps and that's what I was trying to figure out was how it came here because in my dev environment I have contact forms for example that go to me, not to my client but on the live site they go to the client. So I'm not, but let's say I'm updating all the plugins, I'm testing it, make sure everything works but the thing that's nice about a dev environment is exactly the same PHP version and database versions and server hosting, everything's batched up exactly, you know? So then, but then I'm repeating my steps, I'm going through updating the plugins on the live site. But I'm able to do any kind of testing or try some new things. I don't have all the most recent content on the staging site because I'm not even pulling it down because there's no purpose to that unless there's been like some major changes. Right. But it's also, you know, space, space, you know, if you have a space issue that would be a problem. Yes. So there are some downsides too, but I don't know. I was trying to figure out is there a way to have a third level in there so that I can just push things to the live site. But it sounds like you're actually doing some stuff. You are actually doing voice anyway. That, and I do a lot of plugin work so that's a really big issue for me at the moment is trying to find a way that goes easily because I don't like to install and set up plugins on a client's live production site. And usually none of them have staging or QA or anything like that. So. I made me think of both for like that. So you created a plugin for someone and you're like it's 1.0 and you want to create a change log. But I found like later on in consulting I realized like, oh I should do a change log for client plugins and keep track of the version because eventually what happens is you have that same plugin on dev, on staging, on their staging and this local machine that's other one and you feel like oh I don't know which is which. Oh yeah. And so like if you're not doing some other kind of version control to map these things like it's good to be track of versions and change logs for things. Right. I have, we do something similar. So if we do a customizations plugin or something special in a paid memberships pro register helper plugin will version control those. So and show the number. Because inevitably if I've got one my partner has another one. So that way we can at least be able to say which number do you have. Yes. Just a comment on plugins. So you're talking about how you have changes on your local and it doesn't get pushed to the production. I had the opposite problem because the plugin was really just a portal to a cloud service. So I was local. I thought everything was fine. Things were actually happening on live. On live, yeah. To think, yeah. Okay, was that the social? That was the social. Yeah, and that is something that they're trying to cut now because Facebook and a lot of the social medias are not allowing a massive post from somewhere else. Right. That may not be an issue anymore, but yes, we definitely experienced that. Right, yeah, they're cutting out, being able to post from your website. So, all right, great. Any other questions? No? Do you have a link to your resources on Twitter or? Yes, I will tweet out that link. And if you go to visit it, it is, right now it's on a test site and I'm using a new theme and development environment workflow from Morton Henriksen. It's called WP-Rig. So the site is basic, basic, basic and I'll be making changes and updates to that theme. It uses other things like Composer and Browser Sync. So that's the next stage of my journey about creating a better development environment. So you can keep checking back and see how it turns out. All right, URL. It is iViolini.Sidetrack.Studio. URL for whether or not. Great, thank you everybody.