 Hey, guys. Great to be here today. Really excited to be in Helsinki, talk to you guys about configuration management and WordPress. It's pretty technical, and I think I owe it to you guys to explain a little bit about what I was thinking when I was going into this talk and just the idea behind it. So I've worked with the multi-tiered environment for a long time, long enough to know that it's a useful way to work as a developer. I know this is going to be a technical talk. Wanted to see how many of you are technical, how many people in here today are developers. You guys can raise hands. OK, that's great. So there's at least 47 of you that are developers. Anyways, so we're talking about multiple tiers, and the reason why is because when you are working on a site sooner or later, you're going to want to make changes on a server without affecting your live site. So you don't want to have something happen to your visitors. As they're viewing the site, what happens if your code is not right and you manage to break something? You don't want to have somebody see a broken site. That's bad user experience, and we can do better than that. So the reason why we have multi-tiered environment is so that we can develop. We're safe. We know that we can test things, whether it's on our local development environment or it's on the staging environment. And once we're ready, we can push that to our live site. So with that in mind, there's a problem about how do you get your data to go from one server to another, and what are all the parts that you need to make your data the same across a site, and what needs to be the same and what needs to be different. And that's where configuration comes into play. So I'm going to talk a little bit about some background and data in WordPress. Then I want to show you how to do three things. So syncing code base, uploads, and database. And then I want to talk about configuration management with a really cool plugin that allows most people to manage configuration. So about me, I work at WP Engine as a sales engineer. Does anybody know what technical sales is or what technical sales does? OK, a couple of you. So it's relatively different. I'm not a developer all the time, but I do get technical on occasion. But really, I'm working to make sure that people, when they come onto WP Engine, are on the right spot. And so we're giving them the best solution. So that said, I've been a developer for about 15 years. Prior to that, I've worked with content management all the way back. I remember my first time working with the content management system. I was amazed by being able to change a theme and that magic that you could have one click and change to a different theme, entirely different design. It just opened up a really cool door for me, and I thought it was pretty amazing. I've worked with open source technology for most of my career. At some points, I've worked with proprietary systems, but I really enjoy the WordPress community and open source and being able to contribute and use the software and actually be a part of the software that we use. So I've also done some speaking in WordCamps. I've done maybe five last year, and starting about two years ago, probably 15 or so engagements. And it was something that I've never done before, and I really enjoy. All right, so let's get into data and WordPress. The types of data that WordPress has and configuration. So I looked up the definition of configuration management. And just Wikipedia, it gives me the task of tracking and controlling changes in the software. Today, I want to focus on the controlling software, controlling changes rather than the tracking. I think there's many ways that we can audit and see what's being changed, but the controlling and deploying is a little bit more important. WordPress uses several different types of data. So if you're using the WordPress core files, you have PHP files, JavaScript, CSS. So that's your code base. So all of those are files that are written to disk. WordPress uses database to store its content, so posts and pages and anything like options are all stored in the database. You can use transients and object caching. It's a little bit more advanced, but a different type of data that expires at a certain point. You'll also use uploads, so anything that's uploaded to WordPress is stored in the media library as an asset. So these would be typically larger files. And then I've also called out configuration here, because I think that even though it's part of the PHP file, so it's similar to core files, it's a little bit different, because that will change. So your configuration will vary across your deploys, but the code stays the same. So we always want to configure things differently, and you'll see why in a couple of minutes we'll go into the reason why configuration would be different, even though it's the same site, and you're just essentially duplicating the site on a different server. So if I wanted to deploy a WordPress site, simply all I need to do is take the database, the files, and the uploads, and move that to another system. So at the core of it, that gets me my file. That gets me my site on another environment. So let's say I copied my site from production down to development, so I want to do some testing, some coding. That's all I'd need to work with, but that's not going to give you a working WordPress install. You're going to need to create another WordPress config file, and that will contain your settings for database and potentially different settings for development. So if you're developing with certain variables, let's say you're debugging. You'd want to have that on your development environment, but it doesn't need to be on your production environment. And sometimes this configuration will have sensitive information. So when you're working with multiple environments, you will have some things that are going to be the same across the environment, but then you'll also have those unique settings, like I was saying, as far as testing, debugging. Credentials will always change. So you'll have different database credentials, which are stored in that config file. And that is sensitive information. You want to keep that outside of version control, so it makes sense to take the config file and not include it in your version control if you're using it. So I looked at a system called .emv, and .emv is a way to manage configuration across multiple servers. And it works pretty simply by requiring a certain file based on the environment that you're in. So you would set a variable in that configuration, and you'd say, this is what I need to include. So this file gets included for this environment. It's relatively simple. There are other systems like it. And I've even seen this done just by People's Custom Code. And it's a really great way to keep those credentials out of version control, but also manage the configuration based on the environment. I've included a link here at the bottom, so that you can take a look afterwards. I'll share this presentation on SlideShare. You can download and set this up yourself relatively simply. Let's get into syncing things. So if we're going to sync the code base, there's actually two really simple ways to do this. So you're either going to pull your files down via File Transfer Protocol, so FTP or SFTP, or you'll use version control if you're using it on your site. So something like Git, and you'll use a Git push. You'll push your site to a server, or you'll pull it down if you're doing development. And so that really gives you all of the files that you need for your code base. Version control is a plus, because it allows you to make sure that once you push your changes, those files are going to be the exact same as what they are on your development environment. So you're maintaining that sync between them. You can use FTP, and you can sync FTP, but less reliably, because you could always make changes. And you're not, unless you're putting all files up, it's hard to know if everything has been pushed to production. And version control is great, because it allows you to say, I only want to push these files. I don't want to push all of the files. Let's just be concerned with anything that's WordPress core. But some of these config files, we can leave out. And that's exactly what we'll do with the WP config file. So for uploads, your uploads directory, where you've got all of the files that users may have, it's not going to be something that you want to keep in version control, because these are going to change, and this could potentially be a massive amount of files. So it doesn't make sense to waste time syncing these when you don't have to all the time, although there are a couple of ways that you can sync the uploads. The first would be to copy everything, copy all of the files from production to your local development environment. And of course, if you're doing this for the first time, you'll need to do that. But maybe on an ongoing basis, you only need to know what's changed. So you can copy all the files that you need. And then there's another method where you can point to your live server and actually use the files there. It's my favorite, and I'll show you how that's done. So copying all files, again, you're going to use FTP. You can download all those files with a client app if using an FTP app, or it can be done on the command line. If you're more technical, comfortable with the command line, and you have access to SSH, a great solution is to use R-Sync. But again, it requires SSH access. You may not have that on some hosting providers, especially if you're using a shared hosting. So you may have to go back to FTP. So for deployment, if you want to copy only a few files, there's a great feature in WordPress, which allows you to organize your uploads. And this is a setting that you can change in WordPress. It essentially puts things in folders by year and by month. So if you only wanted to download everything from 2017, that'd be simple to do. And this is what it looks like. I'm just showing from March all the files that I've added to my site. And in this case, I just simply want to grab anything from 03 and 04 and pull that down to my local, and I'd have everything for 2017. So for the case of using things where you don't necessarily want to download all the files, this plugin is fantastic. What it allows you to do is look locally for a file. And if it's not there, then use your production server. So I don't have to actually copy any files down to my local dev. I can just use this plugin to automate that. There's some configuration that has to happen. It took me a couple of tries to get this working, must admit, but it's relatively simple. And this configuration is an example of something that you'd want to keep on your dev environment, but not in your production environment, because it doesn't apply to production. It's only for development. What you're doing here is defining the site URL. So my site, admin.local, that's my local dev site. I'm saying uploads by proxy is local, and then I'm also giving an uploads by proxy site, so where the images will be pulled from. And this is well-documented as well at the uploads by proxy plugin page in the repository. So database migration, I think this is one of the more trickier things, but there are a couple of ways that you can go to do this. You can use WPCLI. Again, this is gonna be a little bit more advanced. This will be something that you would need to have command line chops. You'd need to install WPCLI, not very complicated, but definitely an extra step. You can use, you can FTP your files and then import them through MySQL. That's also a little bit more advanced because it's command line based, or you can use third-party plugins. Many plugins available. I won't go into them, but there's ways to do this. If you just want to deal with a plugin, that's no problem. So to do the database import, you're actually, there's three different methods. So WPCLI has some commands available that will let you do that natively. MySQL import, so directly with MySQL. And then you can use on some hosts, you can use PHP MyAdmin, or another visual interface to MySQL. One of the cool things that I found about WPCLI is using aliases. So the concept of aliases is, it gives you a shortcut to remote into another server. So instead of having to log into another server via SSH, I can do that simply by adding this shortcut into a command. So my workflow is, let's say I wanted to see WPCLI Info, but I wanted to see that on my production machine. So the production, I'm not working on production, it's another server somewhere else. I would use WP at production CLI Info. So behind the scenes, this is going in, connecting over SSH, it's running the command, and then returning the data to my local directory. You can set this up, it's simple configuration, and it's documented well on the WPCLI site. I think it's lesser known, but a really useful tool if you're working, and you wanna have a certain very streamlined workflow. It's not very hard to SSH and get used to going into a directory, especially if you're a technical user, but this does make it quite a bit easier, and I find the workflow to be pretty simple. So really the main advantage here is, I just put a simple prefix in front of my WPCLI command, and I'm able to run something on a remote server. So for syncing the database across environments with WPCLI, I've put an example up that shows you how to remote into the production environment and export the database. Then reset the database on dev, and then import that my SQL file, that SQL export, and then change the URLs. So essentially it's going up to production, grabbing that SQL file, and then I'm just cleaning out my database, and then importing the file. So four commands, relatively simple, and important to change those URLs because if you have any URL saved in your database, they won't work, they'll point to the live site. That's also well documented. There is a Gist available, which I have linked right there. All right, so let's get into the configuration management piece. I think this is really cool because sometimes you don't want to have everything saved into WordPress, you don't want to copy the entire database, you just want to make a few changes. So let's say we change the setting on our dev environment and we just want to push those changes up, this can be done with configuration. And in this case, I don't have to deploy the entire database, and this could actually be really risky too. If I'm copying my database from development to production, I risk overwriting some production data. So what if my editors are logged into the production site and they've created new content? So that could actually be overwritten if I don't have the most recent version of the database. So obviously you're gonna save time and you don't really need to sync the data. So some examples of these differences that you might want to deal with in configuration are constants like the site URL, home URL. You don't want to have the same plugins enabled in your production environment, so definitely any of those dev plugins uploads by proxy for example, you wouldn't want to have that on the production environment. And then there's also a situation where on a live site, you may have users that make changes and you may want to replicate those changes and only take the settings that have changed. So there's a way to do this with this plugin called WPCFM. I think this is really cool because it allows you to version your changes. This is inspired for me by a Drupal module called Features. So I think this works in a relatively similar way. It allows you to take some of the settings in the database, in the options table, and some of the other tables in your WordPress database and save them directly as files. And in this way, you can check it into version control and push those changes. So you're not copying the entire database, just a subset. You can organize and customize these settings that you want to push. And it's going to be easier for you to keep things consistent or if you don't want to keep things consistent across multiple environments. So primarily, WPCFM works with options. It saves these options together as bundles and you can create custom bundles. Once we get through the slides, I'll jump to show you the plugin and how it works. I think it's relatively simple for most people to use, but it can also be done through the command line through WPCLI as well. So, and again, the idea is we're going to save those settings to a file and then we're going to pull them into a database on a different server rather than copy the entire database. So this data for WPCFM is saved into a JSON array. So it's in the WPContent that creates a folder called config and it keeps everything as JSON files. And you can manage these settings in the WordPress dashboard. I'll show you how that looks. And it gives the non-technical users a way to alter these settings as well and manage these settings if they're not able to access the command line or to access the file system or repository. So the data that you can manage is mainly options. You can manage site meta, taxonomy, and custom fields. And I think this gives you a good range of things that you can actually keep and store and manage. If you're using a plugin, you're building a plugin and you're using options, you can save those options as well. Using WPCLI, these are a bunch of commands that would help you to use it. So it's actually very simple. The concept here is you're going to push changes to disk. So I push my settings to a file and then I pull them into the database. You can see some other commands. So there's a diff which shows you the difference between what's on your disk and what's in the database. And you can create these bundles as well through WPCLI. So that brings me too close to the end here. I hope that I've been clear enough to make a couple of good points. So codebase, if you're using version control, that will help you to sync the code across multiple environments. Uploads, you can pull down regularly with RSync or you can use uploads by proxy or FTP. WPCLI is a great way to sync your database, keep things in check, other ways to do that as well, but I think that massively simplifies workflow. And the main point is that configuration will differ across multiple environments, but you can still manage that in a central place. I am Edmund Turbin on Twitter. I'm Spice Cadet and I wanted to thank you guys so much for allowing me the opportunity to speak to you. So I have a second to go through the WPCFM plugin. You have time. Yeah. Excellent. Okay, we'll take a look. All right, so just quickly I'll show you what this looks like. Oh, okay. So I have gone to my WordPress install locally and this is the WPCFM page. So if I wanted to, so I've created a couple of these bundles which store settings. I've got one for active plugins. And so what you're looking at here is an option, right? So I've selected the active plugins option and it saves that information to a file. So I have the ability here to see the difference, to push those changes to disk and then pull that into the database. So just really simply, if I've got new code that's been committed, I could pull it in to the database, import those changes. So I've done that also with my theme mods. So any settings that are available to the theme to change. So which I can make sure that my theme is the same on my development and production environment and also taxonomy. So if you notice, there's a bunch of options here. You have a really big list of things that you can manage. So you can pick out things individually or if you want to grab everything, it's possible to do that as well. So you can select all of these options and just push them at an atomic level. So what this looks like in your install is, I'll just clear that out. So I've got a couple of files here. So I've gone into that directory where all of these files are saved. So it's wp-content-config and I've listed out the files. So I've got a couple of JSON files there and I can show you what the settings actually look like. So my taxonomy has all of the settings for taxonomy. So everything there would be committed to the repository and then you can pull that in with WPC FM. That's really it. That's the main points that I wanted to make. I wanted to open it up to questions. Oh, I have a note for myself. Go ahead. So I have some WP Engine swag available at the speaker table. If you guys are interested, a couple of hats, stickers, just stop by and see me over there after the presentation. Thank you guys. Thanks. Thanks, Edmund. Now please raise your hands. If you have any questions for Edmund, there must be something. Oh, it's good. Everybody understands. At least I don't have a job done. Either that or everybody is super confused. Yeah. Oh, super hungry. I want it. It could be that also. Let's get some lunch. Could you get a mic? We can get your mic. I have a mic. There it is. Yes, now it's working. You mentioned that the WPC FM creates JSON files. Let's say you have multiple developers working in one project. In my experience, JSON and Git is kind of painful because like machine created files in version control is just resolving the conflicts all over again. How do you manage that? Yeah, I can see that being an issue. I've not thought of it. So not a good answer, honestly. But I think what my concern here was is just getting those settings up to the production environment. So potentially you want to ignore those settings. So rather than commit them to the repository, just use the WPC-LI commands to make sure they're in sync. Although you're sort of risking not having the same configuration. So the whole point of having it in version control is that you know that those settings are going to be the same. But I do see the concern there, yeah. Any more questions? Here's one from Daniel. I might be trolling here, but when are you going to have WPC-LI on WP Engine? That is a great question. That was a bad one. So it's been on our roadmap for some time. We have a beta available, which allows you to go in and actually do WPC-LI in our user portal. It is something that we're continuously developing and the next iteration will be on the command line as it should be. So I've seen a little bit of movement there. I don't have any sort of dates or timings around it, but it is being worked on. And that's super, super good news. That was very exciting.