WordPress Workflow Series: Part I

Raise your hand if you’ve ever used an FTP client to make a file update directly to a live site. Now keep your hand up if you’ve ever made a file update that broke a live site. If we’re being honest, there are probably a lot of hands up, including mine.

The practice of “cowboy coding” (i.e., editing files on a live server) is how many of us got started. Often, we recognize that it’s not a good practice, but the process of moving to a better workflow can seem daunting. This series is intended to help you understand and implement workflow best practices when developing WordPress sites. Maybe you’ll even decide to retire that cowboy hat. 😉

Understanding the principles behind a solid development workflow

When you start reading about workflow, it’s easy to feel overwhelmed by the various tools and techniques. However, it’s important to remember that a solid workflow is based on a few basic principles. This article is meant to be a high-level overview of the concepts behind workflow best practices.

My goal is to explain how everything fits together so that you can follow best practices in your workflow, regardless of the tools you’re using. In future articles, I’ll talk about the specific tools I use in my own workflow and provide more specific guidance about how to get started.

1. Use a local development environment.

If you do nothing else to improve your workflow, at least consider setting up a local development environment. This means that you’ll have a copy of the website you’re developing running on your own computer.

Working locally means that you’re free to make mistakes and test things out without the fear of breaking a live website. It also makes it easier to edit files since you don’t have to worry about transferring the file up to the host server every time you want to test an update to your code.

2. Set up automated backups of your live site.

While this might not be strictly considered part of your development workflow, it’s absolutely essential to maintain regular backups of your live site. There are many ways to do this, but whatever solution you’re using should meet the following basic requirements:

  • Backups of your entire site (including files and database) should run automatically and reliably at regular intervals.
  • You should be able to set the backup interval and the number of recent backups to be stored based on what makes sense for the particular site you’re maintaining.
  • Backups should be stored somewhere that is NOT your host server.
  • You should be able to restore your site using one of the saved backups. (Test this periodically in your local development environment.)
  • You should be able to easily roll your live site back to a previous backup point.

3. Staying in sync: Code moves up, database moves down

Once you’re comfortable developing locally, you’ll probably start to wonder how you can keep the local copy of your site in sync with the live site. What makes this a little tricky is that WordPress sites consist of both files (including your theme, plugins, and WordPress core files) and a database (which stores your content and any configuration settings).

To follow best practices in modern software development, remember this general principle:

Code moves up, database moves down.

How does this work in practice? Consider the following examples.

Case 1: Updating child theme files (code moves up)

Let’s say that you want to update some files in your site’s child theme. In that case, it’s best to set up a local copy of your site, make and test the code updates, and then “deploy” those updates to the live server. By adhering to the “code moves up” practice, you will ensure that you won’t break the live site by introducing PHP or CSS errors.

Case 2: Updating content and settings (database moves down)

Now let’s say that you want to write a blog post or change a setting in the WordPress dashboard. Those are updates that affect the database, and therefore they should be done directly on the live site. When you want to sync your live and local copies, you should bring down a copy of the live site’s database to your local copy.

What’s important to remember is that your live site’s database is in constant flux. For example, somebody might be writing a comment on your blog post or placing an order in your eCommerce store. Those are both examples of transactions that are stored in the database. So if you were to bring a copy of your local site’s database into the live site (i.e., moving the database up), you would risk losing any new comments, orders, etc., that were added after you set up your local copy.

What about plugins and uploads?

You may be wondering how plugins and uploads fit into the “code moves up, database moves down” scheme. While uploads are technically files, they should be treated as content because uploading a file to the media gallery actually creates a new post in the database. So uploads should be made on the live site and then brought into the local copy.

Plugins are interesting because they are files, but they sometimes have settings that you can configure via the WordPress dashboard after installing them, and those settings are stored in the database. What I would recommend is to always install and test plugins locally first. Once you’ve confirmed that you want to use the plugin, you can push its files upstream from local to live and then apply any configuration settings on the live site.

Similarly for plugin updates, I’d recommend to run those on the local copy to ensure that they don’t break anything and then push the updated files up to the live site.

In a future post, I’ll describe some ways to sync uploads and plugins between your live and local copies.

4. Use version control.

In the previous section, I mentioned making file changes on your local copy and then “deploying” them to your live server. Using a version control system makes the deployment process easy by tracking which files you’ve updated and enabling you to “push” those file updates to the live site.

An effective version control system should do the following:

  • Keep a running history of all file updates, showing specifically which files where changed and what those changes were.
  • Deploy file updates made locally to the live site.
  • Enable you to revert to an earlier version of your code.
  • Enable you to work in parallel with other developers.

In future posts, I’ll go into detail about how to set up and use a version control system with WordPress.

5. Maintain staging installs on the host server.

For the sake of simplicity, I’ve only mentioned working with local and live copies of a site so far. However, it’s a common practice to additionally maintain one or more copies of the site on the host server that are designated as “staging” copies. (These might also be labeled “dev” and/or “test” installs.)

Because they’re hosted on the exact same server as your live site, staging copies can be used as intermediate environments where you can test your updates before moving them live. This is especially important because your local server may not always match the exact configuration of the host server. Staging copies can also be useful to allow clients to preview and approve updates before they are deployed to the live site.

In the diagram below, you can see how the staging copy fits into the development workflow. The general principles still apply, but we’re just adding an intermediate environment. So you would move code from local -> staging and then from staging -> live. And you would copy the database downstream, from live -> staging and from staging -> local.

6. Document your workflow and communicate with other developers.

There are many great tools that will help you streamline and automate your workflow. However, there’s nothing that will replace good old fashioned communication. It’s important to communicate with other developers working on the site to ensure that everyone is on the same page about the development workflow and also to coordinate who’s working on what.

It’s also a good idea to maintain documentation for the sites you build. Especially as workflows become more complicated, it will be helpful to anyone working on the project to understand the specific workflow that you’ve set up. Even if you’re not working with others, the documentation will help you get back into development if you haven’t worked on the project in a while.

How to get started

If you’re a cowboy or cowgirl coder who is curious about improving your workflow but not sure where to start, my advice would be to move into a better workflow one step at a time. In future posts, I’ll go into more detail about how you can start improving your WordPress workflow by implementing the concepts described in this article.

Leave a Reply

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