Coding up Themes
I wrote a whole article on how to approach coding themes as a front-end developer, so I won’t go into too much detail here. The only thing I’ll say is that it is important to start theme development in pure front-end code, an HTML prototype that is fully built out, before moving to integration with the WordPress API.
Why? It allows you to work out exactly how your site’s front-end is going to work. Without having to worry about PHP, you can integrate your own build process, determine your performance budget, and test out interactions and design. It also prevents you from avoiding ideas that you think WordPress can’t handle. In the end, you can use WordPress to do just about anything, and you shouldn’t let the platform limit your design.
Adding a Front-End Build Process
In order to manage all of these dependencies, I use a couple of tools. I start with Codekit, a GUI for creating a front-end build process, but I’ve also used Grunt, a command line task runner. These compile my SASS, check my scripts, compress everything together, and do a whole lot more. If you’re an experienced front-end developer, chances are you are using one or several of these tools. Often, I begin with a tool like Codekit (or Prepros). However, as soon as I need to do something Codekit can’t do, I’ll turn to a command line tool like Grunt or Gulp.
Since you’ll be starting with just the site’s front-end, make sure that your build tool is “watching” your theme folder. When you move it to a WordPress theme, keep it watching just that folder. Having your build tool keeping an eye on your entire WordPress install can cause a real headache down the line.
Combining Assets Into One Request
UPDATE: A previous version of this post suggested dequeing individual files. I have updated this to reflect more sustainable best practices.
When you start adding plugins to your WordPress theme, some of them will come bundled with JS and CSS files, each loaded as a separate request into your theme. But chances are, you’d rather combine all of your JS and CSS into one file, because it’s better for performance. Chris Coyer started an interesting thread about creating a plugin that can help with this process, but for now, you’ll have to manage these assets yourself.
The first thing you need to do is get a list of the external scripts and styles that are being loaded in by plugins. I use Helpful Information or Debug Bar to make this a bit easier. These plugins can get you a list of handles for all external CSS and JS files. That will give you a handle on what exactly is being loaded in, page by page.
From there, the best way to combine all of these assets is to turn to a plugin which can do this for you. There are really two that come to mind. The first is W3 Total Cache, which is actually a full caching plugin that can do a lot more then just combine scripts and styles in terms of your sites performance. If you already using this plugin, it’s a fairly simple affair to switch on a feature to concatenate and minify stylesheets and scripts across different plugins. The other is Autoptimize, which is solely devoted to compressing and combining assets, but has quite a few features for developers that want to real extend functionality. It even has the ability to inline critical components of your CSS to avoid the “render-blocking” problem.
My goal is to have my theme output only a single JS file and CSS file. Then, you can enqueue this in WordPress like you would any other. There are other ways to approach this, but the most reliable is to depend on a server side plugin to do the bulk of the work for you.
Now it’s time to move to the topic of version control. WordPress uses SVN, but I find that a lot of front-end developers use Git. And it’s always the same question. How much should I include in my version control, and what files should I ignore?
I wish there was one right answer, but there’s not. I’ve seen people store their entire WordPress install, just the wp-contents folder, or just the theme folder. I really don’t find the first option to be viable. Keeping your whole WordPress install in sync seems needless, and can add some unnecessary weight. The question is really whether or not you want to include plugins in your Git repo. I tend to avoid this, and rely on another method to keep this all in sync. So really, all I store in Git is my theme folder.
In any case, there are certain files that you will definitely want to ignore. The biggest is the uploads folder. This is going to be far too big to move from machine to machine. If you’re using a preprocessor, you want to ignore cache directories. You might also hear that you don’t need to add your compiled stylesheet and script file, since they are part of your build. But I find, when working with WordPress, it’s easier to leave these files in, as there is no easy way to compile them on the back-end. It’s going to result in some messy diff’s from time to time, but it makes things a bit easier.
Keeping Everything in Sync
Once you have your build process set up, you have to be able to sync up your local (or multiple local) and production environments. If you’re able, I’d also add a staging server to that list, so you can test things in the wild. Syncing really breaks down into four categories: the database, uploads, plugins, and your theme.
To keep your database in sync, I really can’t recommend WP Migrate DB Pro enough. It makes syncing databases between any number of servers really easy. And the plugin has a media uploads add-on, which allows you to sync up images, video, and audio all in the same place. If you’re using Git, you can also try Revsir, a plugin that keeps the WordPress directory and database in sync with built-in backups. The point is, you want to find a tool that does the work for you. Performing routine database dumps with search and replaces can get cumbersome quick.
For keeping plugins in sync between different WordPress installs, there are a couple of options. The first is to include your plugins folder in your version control repository, and use that to deploy to your production site (more on that in a moment). But I think this is a bit unnecessary. If you’re looking for an alternative, you can try a mix of WP-CLI and Dictator. The latter saves the “state” of your WordPress install, including a list of plugins that are installed and activated. You simply need to include a flat YAML file in your repo, and plugins will stay in sync from site to site.
As for your theme, this is where having a Git repo really comes in handy. It will allow you to set up a deployment process so you can push changes from your local environment to your staging or production server. If you have a lot of command line experience under your belt, you can try Capistrano and WP-Deploy. There are other deployment scripts out there, but they can be a bit complicated. If that seems a bit over your head, there are a number of automated systems available, notably DeployHQ and Dploy. Both of these can push and pull changes from GitHub or Bitbucket automatically when changes are made, and are fairly easy to set up. When you do choose to deploy, it’s best to focus on just deploying your theme files. Anything more than that, and you risk unusual conflicts.
Obviously, this is quite a bit of information, but it’s hopefully a good roadmap for you. If you are a front-end developer, it’s easy to start integrating your workflow into WordPress. You just have to decouple your back-end from your front-end, and let your own process dominate the latter.
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.
Join the conversation