…and you plan to submit your theme to the WordPress Theme Repository.
Let me point out some issues, that Themes, which derive from Starter Themes, frequently get flagged for by Reviewers:
1. Theme slug inconsistency
This is probably the most common issue with derivatives of Starter Themes. The Theme Review Guidelines explicitly state:
Themes are required to use a unique slug as a prefix for all custom function names, classes, public/global variables, database entries (Theme options, post custom metadata, etc.). Themes are recommended to use
theme-slugas this unique slug. […]
Themes are required to prefix all options, custom functions, custom variables, and custom constants with theme-slug (or appropriate variant).
Codex: Theme Review
Every Theme is required to use its own namespace, regardless where a function or variable originally comes from (the only exception to this rule seems to be framework functions, that are maintained separately from the Theme). So it’s not good enough to just take the code as is and build on that – Theme authors must rename all instances of the old slug.
Pro-Tip: Build your search-replace query wisely, otherwise you may endup with weird constant names etc. A great instruction for its purposes provides Automattic’s _s Theme in its readme.txt file under “Getting Started”!
2. Licensing
Sometimes Starter Themes come bundled with some awesome JavaScript functionality or a slick icon set for you to use. You made sure they’re GPL compatible, submit you Theme – but it gets rejected. What happened?
They probably were not declared explicitly:
Themes are required to state the copyright and license information for any bundled resources not covered by the Theme’s license statement. Themes are recommended to state this information in the Theme’s [
readme.txt] documentation.
Codex: Theme Review
And since this is a major issue, Themes will not even be further reviewed. So make sure to not only double-check if these resources are allowed to be used in the first place, but also to explicitly declare any bundles resource’s license in the Theme’s documentation.
[UPDATE]: After Chip Bennett was so kind to fact-check this post on my inquiry, the following part is deprecated 🙂 It seems like placing the call in header.php is formally still allowed. But bad practice nonetheless!
3. Enqueueing the Comment-Reply Script in header.php
There’s a new requirement in town, and most (if not all) Starter Themes have not been updated yet, to accomodate for it:
Themes are REQUIRED to enqueue comment-reply script via callback, rather than hard-code the enqueue in the HTML document head
WordPress 3.3 Proposed Guidelines Revisions
This is a requirement, that I – in my short time as a reviewer – just saw fulfilled once. And amazingly enough, by a Theme that was already approved into the repository!
Personally I like clean headers. Themes and Plugins have wp_head() to work with. So just take your scripts and styles, enqueue them in functions.php and hook them to wp_enqueue_script (yes, styles, too 😉 ). You’ll have all your scripts in one place and the document head remains clutter-free.
Really useful article, it’s easy to forget these points at times when developing themes.
The link to Automattic’s _s Theme goes straight into my bookmarks.
Some great nuggets to take away from this. Thank you! I really like the theme-slug section which I knew about / but now I understand. Groovy stuff.
Keep up the good work!