In the last year or two, lots of new tools have come along and made developing WordPress themes or client sites much easier. Code sharing has been made infinitely easier with Git and Github, automation is huge these days with Grunt, and CSS pre-processing has really taken off with LESS and Sass.

All these new tools make dealing with code easy and fun, but what about that pesky WordPress database? In this article, we’ll look at using Git along with an incredible new plugin—Migrate DB Pro—and see how it completely changes client site development.

Let’s outline where we are with our project:

You’ve started work on a site with a brand new client. It’s a medium-sized site with a combination of static content and custom post types. You have already met with your client a few times, and you’ve got a design approved and a new custom theme well underway. You’re about 2 weeks into the project and you want to start getting some feedback. You also want the client to start working with on the live content.It’s time to move the site from your local machine to a live development server that you can share with the client. How do you get your code to the live server? Spoiler: not ftp. Let’s get started!

Using Git to move your code around

Unless you’ve been living on the moon for the last few years, you’ve heard of Git. You likely know that it’s a version control system and that it’s great for working on projects with teams. What you might not know is that Git is just as handy for a team of one as it is for a huge development team.

I work alone or with just one other person on all my projects, but I still use Git on every one. Using Git gives me three huge benefits:

1. Unlimited undo — as long as I regularly commit changes as I go, I’m able to undo anything via Git’s revert command. Just pick a commit that I want to roll back to, and within seconds I’ve gone back in time.
2. Branching — In a very small nutshell, branching allows me to effortlessly try something out. I can create a new branch and make large changes across a bunch of template files and in my stylesheet without having to worry about what I’ve changed. When I’m done playing with my new feature, I can either bring these changes back into master or simply delete them.
3. Github — Github is an amazing tool for you to use as a single developer. Though designed to aid collaboration with teams, Github has some amazing tools for your little team of one. We’ll look at one of these tools for autodeployment in a minute.

Setting up a live development site

To get this working the way I describe, you’ll just need to have your own server where you can setup a development site for your client, and be able to access it via ssh in a Terminal.

1. Create a new site for your client on your web host
2. Install a fresh copy of WordPress for the site
3. Create a new repo in your theme directory and push your theme up to Github
4. Login to your live server via ssh and clone the repo you just created

When you’ve got this done, you’ve got a dead-simple transport system for your code. When you make changes locally, just commit them, push them to Github, then pull from there into your live site. You’re essentially using the Github as an intermediary. I remember a few years back when I realized that I could do this—it was a huge lightbulb moment for me. I always found FTP to be completely agonizing, so it was a huge win to no longer have to FTP files up to the server. All I had to do now was a simple git push, log into the live server and do a quick git pull and everything was in sync. I was thrilled! It wasn’t until I discovered a little-known about Github feature that I really knew how good I had it.

Automating the deployment

Pushing all my changes to Github and then pulling them into my live server is fantastic—but we can make it even simpler. Github has a number of “Post-Receive Hooks” available to you. That sounds complicated, but it really isn’t. In short, these hooks let you do different things after Github detects that you’ve pushed a new commit. For our client site, the thing we want to do after a new commit is detected is automatically push it to the live site. To do that, all we need is a file in our theme on the live site that has a simple ‘git pull’ command in it. When Github detects a new commit(that’s the post part of post-receive), we tell it to go look at that special file in our theme. Here’s how we do that:

1. Create a new file in our repo called github-auto-update.php
2. Put just this one line in that file: <?php `git pull`; (no closing tag)
3. On the project’s repo page in Github, visit Settings > Service Hooks > WebHook URLs
4. Enter the path for the file you created above. It will look something like: http://example.com/wp-content/theme-name/github-auto-update.php
5. Test that you’ve done this right, by committing a change locally and pushing it to Github. If it is setup properly, Github will detect the new commit, it will trigger that github-auto-update file to run, and your changes will be pulled in to the live server. Just like magic.

When you’ve got this setup properly, you’ve saved a step. You no longer need to login to the live site and pull in the changes—Github does that for us automagically.

Now that we’re all set up with Git and Github, we’re really in good shape. We can get any new code changes to the live server by just committing it and pushing it to Github. But that’s just the theme code. Remember that pesky database? How do we move that back and forth? As it turns out, we’ve got a great solution for that too.

Getting the client involved

I like to get the client involved in content development as early as possible. I want them in there working on a live install of WordPress, mucking around with Posts and Pages and images and asking questions and making a mess of things until they get the hang of it. When my client logs into their WordPress site for the first time, the theme is about 75% developed and I’ve got a little of the content already in there. It’s their job at this stage to work on the rest.

The problem with this setup should be obvious: I still want to work locally on the code while the client works live on the content, and I want to regularly pull in the content that the client has been working on. We’ve solved the problem with moving code around above — just let Github automate the process, but the database presents a different challenge. Until now, our options here were limited: create a wxr export file in WordPress, constantly get sql dumps of the live database, or go in and manually copy and paste the content (if there wasn’t too much of it). All of these options work, but they are all cumbersome and time consuming. Thankfully, we’ve got a new, secret weapon: Migrate DB Pro.

Using Migrate DB Pro to move your content around

Migrate DB Pro has completely fixed the pain of trying to keep local and live content in sync. Instead of exporting and importing xml or sql files, you can get a copy of the live content with the click of a button. Now, you can hack away on the template files and theme functionality, while your client works on content. When you want to pull in the latest content, Migrate DB Pro is there to help.

Just like with Git, Migrate DB Pro has two main actions: pushing and pulling. Pull content in from the live server when you want to get the latest that the client has added, or push out to the live server when you’ve added content.

 

Migrate DB Pro, as the name would suggest, is a commercial plugin. The prices range from $39 if you want to use it on a single site, to $99 for the developer license, letting you install it on unlimited sites. If you develop a lot of themes or client sites with WordPress, you could think of this as investment in your time and sanity—over a few months, this plugin could save you hours of time and frustration.

When I first started working with MDBP, I looked it as a tool to help move my site when I’m finished local development. I’d seen a few existing plugins around already that seemed to be doing the same thing as MDBP, but it wasn’t until I started using it that I realized how useful it is for the entire development workflow. In a nutshell, MDBP was to my database, what Git was to my code. Using Git alongside MDBP meant that I could now effortlessly move both content and code between the local and live servers. Let’s see how.

Pulling in the client’s content

Our client has been working diligently on the content. They’ve got all of the static content entered, they’ve written a few blog posts and they’ve populated all of the custom post types we’ve set up for them. The latest version of the content I have is from a few days ago, so I’m way behind.I need to pull in all the latest changes before I continue coding.

1. Install MDBP on your local site as well as on the live development server
2. Connect the two sites using the API keys
3. Allow your local database to be overwritten
4. Pull changes into your local site and overwrite the database

Move all the things!

MDBP is extremely powerful for moving content around. You’re regularly pulling all of the content that the client has entered to your local site, but it doesn’t stop with content. You’ve got a motivated client and they want to launch the site as soon as humanly possible. They’ve gone through the dashboard with a fine-tooth comb entering settings and filling everything out. They’ve put in their Google Analytics and Typekit codes, entered the site tagline, arranged menus and widgets, and set the permalink structure. Before MDBP, your only option to get all of this customization was to get a sql dump — and we’ve already talked about how painful it is have to continually do that.

With MDBP, we can pull in all of these settings—from WordPress content and plugins— to our local development environment with a single click.

Multi-device, Responsive testing

Everything is moving along very nicely now. You’re pushing all of your latest code to the live server with Git and Github, while regularly pulling database content in with MDBP. You’re all set for the last stage of development — testing!

You know the drill here. The client has a long list of devices: Blackberry, Android, all the iPhones and iPads, old and new PCs, IE8, old versions of Firefox, etc. They want the site to work on literally everything out there. There are several ways to serve your site from your local machine, but I’ve never gotten them to work properly, and nothing beats native devices anyway. So the answer is clear: you need to test on a live site.

Good news is, you’re already there. You’ve been pushing your code to the live development site, and pulling back all the content that the client has been working on. The live site is ready for testing. As you test on the various devices, you can make adjustments in your media queries as you go. The only small issue here is that you need to commit each small change before you can retest it on a device. This results in a lot of very small commits at the end of the project, but I find that that really isn’t a big deal.

Roundup

So there you have it. A client project, right from start to finish — from design, to client interaction, to multi-device testing — made completely simple to manage using Git and Migrate DB Pro. Let’s quickly recap what we’ve learned:

1. Using Git is useful even for a team of one — for letting you undo mistakes, and effortless feature experimentation with branches, you should be using Git on every project

2. Git is great, but Github makes it even better — you can use Github as the intermediary between your local setup and the live site. Use Github to backup your code as well as auto-deploy it to the live server with a post-receive hook.

3. Migrate DB Pro was sent from database heaven — using MDBP, we can regularly pull in content, plugin settings, menus and widgets that the client has been working on from the live site. No export files, no database dumps—just the click of a single button.

Getting the client involved in a site used to be a pain, but it really isn’t anymore. Git and Migrate DB Pro make short work of moving code, content and settings around. If you haven’t added these two tools to your WordPress development workflow, you’re working too hard!