Last October, I spent two days at #fowa in London. One of the most common themes that came out of it was how far automation tools have come in the last few years.
Where I work at Storm, we have two groups of devs, I’m lucky enough to lead the WordPress and PHP team while upstairs sit the ruby guys. They’ve spent the last few years writing with modern cool stuff like CoffeeScript and Sass/Less and deployment things like capistrano. They also like to write tests, which as a long term PHP guy, I’ve really never understood, and hey – I’m a WordPress developer, so I have to write everything the way WordPress lets me, and that means using this cool new complicated stuff is even more complicated.
Since last October, i’ve been slowly working to move our WordPress development to a modern workflow of grunt and Sass. I decided to use my website redesign as a way to expand what I had already done at Storm to include CoffeeScript, bower, compass, and composer.
Grunt is a task automation tool, and already it’s started to fall out of favour with the web geeks (with people moving towards gulp), but seeing as Zurb Foundation uses it as their SASS compilation automation tool, and the vast majority of the code I write sits on Zurb’s grid, it made sense for me to use it.
Bower is a “package manager for the web” – it lets me specify a list of “things” I want to use in the project (or, in this case, the WordPress theme) and handles downloading and updates to them. For example, for this theme, it is handling Zurb foundation, the Compass core Sass library, jQuery smooth-scroll, animate.css and jack-in-the-box. It also handles dependancies, so by including Zurb, i’m automatically given jQuery and Modernizr too.
Compass is actually a ruby tool to handle Sass compilation which would replicate part of grunt’s functionality, but it has a nice open source library called Compass Core which provide mixins that come in handy when writing Sass. I use it to give me browser prefixes and older browser support for modern CSS3 features.
Composer is a PHP package manager. In recent times, the majority of common SDKs have added composer support, meaning just like bower, it’s possible to just “require” Facebook, or PayPal, or any other supported library, and have it available inside your project.
Sidenote: Notice how the PHP tool has the ugliest website out of all of them?
Adapting a WordPress theme to use these tools is a surprisingly complicated task, at least it was for me after many years of working in the traditional development way. While WordPress is moving towards these kinds of technologies (3.8 includes Sass compiled admin colour schemes, and there is discussion of moving over to include much more Sass and a compiler in a future release) it’s still a very manual process of enqueuing every script and stylesheet you want to use in your functions file, and writing simple css. There are then after deployment plugins that will handle minification and concatenation of your scripts and styles.
I replaced that with a local system of compilation and minification; that way you can easily detect errors before you go live, and you only need to enqueue one style, and one script – minified app.min.css and app.min.js for production, and expanded but concatenated app.css and app.js for development. I also remove the default version of jQuery from WordPress, leaving Zurb’s default (current) one to take over. This has some potential for problems, but I’ve not noticed anything yet. WordPress are pretty good at keeping their third party libraries up to date, or at least compatible with the latest versions.
Grunt watches for anytime I modify any of the files in the theme and rebuilds everything it needs to, reloading my browser in the process to save me needing to leave my IDE to see the changes to the code I just wrote. If anything goes wrong, I get a growl notification giving me details of where my syntax errors are, before I even reload the page. This has already saved me so much time and made my workflow significantly faster, and that’s good for everyone.
Grunt also handles making sure every image I use on the site is compressed as best as it can be – stripping any meaningless data, essentially doing a “save for web” in photoshop (but actually getting about ~6% smaller filesizes than that).
Anytime any library I use is updated, a simple “bower update” takes care of dropping the right files in the right place without any interaction from me, while the semantic version numbering means it won’t ever update to anything likely to break anything in the theme (too badly, at least).
I hope to release the base theme we use at Storm open source later this week – that’ll give you everything you need to get going in this exciting world of modern web development.