A couple of years ago I wrote about deploying WordPress from a local install to a live site. My workflow has evolved over time (I’m sure yours has, too) and the tools available are consistently getting better. So I figured it was time for an updated look at my WordPress deployment workflow.
For starters, let me define what I’m talking about when I say “WordPress deployment workflow.” I’m talking about the specific process that involves taking a WordPress site on your local machine and moving (“pushing”) it to a live server. This also includes the process of making changes to a WordPress site and keeping your local environment synced with a live site.
What I’m not talking about is a WordPress development workflow. That involves fun things like setting up development environments, version control with Git, and spicing things up with Composer, etc. And that’s not what I’m talking about.
I’ll use this tweet from Lee to kick off the conversation. I’ll start by sharing my deployment workflow and then wrap up by sharing what other (smarter) developers are doing.
@cdils what is the best way to develop WP locally then push updates to your live site? A plugin like backup buddy or wp db migrate?
— Lee Blue (@leehblue) August 25, 2016
By the way, there are affiliate links in this post because that’s the way I roll.
My WordPress deployment workflow
There are a bajillion different options for setting up your local development environment. While that’s not directly relevant to the conversation, I’m telling you this because I use DesktopServer which, as well as setting up dev sites, includes a freaking awesome way to deploy a WordPress site to a live server.
Before I get started, it is worth noting that I’m coming from the perspective of a single developer (me) working on a project. If you’re collaborating with other developers or working in an agency setting, your deployment workflow will probably look different.
Situation: That very first deployment
DesktopServer is hands down the easiest way to take a brand new WordPress site and deploy it to a live server. Hands. down. Drop the mic.
All you need to use their “quick deploy” feature is a live server with WordPress already installed. You give the admin credentials for that site and then push a button. Your local site wipes out and replaces the destination site. It’s so easy it hurts.
Situation: I’ve edited theme files and need to push those from local to live
At this point, I’ve got a live site, but I’ve made some tweaks to theme files (or could be plugin files) on my local site that I need to push live. Well, I can’t use DesktopServer’s quick deploy to push those changes because it replaces the entire live site.
I need a way just to push those changed files.
Frankly, I have several different ways of handling this based on the situation (and my mood). 🙂
Quick and dirty
I recently threw together a little site to chronicle my Pokemon Go obsession. This was not a project that called for setting up repositories, compiling CSS, or anything fancy. If I were to accidentally tank this site with a missed semi-colon in a PHP file, it wouldn’t kill me. I’d just restore it and move on.
For sites like this, I use good ‘ole plain FTP/SFTP. It gets my files from Point A to Point B with the least amount of overhead.
Lots of ongoing changes
I like to use Git push for this. From the command line, I can push my changes to the remote (live) server. It’s more work to set up than an SFTP client, but if you’re working in a live staging environment and are gonna be regularly making file tweaks/changes, this is worth the extra effort.
Here’s an article about how I use Git push with WP Engine.
This last one I’m not actually using any more, but it’s still worth a mention. When I say “automated deployment”, I mean that when your code is pushed to a specified repository, that triggers an action that deploys that code to a server.
Situation: There’s new/changed content and I need to sync between local to live
Historically speaking, this has been a pain in the arse. While swapping out files in a WordPress install is a straight-forward affair, dealing with any sort of database sync makes a person want to curl up in the fetal position and cry.
And then came WPSiteSync from Dave Jesch. Imagine you write a new post with some media attachments on your local install and want to push that live. Well, you can. And it’s ridiculously easy. I’m not an affiliate and get nothing for saying that – it’s just a cool product.
You can use it for bi-directional pulls (meaning you can send something live to local or go the other direction with local to live). The plugin is still young – currently, you can sync regular posts, custom post types, and authors.
Support for other content types (i.e. menus, users, comments) is on the roadmap. Perhaps my favorite thing is their Beaver Builder extension. I’m a fan of Beaver Builder (here’s my review) but boy it’s a major pain to work with locally after you’ve done an initial deploy (because the plugin touches your database, not just your files, and database syncing is… well, fetal position/crying).
Anyhow, keep your eyes on WPSiteSync.
Situation: I need to wholesale replace (or get) a database
Here’s a common scenario: You need to build a new WordPress theme (or tweak an existing one) for a client that already has a WordPress site. In this scenario, you want to build the theme around their existing content (and media files) – not just a bunch of bacon ipsum and place kittens.
This is where I unsheath the amazing Migrate DB Pro. I think I’ve been using this for two or three years now and it’s awesome.
In the scenario I just mentioned, I’d install Migrate DB Pro on both my local site and the live site and then I’d pull down the entire database (and media files, if you want them) to my local install. Of course, you can push as well.
There are plenty of other scenarios, but I find myself most using Migrate DB Pro if it’s a project where I’m getting my hands on an existing WordPrses site for the very first time.
Situation: I need to merge two databases
This is one of the biggest headaches in WordPress site management and there hasn’t been an elegant solution. Until now.
This is a (not yet released) product from the same team that developed Migrate DB Pro. If you’re not sure when you’d ever encounter this situation, here’s a perfect example, taken directly from the MergeBot announcement post:
Ok, so you’ve just landed an exciting new client: Springfield Box Factory (boxes!!!). They need some development done to the site. They have an existing WordPress site, so you get a copy of the files and database, set up the site locally and start coding.
A couple of weeks later, you’re ready to deploy your update but realize that while you were making changes to your database locally, the client was also updating the live database and visitors to the site were also adding data. If you just overwrite the live database with your local database, you’ll lose all the changes to the live site made in the past 2 weeks. — Brad Tousenard
Read it and weep.
Other people’s WordPress deployment workflow
Okay, so I’ve mentioned how I like to go about getting a WordPress site from one spot to another, but I’m just one developer with one way of doing things and my way is certainly not the only way.
Here are some articles from other WordPressers you might enjoy:
- WordPress Developers and WP Migrate DB Pro by Tom McFarlin
- Awesome WordPress Workflow with WP Migrate DB Pro and WP Pusher by Peter Suhm (WP Pusher)
- How Reaktiv Studios uses DeployBot in their WordPress workflow
- Leveling up your WordPress development workflow by Dara Skolnick
- WP Development Workflow course with Carrie Dils and Mika Epstein.
So yeah, there’s not just one way to get a WordPress site from local to live — you’ve got a lot of options.
p.s. If you’ve written a post about your WP deployment workflow, leave a link in the comments!