Underscores Gets Automated Testing

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.

Subtitles v1.0.7: Jetpack Support & Better Editing

Subtitles v1.0.7 has just been released on WordPress.org. The two major changes in this release are default support for the Jetpack Portfolio custom post type and a better out-of-the-box editing experience on Add New Post screens (see issue).

Download your copy of Subtitles today, read over the documentation GitHub if you have any questions, and feel free to get in touch with me if you notice anything buggy about the plugin.

I was wrong about custom post type standardization.

I spent so much time thinking that implementation and the Customizer mattered in the discussion of custom post type standardization that I didn’t realize how easy this entire effort would be once the issue of meta keys was figured out. Here’s how the Testimonials standardization happened, and here’s how easy it will be to handle other post types moving forward:

  1. Someone kicks off a discussion about a custom post type that they care about.
  2. Other people weigh in and data standardization is discussed.
  3. I’ve found that providing visual mockups of data structures in discussions about data always helps the discussion.
  4. People agree on stuff, and a standard is created.

7 days. That’s how long it took for us to standardize Testimonials for all WordPress users. I don’t think it will be this easy for all custom post types but it can be if people care about it and give guidance to each other. Now it’s up to WordPress.com and WooThemes to adopt the standards that we’ve put forth for Testimonials. WordPress.com and Jetpack are on board; it’d be awesome if WooThemes also got on board.

Michael Cain at WordPress.com is a smart man. He helped me with thinking through CPT things during the last few days and I can’t thank him enough for his time and input.

Custom Post Types, Jetpack, Standardization, and Testimonials

Update: I was wrong about a lot of this. What follows deals more with implementation, not standardization. The standardization was much easier than I thought it’d be.

Both Brian and Justin recently wrote compelling posts about custom post type standardization in WordPress, which will become more important as the platform moves further in the direction of becoming less bloggy and more websitey.

I agree with Justin that creating standardized custom post type names is easy. He’s taken the lead on an “open set of standards for the WordPress developer community on how to name custom post types as well as related taxonomies and metadata”, which I fully endorse and encourage plugin developers and theme developers alike to look over. Naming here is not difficult, and the initial CPT list-Testimonials, Portfolios, Recipes, FAQs, and Events-is something that Jetpack and others have already started tackling.

My concern lies mostly with how users will interact with these custom post types and if they serve real needs. I’d prefer to spend less time on the ones that don’t matter right now (FAQs) and more time on the ones that do (Events). Which custom post types are most important is a matter of choice, to be sure, but if we’re able to identify one easy custom post type, standardize it, and then use that process as a precedent on which to standardize all other custom post types, I think we’ll be in a good place. The alternative is to spread our attention too thin and end up in a situation where two years down the road we’re still without some really useful tools as both themers and plugin developers.

Testimonials are the easiest to address immediately, not only because their usage is hard to misinterpret but also because they already exist on WordPress.com and need improvement. I do not know that Automattic has either the manpower or the want to lead the way on every custom post type, and the ones that are in Jetpack were born out of necessity in the moment. All of them are stuck on V1 because they’re hasn’t appeared to be a great need to V2 them.

We can have a very quick win with Testimonials. This is what would need to happen:

  1. Install Jetpack
  2. Install and activate the Motif theme.
  3. Go to the Customizer and stare at Testimonials in confusion.

I kid with point 3, but it does underscore my belief that we should start thinking about standardization from either within the Customizer itself first or the post and page edit screen first. The moment we bog ourselves down in the data we lose focus of how we want users actually interacting with these custom post types. I think that with Testimonials we can hammer away on the version that Automattic has built, make it better, standardize everything about it (including the experience around it), and then yell from the rooftops at Automattic to either incorporate these standards via pull requests or push back with their own ideas.

Data and naming standardization will be easy here; the experience side of this will likely require discussion.

  1. What should be included in a Testimonial? Customer Name? Customer Website? Company Name? The actual Testimonial? You get the idea.
  2. What default descriptions should we give to the Customizer controls for Testimonials? Having nothing on a Customizer screen but a section titled “Testimonials” with blank boxes is scary and confusing.
  3. Should customers be customers or clients? Or visitors? Or supporters? You get the idea.
  4. What should adding a Testimonial on a post edit screen look like?

These are the types of questions I’d like to focus on when talking about standardization. The data part will be easy if we can nail down the “How will users actually use these?” part. We can start with something already done and V2 the heck out of it to make Testimonials better for all of WordPress.com users and also set a precedent for how the .org world should go about implementing its custom post types.

I don’t care as much about “theme territory” and “plugin territory” discussion as others; I think the lines will always be blurred and that’s okay. But I can’t wait to see a CPT-supporting default theme in WordPress, which I briefly mentioned several weeks ago on an Apply Filters podcast. The sooner we can hop on standardizing just one custom post type, the sooner we may see that happen.

Discuss Testimonials on GitHub.