Review is a key part of Theme Wrangling, so we spend a lot of time looking “under the hood” at themes. Here are some of most common theme development errors that come up in the review process, and some tips on how to avoid them.
1. GPL-incompatible Licensing
Just because it’s “free” doesn’t mean it’s open source. If you’re building your theme on a framework or starter theme, or if you’re building a child theme, the foundation/parent theme must be GPL or GPL compatible.
In addition to the theme’s license, always check the licenses for bundled resources – images, scripts, fonts, or icons sets – to ensure they’re GPL compatible, and state their respective licenses in the theme’s README. When in doubt, contact the original author to inquire about the license (and perhaps encourage them to switch to a GPL-compatible one if they haven’t already).
The WordPress Codex has helpful information regarding GPL and theming:
2. Poor Code Quality
3. Fails the Theme Unit Test
The Theme Unit Test is a set of data used to test for visual bugs and inconsistencies. We know you’re excited to share your theme with the world, but before you do, test it thoroughly with the dummy content provided. You’ll catch a lot of the common issues that come up in theme review, which in turn speeds up the review process.
4. Copy Pasta Code
Well, maybe, or maybe not. It’s important for you to understand the code that goes into your theme for a number of reasons – security, usability, compatibility, and licensing concerns among them. In short, if you didn’t write the code, you should still familiarize yourself with its source and license, and have an understanding of what the code is doing and how it works.
Don’t get me wrong – sharing and working with open source code is encouraged! It’s a great way to learn. But simply finding a script and copying it into your theme does not help you grow as a developer, and there is a good chance it won’t help your theme in the long run, either.
5. Improper Data Validation/Sanitation
Last but definitely not least, it’s important to make your theme as secure as possible. If you allow users to change settings, there are that many more entry points for harmful data. A common misstep in theme development includes failing to validate data going to the database and sanitize data coming from the database, leaving your theme (and your users) open to malicious code. There are a number of ways to prevent this, and you can read about them in the Codex:
It is also recommended that themes use the Settings API to include theme options, but I prefer to use the Customizer, and keep theme options to a minimum. Either method is valid as long as you follow appropriate validation/sanitation procedure. Read more about the Settings or Customization APIs:
- Settings API
- Theme Customization API
- How to leverage the Customizer in your own themes – a helpful tutorial from Otto
As always, if you’re looking for a secure, stable, properly coded, and GPL-compatible base theme, you can’t go wrong with our very own _s starter theme. _s addresses several of the above concerns out-of-the-box, which speeds the development process and decreases your chances of making one of the above mistakes.
I hope this guide will help make your future themes that much more awesome!