A WordPress Deploy Workflow

The Backstory

Here at Pacific Sky, we build most of our websites with WordPress. There are a lot of reasons for this, so I won’t go into them here. Suffice it to say we work with WordPress a lot.

I’ve been using a custom fork of Mozaik’s WordPress theme starter for a few years now and brought the tradition with me to Pacific Sky. That starter may be the subject of a future post, but basically what it provides is a build environment for WordPress that allows me to write SCSS for styles, manages asset minification, and a whole host of helper utilities that really speed up custom theme development.

What we needed was a way to quickly pull down changes from a production site to our development environment and to push those changes live once changes have been made.

There are tools that help automate this process but most of what I had found was based on Capistrano. Capistrano is great but I don’t know the Ruby language in which it is written and don’t want to deal with the additional overhead of a new language. I really wanted something written in PHP.

That’s when I came across this blog post (archive.org). The author, Arnaud Sellenet, had written a WP-CLI plugin that did exactly what I was looking for.

If you’re not familiar, WP-CLI is a piece of software that allows you to manage a WordPress instance from the command line. So, you can type into a terminal wp deploy push production or wp upgrade instead of using the dashboard.

Despite being several years old, the plugin still worked and served our purposes with a couple tweaks, mostly relating to the theme starter we use. I got in touch with Arnaud, who’s moved out of the PHP/WordPress world and was gracious enough to allow us to continue maintenance of the plugin. Now that the original blog post is only available via archive.org, I’m writing a how-to to replace it. I haven’t tested the command-line functionality yet but the process should be the same once it’s ironed out.

Requirements

Experience using WordPress

A development server and a production server (at minimum, but you may have as many remote environments as you please)

SSH access to your production server (SFTP logins usually work)

How To

1. Make sure rsync is installed on both your development server and your production server. You may check by entering which rsync into the command line of both servers. rsync is installed if a path appears (e.g. /usr/bin/rsync). rsync is a utility that synchronizes directories across two different computers and is essential to uploading and downloading files.
2. Install WordPress with the WP Deploy Flow plugin
3. Add your server configurations.
   What you’re doing in this step is to add your remote server’s information into the plugin at Tools -> Deploy. This is where the WP Deploy Flow Plugin will get its information when you go to deploy. We call our remote server “production”
   1. path This is the path on the remote server to which WordPress will be uploaded
   2. url This is the final URL of the site
   3. db_host This will go in the DB_HOST constant of the remote instance, so probably 127.0.0.1 unless you have different database and file servers
   4. db_user The user of the remote database
   5. db_port Probably 3306. I would leave it blank.
   6. db_name The database name on the remote site
   7. db_password The database password for the remote site
   8. ssh_db_host The username used to log into the database host via SSH. This is probably the same as ssh_host
   9. ssh_db_path Probably the same as path, unless you have different database and file servers
   10. ssh_host The url or IP address of the remote site through which you will SSH
   11. ssh_user This is the user through which you will SSH to the remote site
   12. ssh_password Your SSH password to the remote site
   13. excludes A comma-separated list of files to exclude from transfer
   14. path_owner The path owner of the remote path. I would set to www-data if you don’t know
4. Use!
   You’ll have push and pull commands for the environment now, along with the option to run it as a dry run. Note that you’ll be logged out of whatever environment receives the database as its sessions will be invalidated.