Approaches To WordPress Theme Development

Articles

What makes a WordPress theme? The simplest answer is PHP, HTML, CSS, JavaScript, and assets like images and other embedded media. But before these elements are forged into something beautiful you must decide on how your theme will be built and its intended use. Philip Arthur Moore expands on a recent WordCamp talk about four different approaches to theming and offers the benefit of his experience to help you decide on a route that’s right for you and your projects.

Parent And Child Themes Bundle Up

The Twenty Somethings — Twenty Ten, Twenty Eleven, and Twenty Twelve — are all perfect examples of themes created to function as standalone default WordPress themes and provide graceful support for child theming.

Out of its box, Twenty Twelve delivers a mobile-first design that accommodates clean typography, styling for multiple post formats, and CMS-ready page templates. At the same time, it’s completely customizable by way of child theming, or theme inheritance.

Parent themes pass on all their traits to their children, and when coded intelligently they allow their children to modify, add, or remove parent functionality entirely. This means taking advantage of core WordPress action and filter hooks to set theme defaults, appropriately outputting scripts and styles to page headers, and softly modifying fallback arguments for template tags.

When custom, non-hooked functions are used in good parent themes they are made pluggable; and, in general, parent theme stylesheets do not aggressively rely on ID selectors. In short, ideal parent themes are by themselves just right on the front-end and fully moddable on the back-end.

The maximum benefit of the parent-child approach is that child themes are relatively simple to create: a style.css file housed in its own folder is all that’s required. This means that WordPress developers who actively offer theme support are able to provide straightforward customization guidance to DIY users. The learning curve for rapidly creating child themes is gentle.

One downside of relying on the parent-child theme model is that any post-launch changes made to a parent will directly affect a child theme — sometimes with negative results. Because child themes take on all the code of their parents unless specific overrides are in place, even the most seemingly innocuous improvements to a parent theme can have far-reaching effects to its child themes.

If, for example, a parent theme author decides to modify internationalized strings, change from an ID-based styling system to a class-based styling system, or change a hook on which a custom function fires, she should carefully consider the fact that child themers may need to update their translations, rewrite their child stylesheets, and update their custom, hooked functions.

Theme Frameworks By Developers, For Developers

In a previous life I developed commercial WordPress themes for an outfit named Graph Paper Press. Its mission was — and still remains — to create sleek, minimalist themes for photographers and other creative people.

With every new theme we developed, we kept running into the same questions: How do we speed up development time and cut down on code repetition? How do we ensure maximum control when it comes to customizing an out-of-the-box theme without breaking future upgrades? And how do we manage all of the custom functions that we’re developing and use in every new theme that we ship out? For a time, a theme framework was the answer we came up with.

At their most complex, theme frameworks act as code libraries that aid in developing highly functional child themes. Theme frameworks are advanced incarnations of the parent-child theme approach and, when acting alone as parent themes, look like slightly baren fields waiting to for us to sow the seeds of our next best theme. Frameworks and their children feel codependent.

The reason theme frameworks are so fantastic for developers is that they allow an unparalleled level of fine-grained control over all aspects of a theme’s functionality and design. Frameworks offer custom actions and filters, custom callbacks for core-supported hooks, and blurred lines between plugin and theme territory. “I can make this theme do anything,” is what developers who make frameworks say.

In the WordPress.org self-hosted side of the theme landscape, theme frameworks are a viable approach for commercial theme developers who have little-to-no control over a customer’s hosting environment.

Where theme frameworks sometimes fail is that they are — for the average WordPress user — impossible to either understand or easily modify. Whereas with a bundled theme such as Twenty Twelve the process of overriding a template file or function is fairly straightforward, doing the same with a theme framework can be anything but.

The theme framework learning curve is steep, so much so that the most popular theme frameworks in the commercial market today have customization economies created around them for user support. Understandably, users who are forced to not only purchase a theme but also simple customization services often share their frustration with this development approach.

One more point to consider when developing with theme frameworks is the possibility of code bloat. Because they act as libraries, theme frameworks must include every function that will ever be called in a child theme. Maintenance and upkeep aside, keeping track of all the custom functions and custom hooks created by a theme framework is important. So too is good code organization in a framework. You may decide that this is too much overhead for a small project.

Theme frameworks absolutely have their rightful place in the WordPress ecosystem — they make life easier for developers but can create problems for the DIY user. Well-supported theme frameworks feel these effects much less than those that are left to rot on the vine.

Starter Themes A Wrangler’s Playground

At Automattic we — the WordPress.com Theme Team — face the challenge of finding, developing, and launching high-quality WordPress themes for millions of users.

We tackle this primarily by three methods: exploring WordPress.org Extend for stunning, fully GPL-compatible themes; partnering with premium WordPress theme shops who code well and provide superior support; and by crafting our own in-house themes.

For Automattic-developed themes we rely on the starter theme _s, also known as Underscores. A starter theme is, as indicated by its nomenclature, used as a project head start.

At its essence Underscores is a toolbox — in fact one of its predecessors is named Toolbox — that contains just enough PHP, HTML, and JavaScript to rapidly get a new theme off of the ground. It’s the 80% of a theme that results from 20% of up-front effort.

A close inspection of Underscores‘ stylesheet reveals resets and sensible typography, asset alignment rules for WordPress-uploaded media, and proper multi-level primary navigation styling. In addition, rules for screen reader text, post navigation links, and multi-author blogs are also present. “Just enough but not too much,” is the mantra of a starter theme’s stylesheet, where the primary goal of any code added is to avoid repetitive future work.

Lean, well-commented, modern template files are a hallmark of Underscores, as well as example code for oft-used theme features such as custom headers and theme customizer integration. And because the code that’s used is always the starting point of every new theme on WordPress.com, it’s well-vetted for security and WordPress best practices.

An important distinction between parent themes and starter themes is in how they are developed. Whereas every change to a parent theme brings with it the potential of adversely affecting all child themes that rely on it, with starter themes there is no concern.

Starter themes are not parent themes, and should never be used as such. They are meant to be constantly iterated upon and in flux. They exist to make launches happen faster and make code quality better with each new theme launch. The Underscores of today is markedly different than the initial version that launched, which means that the practice of always making it better is succeeding.

Without a doubt the largest speed bump to using starter themes is that in this development model there is no bug fix and enhancement inheritance that’s enjoyed by the parent-child theme workflow. If a critical bug fix occurs on the canonical version of _s, then manual updates to every theme spun off of all prior versions must take place.

With time, however, this negative aspect of starter themes is greatly diminished. Every time Underscores is used to begin a new project, a fresh set of eyes audits its code pre-launch, meaning that gradually the process of large-scale manual bug fixes to old starter theme code fades away.

Building From Scratch Freelancers And Agencies Unite

The major assumption I’ve made up until this point is that you’re developing a WordPress theme to release it publicly. When we drop these approaches in favor of one more tailored for client work, starting from scratch emerges as another clear option.

When I write “starting from scratch,” what I really mean is ignoring, for the most part, commonly held WordPress theme guidelines and doing only what is absolutely needed for integrating WordPress into a project.

A theme that contains only a single stylesheet and a few template files would not be accepted on WordPress.org or WordPress.com, but that doesn’t mean it wouldn’t be completely appropriate for a one-off gig or WordPress-powered microsite. After all, all that’s needed for a theme to properly operate is a stylesheet and an index file.

Similarly, large-scale projects that are a mashup of theme, plugin, and web application are not well-accounted for by the approaches I’ve covered above. For these projects the best way forward will likely be dictated by budget, time, and administrative constraints. For all three limits, using a starter theme will at the very least act as a sanity buffer.

Go Forth And Theme

So: parent-child themes, theme frameworks, starter themes, or building your theme from scratch? Now that you know a little bit more about the pros and cons of each, you’ll be able to make better decisions on personal and client projects alike.

Each approach exists as a scenario-specific response, and I’m confident that in the future more interesting problems and solutions will emerge as WordPress themes evolve. Good luck with whichever approach you choose, and may your adventures in wrangling always be fantastic.

Based on “IMG_0270.jpg” by Hello Turkey Toe, CC-BY-2.0.