Odds are, you have heard the term “workflow” in the web development field, especially if you’ve been doing it for any significant amount of time. For those who may be newer to WordPress development, it may not be something you’ve established or are totally familiar with. Basically, a workflow is simply your work process – the steps you typically take when working on a project.

In this post, I’m going to share my workflow for the purpose of helping new developer create their own process. My workflow is not the most elaborate and it’s something I’m frequently modifying. However, this process is the one I’ve been following a lot lately and is one I’m happy with for now.

Workflow Tools

Web/software development has its “tools of the trade”. These tools include applications like text editors, local servers, etc. They also include technologies like Grunt and other task managers. Here’s what I use:

Sublime Text 3

Sublime Text is, in my opinion, the most powerful and easiest to use text editor on the market. Some would certainly disagree with that in favor of options that are more powerful (i.e. PHP Storm) and, although I’ve not used many other editors, the ease and power you get with Sublime is excellent. I started using it a while back and have no intention of switching anytime soon.

Sass

Sass is a CSS pre-processor that makes writing CSS a hell of a lot quicker and more efficient. Sass is not rendered by a browser so it must be compiled into a standard .css file (more on this in a bit). I also use Compass on my Sass projects because it provides a great framework for extending the already-powerful Sass language. Compass includes some very helpful mixins (i.e. for vendor prefixes) and other things that make it a real luxury.

Codekit

Codekit is like steroids for developers. Really, it is. That’s even the developer’s tagline for it. It’s a paid application that’s worth every penny, especially for only $32. Some of its features include browser auto-refresh (this is freaking awesome!), Bower built-in (dependency management), and a compiler for all of your scripts and styles. While these features are available independently, and for free, Codekit provides them all in one nice interface. Personally, I try to sick with code over GUIs but Codekit is just phenomenal.

MAMP

MAMP (Mac Apache MySQL and PHP) is a desktop application that turns your computer into a local server, allowing you to develop on your local machine. This has a few advantage, such as your development not being accessible on the internet and increased speed. Your local server is much faster than a live server so you don’t have to wait nearly as long for page reloads.

There are other applications that do this same thing (Desktop Server is a popular one) but I like MAMP because it’s what I’m used and it works with Codekit’s live browser refresh.

Git and GitHub

Git is a system for version control, which lets you track and manage changes to your code base. It’s installed and used via your computer’s command line. There are GUI applications that you can use but I prefer and suggest learning how to use it with the command line because applications can be limiting and highly complex. To get started using git via the command line, you basically need to learn only a handful of command (i.e. config, status, clone, commit, push and maybe a few others).

GitHub is a website for managing your git projects. It also lets you collaborate with other developers and review open-source code. It’s become a standard for open-source version control and project collaboration.

Development Workflow

For client projects, I always set up a local installation of WordPress running on MAMP. Once I have a fresh copy of WordPress, I delete most of the junk it comes with (i.e. older themes, the Hello Dolly plugin, etc.). The only thing I do keep is the most current Twenty XX theme just in case something goes wrong with the primary theme and WordPress has to revert to a default.

Next, I add a few dummy posts and pages to work on. I don’t bother importing a ton of test content, such as the theme-unit-test-data.xml provided by WordPress for development. Instead, I created my own import file that I like to use. Ultimately, all the sample content needs to be deleted so I don’t add more than a few posts.

The real work starts when I add a fresh copy of Genesis. During my days of using Genesis, I’ve worked with many of the StudioPress child themes and I’ve developed child themes from scratch. Currently, I’m in the process of putting together a new version of my own starter theme but this one from Greg Rickaby is a nice starting point – it’s a Sass-ed version of the Sample child theme (mine will actually be based on that one).

A bulk of the work done during my theme development is done by Codekit. I edit the files and it refreshes the browser automatically and instantly. I write Sass and it compiles it into minified CSS. I create the JavaScript files and set Codekit to minify and concatenate them into a single JS file. By the time I finish the project, it loads a single, minified CSS file and a single, minified JS file. This optimizes load times because it decreases file sizes (minify) and HTTP requests (one file vs multiple files). In a future post, I’ll share my development process specifically for Genesis child themes.

After every few changes, I’ll push everything to the project’s GitHub repo(s). When I say “project”, this means single themes, plugins or a combination of them. For a client project, I’ll typical have one theme and one or more custom plugins; each get’s its own repository.

Syncing GitHub Repo with Live Installation

I recently started using WP Pusher, a plugin for syncing your own plugins and themes that are stored on GitHub (BitBucket and GitLab also supported) with a live website. This means that I can keep a live staging website for the client to view recent changes or, once the website has gone live, to update the code in the production environment without having to do anything other than push it to GitHub. I wrote a review of WP Pusher and why I think it’s great for a developer’s workflow.

Migrating from Local to Live

Once a client site is complete (or mostly complete), it has to be moved from my local, development site to a live server. I remember this being one of the biggest hassles early on but it’s actually quite simple; you just have to move the database and the files.

With the database, I export a copy, open it up in Sublime, do a find and replace of the links and save. This prevents links from pointing to “localhost:8888” or whatever your local URI is. Then, I create a new database on the live server and import the .sql file.

In this files, the first thing I edit is the wp-config.php file because it’s what’s going to establish the connection with the new database and take care of a few other important things. After I make any needed adjustments to plugin and theme files, I upload everything to the live server and being testing.

Finishing Up

There you have it: a sneak peak into how I develop my WordPress projects. I didn’t cover every last detail but this is a bulk of what I do to improve my efficiency as a developer. If you’re new to development, you’ll eventually stub out your own workflow but having some helpful steps to follow in the very beginning will make your early work much less of a headache.