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:
- Production Server – We needed a solid production server that we could rely on to not go down and maintain 99.99% uptime.
- 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.
- Local Server – We needed a way for us to work on our sites locally without a whole lot of hassle.
- Move Code Between Servers – We needed this to be fast, simple and easy without FTP.
- Modern Coding Practices – Duh.
- Sharing Code – We need to be able to share our code easily and quickly.
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.
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
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:
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
I’m writing about book about Modern WordPress Workflows! Click here to find out more!