Blog

Evolution of my WordPress theme development workflow

I’ve been using WordPress to create client websites for over five years now. In that time, everything has changed. Multiple times. Everything’s amazing, but web development has gotten more complex, not less. The depth of knowledge required to use the HTML/CSS/JavaScript stack is staggering, and the abundance of tools created to make it easier has just added another layer of “things you need to know”. And that’s completely ignoring which tooling you should choose in the first place.

Still, I’d take today’s development environment any day.

I did a little reminiscing and came up with a few major phases in my years creating WordPress themes for customers.

Thematic

In the beginning I remember using the Thematic theme framework as the visual foundation for a few projects. It was my introduction to parent/child themes, hooks, filters, and other key elements of WordPress themes.

My development environment was as primitive as you can possibly imagine. I worked live on the web server, either modifying the files right in vim, or by editing them in my FTP client’s text editor.

Looking back, I’m happy this phase of my development career is way behind me. Yikes.

Genesis

Later, I began using the Genesis framework for a number of sites. It had a lot of nice features built in that could be used right from the admin interface and required minimal PHP coding to make customizations.

But eventually, I started feeling like I was working around Genesis instead of being more productive with it. Saving customized HTML markup and CSS styles in the Genesis settings didn’t feel right to me, nor did entrusting a theme with many features that would arguably be better if broken out into separate plugins1.

During this phase, I switched to using Sublime Text and the Sublime FTP plugin to automatically send my changes up to the web server for previewing. This was definitely better than working right on the server, but made for a slow loop of modify → save → upload → refresh → view → repeat.

Foundation and Bootstrap

Next, I experimented with creating themes using the Bootstrap and Foundation front-end frameworks, which both offer many prepackaged CSS and HTML components. But, they both eventually began to feel too “heavy” for my projects, with lots of default CSS styles going unused and grid systems that get unwieldy.

I finally started using a local development server for these projects, going with a WAMP2variant that let me install and run WordPress on my Windows 8 laptop.

The biggest change from this period was the addition of Sass3 to my workflow. I’m now far more productive and organized in how I create CSS for my projects thanks to the features of this preprocessor.

Underscores + Bourbon/Bitters/Neat

Which brings me to my current setup for creating WordPress themes.

Sublime Text 3: I’ve been using beta versions of Sublime Text 3 for almost a year, and it has been super stable for me. I don’t know what I’d do without Sublime and its numerous keyboard shortcuts that are now burned into my muscle memory.

Underscores theme: A starter theme (not a theme framework) by some of the amazing folks at Automattic, underscores provides a theme structure that is up-to-date with WordPress features and standards. It provides almost no styles, but you can generate a version that comes with a bunch of empty Sass files for you to start editing.

Bourbon: Bourbon is a bunch of Sass tools (called “mixins”) that you can reuse to write less code.

Neat: Built on top of Bourbon, Neat lets you create simple CSS grids without all of the cruft you find in Bootstrap and Foundation. Once I got used to the different way it worked, this was a game changer for me.

Bitters: A basic set of project defaults for typography, lists, tables, form elements, and more.

Autoprefixer: Write CSS/SCSS without worrying about any vendor prefixes and Autoprefixer will automagically add (or remove) necessary ones based on current browser popularity and feature support.

Prepros: This app handles all of my CSS pre and post processing without me having to mess around with Grunt or Gulp.

Vagrant: Another tool that feels like magic sometimes, Vagrant lets me quickly create new virtual machines for projects on my laptop that come configured from a template with everything I need to get started. The project files in the Linux VM are accessible by all of my tools in Windows via a shared folder, so I can do all of my development there while running WordPress in an environment similar to its production setup.

The setup is more complex, yes, but I think the end product is better as a result. I can now easily design my themes mobile first, and they’re now faster and easier to understand as well.

I’m looking forward to seeing what changes the next five years bring!

As of the day this post was published, this blog is still running Prose, a Genesis child theme. ↩

You Might Also Like

This Post Has 3 Comments

RJohn

Nice! I followed a similar path getting into WordPress development and I’m using the same Underscores/Bourbon base for my projects. At this point I’m starting to feel like WordPress is getting in the way and I’m hoping a lighter, and more minimal CMS grows a community of contributing developers like WordPress has.

Samuel Rustan

I go back and forth. I do a lot of client work in WordPress, mostly because it’s the software non-technical software have heard of somewhere. There are a few interesting things going on with it, like the rest API, but other things have been getting my attention lately.

The Craft CMS uses PHP and MySQL like WordPress, but offers flexibility without the workarounds and kludges.

And I have to admit, I’ve been really interested in the latest versions of Microsoft’s web stack. C# + ASP.NET 5 + MVC 6 looks like a really good combination, especially now that they’re open sourcing things and allowing them to run on OS X and Linux in addition to Windows.

I haven’t looked at Flask for quite awhile, but it looks nice. Python is the bomb.