Just over a year ago Koop wrote about a new frontier for WordPress Core development. Since then I’ve been paying much more attention to the tools that both plugin developers and Core developers use to make sure that the code they’re writing isn’t breaking WordPress.
I began my WordPress career making themes and will always consider myself a theme developer first. Themes aren’t just about wrangling stylesheets; they are about coming up with amazing and beautiful solutions for website makers and web publishers that involve primarily PHP, JavaScript, HTML, and CSS. Themers are both designers and developers. We make good looking web templates but we’re also tasked with coming up with “plugin territory” functionality when Core lacks what we need or a plugin doesn’t exist for what we’re after.
In creating Subtitles I wanted to make sure that every single commit I made to the codebase before and after release didn’t break anything. Travis CI is a beautiful tool for doing just that, but my hunch is that among theme developers it’s mostly associated with plugin unit testing and deep Core development. Themes also need automated testing, especially those that are subject to public contributions like Underscores, and now it has it.
The V1 of automated testing for Underscores only checks for two things, PHP syntax errors and checks against WordPress Coding Standards. Even with that we needed to add in a few exclusions because the coding standards were returning poor XSS-related results. Still, having basic checks in place now ensures that all commits made to _s by its lead contributors will be tested for code regressions and all pull requests from outside contributors will be tested for errors.
Moving forward the goal is that enough automated checks will be put in place that any themer in the world will be able to build a theme using _s as a starting point and be sure that it’s been rigorously tested and will be ready for the likes of any marketplace and customer base.
Ideally, the teams from WordPress.com, Creative Market, WordPress.org, and ThemeForest could have a pow wow and talk about the errors that plague their themes most. Then we could all come up with some sensible automated rules for theme checking, add those into a scan set, and use them for our public GitHub repos and other publicly distributed themes. Buggy code isn’t unique to any one community of developers so the more we can do to help each other, the better.
If you have ideas about which kinds of automated code-level scans we should be checking for in Underscores and themes in general, add your input into the discussion. One-liner stuff like PHP syntax errors is great. So, too, are things like running the theme through VIP checks with every commit, which will come sooner than later.
Any check is a good check. Now that Underscores has basic build testing in place, look out for many more of them to be put in place in the coming months. This is exciting.
