A Simple Workflow for WordPress Development

I recently collaborated on a WordPress project with a developer who had never used a modern front-end workflow. While that’s understandable, I wasn’t about to give up Sass, or go back to the old days of FTPing files up to a server. And with two developers working on the same project, version control – Git in particular – was a must so that we wouldn’t overwrite each other’s work. My challenge was to introduce these concepts and tools to him in the fastest way possible so that he could jump right in and get to work.

That’s why I developed this workflow. It’s easy to learn and it provides failsafes and safety nets that help you develop with confidence. It takes a bit of work to set up, but once you start using it, I doubt you’ll ever go back to your old ways. If anything, you’ll want to tweak it to make it your own.

With this workflow, we’ll be developing on our local, using Git for version control and deployment, safely syncing our database, and using a starter theme that comes preconfigured with modern front-end tools that make developing our site easier and more efficient.


THE WORKFLOW EXPLAINED

This workflow uses WP Engine* for managed WordPress hosting for several reasons. First, they support deploying with Git. Second, they have three server environments – Production, Staging, and Development. This means we can use version control and follow a proper workflow. Having a Development server means that we can test our work on a remote server without our client seeing unfinished work. Once we’re ready for client feedback, they’ll view it our Staging server.

For our Git repository, we use Bitbucket. Bonus: WP Engine supports Bitbucket pipelines for building and deploying our code. What is a pipeline?

Bitbucket Pipelines is an integrated CI/CD service that allows you to automatically build, test and even deploy your code, based on a configuration file in your repository.

Atlassian Documentation

It sounds pretty technical, and I’m sure behind the scenes it is, but thanks to WP Engine, it’s easy to set up. Once we set up a pipeline for our Staging server, any time we push code to the Staging branch, our changes are deployed to the Staging server.

With Bitbucket’s free plan, you get 50 minutes of build time per month. Assuming each build takes about a minute, that’s approximately 50 Staging deployments per month. Those minutes get eaten up pretty fast when you’re developing, but fortunately, there’s an alternative. We can deploy directly to WP Engine’s Git repositories (each server environment has one). So rather than using a Bitbucket pipeline for our Development server, we first push our develop branch to Bitbucket, and then merge it into our WP Engine Development server repository. Once we push that branch, WP Engine rebuilds the site, and voilà, our changes are on the Development server.

So as you can see, we have two options for deploying our code to the WP Engine servers: Bitbucket pipelines, or a WP Engine server repository. We’re using a pipeline for Staging because it’s less steps, and we’re using the WPE Development repository for Development to save on Bitbucket build minutes.

That takes care of deploying our code, but what about the database? Before we get to that, let’s look at the recommended best practice:

DATABASES MOVE DOWN, CODE MOVES UP

Source: WP Engine

By sticking to these simple rules, you can help ensure you don’t overwrite important information on your production site when making changes.

WP Engine Documentation

The key is to be consistent. Shortcutting this rule will eventually lead to confusion and mistakes.

Git takes care of the first rule: our code always moves up to the WP Engine servers, either through a Bitbucket pipeline or directly to a server environment’s repository. For the database, we only update content on the Staging server, and we pull it down to our local environment and to the Development server. We use a tool that makes this foolproof: WP Migrate DB Pro allows us to set this up once and save a migration that only allows data to move down.

Here’s an overview of our workflow. As you can see, files only move up, and the database only moves down.

Post launch, you’ll probably want to make the Production server the master database. If your site has user input such as comments or reviews, you don’t want to overwrite that content when doing updates. Before making changes on Staging, first copy the site from Production to Staging, make and test your changes on Staging, and then copy Staging back to Production.

OTHER TOOLS

For our local server, we’re using Local because it’s dead-simple to spin up a local WordPress install, and the UI makes it easy to access both the front-end and WordPress admin dashboard. For our code editor, we use Visual Studio code for the built-in terminal window, native Git support, and the Atlassian extension for Bitbucket – optional nice to have features!

We’re using Tower as our Git client because it makes working with Git super easy, even for someone who has never used Git before.

For our starter theme, we’re using the Understrap theme with an Understrap child theme. (This site uses Core, but for custom sites we use Understrap Child.) Understrap combines Automattic’s Underscores starter theme with Bootstrap 4, so we get all the Bootstrap components and the responsive grid right out of the box. It may not be the most performance-minded stack on the block, but running on WP Engine, its performance scores are quite respectable.

Underscores also includes Sass, npm, and Gulp, and there’s almost zero configuration, so even if you’re not experienced with this sort of workflow, it’s easy to get started.

UnderStrap uses npm as manager for dependency packages like Bootstrap and Underscores. And it uses Gulp as taskrunner, for example to compile .scss code into .css, minify .js code etc.

Understrap Documentation

And finally, we install our favorite WordPress plugins, like Advanced Custom Fields, Gravity Forms, Yoast SEO, etc. locally so they’re in our Git repository, and then activate/configure them on our Staging server so that their settings are stored in our master database.

So that’s our current workflow. So far it’s worked well for us. Even my colleague who had never used version control or a modern, front-end starter was up to speed and contributing in no time.

I’d love to know what you think about this workflow. Does it sound useful? Are there things you’d do differently? Please let me know in the comments section below.

COURSE COMING SOON!

For those of you who are new to all this, I’m working on a course that explains how to set up and master this workflow.

If you’d like to be notified when the course is ready to launch, please fill out the following short survey (6 multiple choice questions) and subscribe for updates. Your answers will be invaluable in shaping the course content.



About the author

Brian Steele

Brian is a remote, freelance web developer who lives and works in Muskoka, a ways up the road from Toronto, Canada.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.