Make theme standards your New Year’s Resolution


Most theme authors have their own habits. Most habits will have a positive effect on themes, or least on the time it takes to develop themes. Developers sometimes forget, though, that there are Theme Development Standards everyone should use while coding themes. Some are more obvious than others, but none of them are that hard to stick to.

In the last few months I’ve heard of theme developers making silly mistakes. To name a few:

  • adding stylesheets and Javascript files via header.php instead of using proper functions,
  • including a sidebar directly into header.php instead of using sidebar.php (via Ryan Duff),
  • and hard coding menus in header.php instead of using WordPress menus.

For these mistakes and others popping up, consider this a reminder: there is a Theme Testing Process you can use to test your theme. Yet many themes out there aren’t even close to checking all the boxes on that list. Even on massively popular marketplaces like ThemeForest, there are themes that fail in the first few steps.

The and ThemeForest theme review team are already using the Unit Test to limit the number of poor quality themes out there. The next step is for theme developers follow these coding standards by default. With WordPress improving every single day, it’s time to improve the quality of all the great looking (but poorly coded) themes out there.

So with the new year closing in pretty quick, what are other New Year’s resolutions for theme developers? Just how high are we going to set the bar for WordPress themes in 2012?

25 thoughts on “Make theme standards your New Year’s Resolution

  1. We desperately need a standardized theme framework for both the code and the theme options. I can’t understand why every theme needs it’s own way of solving the exact same problem. Imagine if every developer needed to build the WordPress backend from scratch. What would be the advantage?

    • There are indeed a number of libraries and frameworks for handling things like options. Heck, we wrote our own because we weren’t satisfied with the alternatives.

      I respectfully disagree that we need some sort of centralized framework for these things. Let everyone work out the problems as they see fit, and the winners will float to the top. Once you declare “this is how themes are coded, period” you stifle innovation. Libraries and shared code are wonderful, but I’m not sold on standardizing theme frameworks or even options.

    • I don’t see the need for one standardized theme framework. Then again, I’m one of those developers who builds themes without a framework. I think that Coen tried to emphasize the need for developers to stick to best practices, and in this case more specifically WP’s best coding practices.

      I think it’s out ‘duty’ to educate the developers that deviate from these best practices by submitting patches for their themes, just as we do for plugins developers. This way we help out the many users who have ever installed a less-than-par theme and the developer in question.

      • Wanted to chip in on Coen’s first article here, but Luc said it best. No need for “one” theme or framework (you already have twentyten/eleven if you want), but it is not the solution “for everything”. Best practices in html/php/css are a better path to follow. Let frontenders be creative.

    • Standardized theme / option framework ?

      Yes, please.

      We need the standards not to confine or impose onto ourselves, but we need it so that we could all be on the same common ground – or at least something to fallback to.

      Having the standards doesn’t mean getting rid of the freedom of making it differently, folks who come up with something better can always contribute and make changes or even with a complete different method altogether.

      The choice is still there, with or without the standard.

      So let’s please have it.

  2. As a theme developer, trust me, we don’t want to reinvent the wheel. The problem is when it comes to theme options and WP-Admin UI there is no wheel.

    While 3.3 is an improvement, there are still fundamental and philosophical issues at play that haven’t been addressed, and that may never be addressed until Automattic draws a line in the sand and provides strict logical UI standards.

    A perfect example of this is a check box.

    A check box can be used to both enable or disable something. It is an entirely useless inconsistent UI element that is commonly accepted and used all over WP-Admin. Go through WP-Admin and there’s check boxes to enable something, and then below it a check box to disable something else. Both boxes are checked yet one disables, and the other enables. It makes no sense.

    In my latest theme iFeature Pro 3 we completely redesign our theme options and opted for on and off toggle switches like Apple uses in iOS. This way you know if something is either enabled or disabled. Until an on / off toggle switch is implemented in WP-Admin, the UI will suffer over something as simple as a check box. Why should I use a check box because it is “standard” when it is confusing?

    Our old theme options had WordPress like tabs, and check boxes galore. We then opted for making our theme options intuitive, and pretty. They look more like an iOS device then they do WordPress, and guess what? Our support requests dropped significantly, and we never have to link users to our documentation anymore.

    We also designed our theme options so that if something is disabled you don’t see more options pertaining to it. Only once an option is enabled do you see other options that relate to it. This way we’re not overwhelming users with options they aren’t even using.

    Arguably our theme options are inconsistent with WordPress’s UI, which is supposedly bad, yet the reality is they are more intuitive and easier to use than WordPress’s UI.

    Until WordPress and WP-Admin actually provide logical UI standards that actually make using WordPress easier then people are just going to keep trying to make their own options. Some of them will make sense, and others won’t. The ones that do will sell more and be used more and then eventually become the new standards, until then it is the wild west.

    • I don’t really see how an on/off toggle is any different than a check box to a user.

      A check box that is checked means yes/on and one that isn’t checked means no/off.

      If you have an option like “Allow search engines to index this site” and the box is checked it is pretty obvious that with a check mark in the box means yes allow the site to be indexed.

      If there was no check mark I don’t see why anybody would assume that an option like this would mean that search engines are allowed to index the site.

      It doesn’t really have anything to do with the check box itself and more just how things are worded.

  3. 80% of the existing issues can be solved by using the Theme Check Plugin and really paying attention to the results.

    The other 20% can be solved by pitching into the Theme Reviewers mailing list and joining the discussions about the right way to do things, so that we can have the proper input, viewpoints, and talky-talk about how to improve things all around for everybody.

    We’re ready and willing to code to fit the needs of the many. Opinions and viewpoints are always welcome.

    • Indeed, there are lots of great discussions going on in the mailing list, but I really don’t like the format.
      It would be nice to use forums instead. It would make it easier to follow discussions.
      Or is there another way to read the mailing list other than in an email client?

      • I use GMail. It makes mailing lists nice and easy. Just filter all of a given list into a label, then you can browse that label at will and all the replies are threaded.

    • IMHO Theme Check should be performed by a developer before releasing a product to the wild. Theme Check has become my main tool when working on Themes developed by others (non-standard that is) as well as any older Themes for clients. It’s always up-to-date with current guidelines and definite time-saver.

      Theme Check is also used by many of us here.

      Good post Coen, this should be way to go for sure!


  4. Pingback: Interview with Kevin Muldoon from WordPress Mods Blog | WP Kube

  5. This is absolutely something we need to get onto. I wrote an article about this exact topic over on Wptuts+ back in September, trying to encourage the use of the Theme Review Team’s process for all premium theme developers.

    Also, it’s important to mention that for marketplaces such as ThemeForest with so many themes submitted over such a long period, review standards evolve. The stricter standards currently enforced may never have been applied to themes that haven’t been updated in a while. This is a process that’s been discussed, but it’s a large job and something that can’t happen without planning.

    So, let’s hope 2012 is the year for all of us to get our ducks in a row!

  6. Adding stylesheets via header.php is wrong? Both twentyten and twentyeleven do it that way. Perhaps you mean something that I am missing…?

    • correct, only the main stylesheet should be hardcoded into the header.php template. Others should be enqueued with the wp_enqueue_scripts hook for the front end.

  7. We’re currently working on rebuilding our theme options framework from the ground up using the standard WordPress UI and making use of the new HTML5 image uploader rather than a custom image uploader. That was one of the main issues keeping us from switching to the standard WP uploader for images within our framework.

  8. Silly question I guess, but talking about “not using the WP menus” … I have a minor experience with them, but I see that they do not handle sub-categories, am I right ?
    That is you want to create a entry in your menu with a category and drop-down the sub-cats … I did not see how that might be done with WP menus … That’s why I choose to hard code … maybe there is a better solution ?
    Thanks anyway for the ideas !

  9. I see that they do not handle sub-categories, am I right ?

    That is not the case. You can drag menu items (sub categories also) as you like under Appearance >> Menus. It’s just depends on your theme does it support drop-down menus in front end.

    • well, you can drag a category, and then its sub-cats, but what’s the point if you make sub categories, if you need to drag them by hand, the menu should read them automatically, see my point ?

      • Yes I see your point. And if you are making theme just for yourself, it’s totally fine hard code menus as you like.

        But if you are making theme for public release (this post is about public releases) you should not hard code your menus like that and you should use WP menu system. Why? Because not all end users want to have all sub-cats hard coded in to theme. They want to decide what they want to put into menu and what is under what menu items. It only takes few seconds to drag menu items to do so. For example if I wanted to exclude couple of categories and four sub categories it’s so much easier to do with WP menu system.

        Same goes with pages by the way. They are not listed automatically either for the same reason.

Comments are closed.