Zach Adams Web Developer and Programmer

Ultimate Wordpress Development Workflow

September 12, 2014

I work for a startup where we handle just about anything Website/SEO/Social Media related. The biggest share of revenue comes from websites and when it comes to making a modular, customizable website quickly, not much can beat WordPress as a CMS. Obviously some people have disagreements because this is the internet and the day that somebody doesn’t criticize somebody else’s preferences is the day we discover World Peace. This is simply my personal preference when it comes to WordPress development.

Update 1/9/2015 – Variable VVV seems to be a better alternative to Auto Site Setup Wizard

Old WordPress Workflow

We started out doing things the old fashioned way.

When I started we had a reseller account with HostGator and we had around 20 WordPress sites in various states of disrepair. It soon became clear that HostGator was not cutting it, their server was too slow to make changes quickly and it often took an hour or more to connect to support who, while competent, didn’t have a lot of fixes.

We developed live or on a shoddy development server we setup. Obviously this led to some serious issues, like clients websites being down or looking really crappy for days at a time. None of us really knew what we were doing and code was often lost or overwritten in the wrong places. The best form of version control we had was FTP and backups of the entire site or specific files stored on our local machines. This led to more problems and more frustrating issues. There are 6 major requirements we came up with that this workflow needed to solve:


  1. Production Server – We needed a solid production server that we could rely on to not go down and maintain 99.99% uptime.
  2. Staging Server – We needed a testing environment similar to A2 just to double check that the site works in a live environment. It’s also a good way to show clients progress and get their input.
  3. Local Server – We needed a way for us to work on our sites locally without a whole lot of hassle.
  4. Move Code Between Servers – We needed this to be fast, simple and easy without FTP.
  5. Modern Coding Practices – Duh.
  6. Sharing Code – We need to be able to share our code easily and quickly.

The Solution

First Issue – Good Production Server

We upgraded our server to a solid reseller server from A2 Hosting which showed immediate performance improvements.

A2 Hosting (Refer a Friend link)

A2 Hosting (Regular link).

This reseller included WHM which includes cPanel for every client’s site. A lot of people don’t like cPanel for it’s ‘bulkiness’ and they’re totally right. However some clients do need access to make some changes to the way their webserver runs, and so far I haven’t found a good replacement that’s as easy for clients to use. So for now we put up with it.

Another important thing that’s required in this server is SSH access, and A2 makes it pretty simple to connect to your sites so you won’t have to worry much about it. A2 also has a pretty great collection of tutorial articles both for their services and server management in general.

Access your account with SSH – A2 Hosting

Second Issue – Staging Server

This one was a little more difficult. We needed an environment similar to A2 however WHM is not free nor cheap.

We decided to settle for a simple LAMP server hosted with Linode (Also highly recommend). We also needed replacements for cPanel in case we needed to access the server to debug, so we settled for eXtplorer which provides a file manager similar to cPanel. We also installed phpMyAdmin for database administration.

We setup a subdomain for development and put each site into it’s own directory so that it’s easily accessible to clients who want to see progress.

Third Issue – Local Server

Here’s where things get a bit tricky. Since Windows didn’t really suite my new workflow needs I setup a dual boot on my work computer so I can easily switch between Windows and xUbuntu whenever the situation required it.

Update 1/01/2015 – I recently got a Macbook and this workflow works just fine on a Mac environment

Unfortunately if you’re a Windows user this is probably where you’re going to have to get off, as I don’t know exactly how this would work on a Windows machine.

For the server part, we decided to use Vagrant. (Why Vagrant?)

Vagrant by itself is great, but you have to install and configure all your software by hand. This will lead to issues, however luckily there’s a solution that’s simple and easy to work with:

Varying Vagrant Vagrants (VVV) – A WordPress specific Vagrant machine that allows multiple WordPress installations to play nicely on one machine. By default it comes with 3 WordPress blank installations for the Stable, Trunk and Develop branches of WordPress so you can test Themes and Plugins with the newest versions.

VVV is great but it only comes with 3 installations by default and you’re going to need one for each site you’re working on. VVV tells you how to setup new WP sites, however IMO it’s a little tiresome. This is where Variable VVV comes in:

Variable VVV – Very neat little script from bradp that takes care of the grunt work setting up and taking down sites in VVV. Using Variable VVV you can create new sites or delete old ones on your VVV machine with just one command!

With Variable VVV and VVV creating and managing your Local Server is quite easy and simple.

Fourth Issue – Moving Code Between Servers

This was the issue that stumped me for the longest time. There seemed to be no truly easy way to push the entirety of WordPress, database and all, quickly and easily between the separate servers. There were solutions out there that seemed too complicated and required the knowledge of other languages just to get around. I needed something simple.

Then I discovered Wordmove.

This is the saving grace of this entire workflow. Pushing an entire WordPress site live is as easy as typing

wordmove push -e production --all

And pulling a site from production to local for patching is as easy as

wordmove pull -e production --all

Wordmove works best with SSH due to it’s use of rsync which makes copying files super duper quick (like anywhere from 5-10 times as fast as FTP) but it can also work using FTP (even including the database!).

Basically the only configuring you have to do before hand is inside the Movefile. The Movefile is just a file titled “Movefile” which you place inside the default WordPress directory you want to move.

Using this you’ll never have to worry about renaming your site url or uploading your zipped code to a server, it takes care of everything automatically.

Fifth Issue – Modern Coding Practices

We also found ourselves using an abhorrent number of bad coding practices in our sites including adding an ungodly amount of unnecessary CSS and Javascript to our pages where they weren’t required. WordPress is notoriously bad at this, so we tried some tactics to fix this.

First – Sass

Sass makes coding CSS fun again. It takes most of the bad things about CSS and fixes them. I won’t go into detail about how awesome SASS is, just read their site. Sass does require either Grunt or Gulp to compile it correctly, and that’s what I’ll talk about next.

Second – Gulp/Grunt

There’s a lot of debate as to which is better, but for this workflow I use Gulp. You can use either as preference.  Both allow for the compiling of SASS into a single CSS file which is huge for a better WordPress site. We can also set it up with Livereload which really takes some pressure off my F5 keyboard button .

Third – Theme Setup

Taking the time to setup a solid, working default WordPress theme can save a massive amount of time. In our case we started with the _s Wordpress starter theme and refactored the Sass directory to be more like this. Then we refactored the functions included to be a lot simpler. What resulted was an extremely simple starter theme that was customized for our usage.

Recently I’ve setup a public starter theme which allows you to use the Twig Templating Engine along with Sass and Gulp for quicker theme development:

Sprig WordPress Starter Theme

Sixth Issue – Share Code Easily

There’s really only one correct way to do this and that’s using Git. Learning Git isn’t actually as hard as a lot of people make it out to be, you only really need to know the absolute basics such as adding and committing and you can learn the rest when you need to. There are any number of awesome Git tutorials out there, and knowing it is absolutely necessary for a solid programming workflow, no matter what language you’re using.

We setup a Bitbucket account for our company. Each project get’s it’s own repository and the code can easily be pulled and pushed between the 3 of us without any inconsistencies. We chose Bitbucket over Github just because of the free private repositories, though it’s really up to your preference, either will work awesomely with this workflow.

New WordPress Development Workflow

Here’s what a typical day looks like:

  • Log in, boot up VVV with ‘vagrant up’
  • Find site I was working on, start up Gulp with ‘gulp’ and begin coding while documenting with Git
  • When a coworker needs updated code for a site I push my local Git changes to Bitbucket
  • When I reach a point where I can show the client progress I run ‘wordmove push -e staging –all’ and email the client with the changes
  • When the client is happy enough I can push the site live with ‘wordmove push -e production –all’

When a client has new changes from a site that’s already live:

  • Move to local directory and run ‘wordmove pull -e production –all’ to pull site from live to update local version
  • Begin updating with new patches, documenting with Git
  • When I have something I can show the client I push it to staging with ‘wordmove push -e staging –all’ and when they’re happy enough I can push it live with ‘wordmove push -e production –all’

When I have a new client

  • Move to VVV directory and run ‘vv -c’
  • Run through Variable VVV script (Can take up to 5 minutes, go get a coffee)
  • Setup new default WordPress site with our default theme, and relevant plugins/settings.
  • Begin working like usual

book-cover-2I’m writing about book about Modern WordPress Workflows! Click here to find out more!


Griffin says:
September 13th 2014 at 12:00am
I've been looking for just this sort of workflow for the past few months with my chosen flavor of Linux! Some of the other methods I have tried either didn't work or left vital steps out of a newbie's reach. I'll be giving your method a shot this week - I cannot freaking wait!
Richard Buff says:
October 7th 2014 at 12:00am
My favorite part about this is that you didn't just give a broad overview and call it a day, you actually broke down the steps for difference scenarios. To me, that's the difference between a good post and great one. Keep it up!
Devon H. says:
October 14th 2014 at 12:00am
Zach, Thanks for the awesome guide! I've managed to get the majority of your system working on my local machine, and have been able to get my files to transfer to my Digital Ocean droplet running their LAMP stack option, but I'm having trouble with the config.php file. I've created the database on my server, and the information is correct (verified by switching it out and receiving the errors for incorrect data), but it refuses to create the config.php file, or read the one that already exists within my setup. Also, my movefile is sitting in the folder above htdocs, with the vvv-init and such. Should it reside in the htdocs folder instead?
Deric says:
January 5th 2015 at 12:00am
Nice workflow! I have started to implement this into a couple of my projects. One question, how do you handle renaming fields in the database with the production servers ur?. In other words, changing all of the entries in the DB into Is this something that you do after the fact in phpmyadmin? Thanks for the help!!!
Daniel says:
January 13th 2015 at 12:00am
First, this workflow and walk-thru are phenomenal. I've been on the hunt for the best wordpress workflow for awhile now and instantly fell in love with what you guys have came up with. However... I'm having a world of an issue with what seems to be the very last step, wordmove. Namely, the db import/pull pertaining to the siteurl and homeurl within the wp_options table. I am trying to pull a current project from a live/remote server into a new vvv local wp install. No matter what I do, on pull, everything runs great, uploads/themes/pages/posts/etc all of it, except the live url replaces my local urls within the wp_options table in my localhost db. Of course, this makes the local install useless until I manually modify those using phpmyadmin... and of course, pushing causes the same issue, but in reverse. For a few days now, I've tried modifying table prefixes, default 'wp_' prefixes, every order of operation I can think of, but all to no avail. When running: 'wordmove pull -e staging -d' or 'wordmove pull -e staging --all' everything runs great, but the staging/live url gets imported into my local environment and vice-versa on push. Did you guys run into these issues... ever? I've been hunting for days and can't seem to figure this one out.
Arsy says:
January 13th 2015 at 12:00am
Great post!
Merv says:
January 18th 2015 at 12:00am
grat workflow thanks for sharing. Will be looking into the pushing/pulling/ to the production and dev servers. On another note MAMP is available for Windows now instead of just Mac. It's excellent.
erik says:
February 11th 2015 at 12:00am
totally going to hijack this from you! great article. this basically covers all the crap that i deal with on a daily basis. Question - have you ran into any issues with VVV being LEMP (nginx) and whm running apache? i am using a whm/cpanel server as well, and am alittle worried about developing on nginx and then pushing to apache.
Lucas Jahn says:
February 22nd 2015 at 12:00am
Great article man! Keep on going the good work and thanks a lot. it works just perfectly! (also on windows machines)
Zee says:
March 2nd 2015 at 12:00am
This was really helpful. :) After reading this, I am trying to configure wordmove with SSH right now but it's not working. Is it possible to have a look at your movefile please? Thanks for sharing!
Bob says:
March 13th 2015 at 12:00am
Great article, I just have a couple questions. Having a little trouble with wordmove too. Works on everything but pulling the database files. If you have any thoughts on troubleshooting I would appreciate it. Second, how do you switch your browser between the dev, staging and production sites? hosts file editing seems awkward, slow and an opportunity to confuse the sites.
Bob says:
March 13th 2015 at 12:00am
This also looks interesting.
Luigi says:
May 29th 2015 at 12:00am
hi, just few question about your workflow: 1) why pay linode to have a staging server? isn't it much easy to create a subdomain on the same live server? ex. .../www/"files-live-wp" and .../staging/"project-name"/"files-staging-wp". More easy and staging and production has the same. 2) can i have much details about team coworking? each time my coworker want to change samething he has to call me? and then i have to push on my remote repository? i think that we need a way to make each coworker indipendently. isn't it? is it operable automatic synchronization beetween my local and remote repository? 3) how is it possible to version controlling also the database? it would be nice if we can rollback always the database. isn't it?
Tony says:
June 3rd 2015 at 12:00am
Hi Zach, This is really awesome! Thanks for the great write up, and for sharing your great workflow! I just setup Varying VVV yesterday and it's awesome. Now I'm working on a better way to move my sites back and forth and have been looking at Wordmove. I have a question I'm hoping you can help with, and haven't been able to find out anywhere. I see how powerful it is in pulling and pushing site files and databases. Do you also use Wordmove to clone a site from production to your local dev setup? It seems like that would also work, but I thought I'd ask if you've used it this way. Thanks again! Tony
Joe says:
June 14th 2015 at 12:00am
Thanks Zach! This post is the first time I heard of Wordmove. I will be sure to check it out. I am trying to figure out how to version control the actual VVV box separate from the sites inside. It got corrupted today and I had to destroy it then recreate it.
Tony says:
July 8th 2015 at 12:00am
Thank you, Zach! Looks like it's going to be a huge timesaver. I'll give this a shot. Thanks again for the great tut and follow up.
Alex says:
November 15th 2015 at 12:00am
hi, nice tutorial. What happens with the database in this scenario. If you make changes to the theme these get stored in the database. in your setup you will have to login production and fix that ? I have found multiple tutorials on the subject but all skip the database part. What if an article is stored on the production server and you would deploy all from staging to production. This is were I'm struggling with finding solutions. cheers
Chris says:
December 14th 2015 at 12:00am
Great writeup on VVV! Thanks! Especially WordMove.. Do you still recommend a2 for your clients who need CPanel? They look like a decent reseller. says:
January 24th 2016 at 12:00am
Thanks for another informative site. Where else may just I am getting that type of information written in such an ideal method? I've a challenge that I am just now running on, and I have been at the glance out for such info.
David says:
December 8th 2016 at 12:00am
Very nice article ! I almost got the exact same workflow ! Been using Wordmove for two years and I am not looking back ! Being able to push/pull both files and database is great !
Rajavanya Subramaniyan says:
August 2nd 2018 at 12:00am
Thank you for this Zach. Been having a hard time, not having a local dev machine as we were multiple people. How do you deal with two people working parallel-y. How does the wordpress database sync then? How do we prevent overwrite of content changes to pages by different people?

Leave a Reply

Your email address will not be published. Required fields are marked *