The WordPress theme development market has grown incredibly in the past few years and with so many companies and freelancers around, how do you stand out? In this post we bring you five tips on how to make your theme easier to use, avoid frustrating customers, use WordPress to the max and provide better and cleaner code for WordPress developers.
1. Keep it Simple, Less is More!
I agree that features in themes are cool, hundreds of shortcodes, thousands of widgets and millions of theme options, but do your end users really need all that? Why waste your time doing something that will never be used, or worse, make your them confusing or conflict with plugins?
A great example is Google Analytics. If you’ve built in support for the GA tracking code in your WordPress theme, your end users can use that to track their visitors, right? Yes, but what happens when they stop using your theme? Their analytics stops working. There are various Google Analytics plugins available so just make sure you’re using functions like wp_head and wp_footer in your theme in order for them to work.
Another good example is SEO. Having good, semantic and easy to understand markup is always a must, but building in a bunch of SEO options like meta descriptions, titles and keywords is too much. What happens when your end user switches to a different theme? They loose all their data which is pretty difficult to restore. Again, there’s a good plugin to solve that.
If you do bundle options with your theme, make sure they’re easy enough to understand. You can provide a documentation or a screencast, but ideally your end users should be able to use your theme without having to learn anything new. A great example is of course Twenty Eleven.
Widgets, shortcodes and custom post types require a separate blog post, but when taking such decisions, always ask yourself the question on what happens when users stop using your theme. You don’t want them to, I know, but eventually they will, and the most frustrating thing that can happen during a switch is loss of data, meaning they’re locked in — our next tip.
2. Avoid Lock-in Effects
The lock-in effect is when your end user is locked in to using your one specific theme only, and if they do decide to switch, they will loose some or all their data. This is somewhat related to the point discussed above and of course you’ll be more than happy if your customer is locked in to using your theme, right? But your customer won’t.
They’re locked in to using WordPress already, although various export tools are available for transitioning to other platforms. Of course developers and geeky users can always work with raw data in MySQL or XML but others can find it pretty difficult and frustrating that they have to.
One of the easiest ways to solve this could be through plugins, either code compatibility for existing plugins or write your own. Yes, plugins can (and usually do) have lock-in effects too but as long as the plugin works with the majority of available themes (whether yours or third-party) then there’s no reason to turn it off.
If your theme has got three extra social widgets, write them as a plugin so that your customer can take the widgets with them to a different theme when they choose to do so. And also think about when your customer arrives with three existing widgets that they’d like to use with your theme, and make sure you provide appropriate fallback CSS styling for all the widgets, including standard ones. Besides, that’s just good practice ;)
It’s quite difficult to completely avoid lock-in effects, I agree, but that should be your goal. For example, why code a new gallery post type to embed photos in your WordPress theme if you can simply use WordPress’ built-in gallery features that work across the majority of themes? Which brings us to the next tip.
3. Don’t Reinvent the Wheel
I’m pretty sure you know that WordPress is not just a blogging platform these days and a lot of WordPress developers are overlooking the API that WordPress provides to it’s themes and plugins developers. Dig into the WordPress core, learn from the standard WordPress themes and look at what other developers are doing.
Of course you won’t find everything in the Codex but just keeping up to date with the changelogs of new WordPress releases is a good start.
WordPress has built-in support for image sizes and post thumbnails since version 2.9, that’s 2009 and you won’t believe how many themes are still using scripts like TimThumb these days. Other examples are background colors and image choices, navigation menus, the color picker script, the HTTP API, RSS feeds functions and a lot more.
A couple of days ago I even discovered a function called get_date_from_gmt which I found very useful when working with dates from Twitter. I never knew it existed before digging into the core, as well as checked and selected!
We wrote a more general article earlier called 5 Tips for Becoming a Better WordPress Developer which covers things like contributing, staying up-to-date and following the coding standards and best practices.
4. Theme Check and the Theme Unit Test
Seems like there will never be enough blog posts and articles about these so it’s worth mentioning them both again here. Theme Check is a WordPress plugin developed for the WordPress Theme Reviewers Team which runs a few thousands of tests against the theme sources.
You’ll have to use this plugin and pass all the tests if your goal is to get listed on WordPress.org, but using it for premium theme markets and even simple client jobs is a good idea as well.
The Theme Unit Test is an XML export of demo data that outlines most of the features built into WordPress, and while being mandatory for WordPress.org themes, it’s a good idea to quickly run through the tests when working with theme markets and client jobs.
With this test you’ll know that your h6 tag is styled, that nested lists are supported, that images and videos won’t break your design layouts and so on. You won’t have requests like “I inserted a right-aligned image in the editor but it’s not right-aligned on the site” if you know what I mean ;)
There are other plugins to help you in your general theme development workflow and we’ve listed some of them in this post: Essential Plugins for WordPress Theme Developers.
5. Think Child Themes
Child Themes is a great way to extend or modify existing (parent) themes by overriding template files and taking advantage of actions and filters available in the parent theme.
When creating a WordPress theme keep in mind that your theme may (and probably will) be used by WordPress developers, so why not make their life easier by adding those extra actions and filters and keeping your files and markup structure easy enough to adapt and build upon? Don’t overdo it though ;)
The best way to find out whether your theme is good enough to be a parent theme is to try and build a child theme yourself. Try adding a third column if your theme is two-column. Try adding a new page template, try adding a new option in your Theme Options panel, etc. We published a tutorial on how to create a child theme based on Twenty Eleven a while ago, which should give you a good kick-start.
And at the end of it all, do provide a short documentation to WordPress developers about the available actions and filters, about the template files and other assets. Ideally you’d like to build a Wiki and have (or better follow) a naming convention, so that developers wouldn’t have to learn new things when working with other themes you’ve built.
Conclusion
These are only a few tips that can make you stand out from the crowd. Do keep in mind that your code, features and documentation is only one part of the WordPress theme and that your design is the second and probably a larger one when it comes to theme markets. Make sure your design is top-notch and pixel perfect and that your theme demo is as complete as possible.
Have you got other tips to WordPress theme developers? Let us know by using the comments section below. Thank you for reading, sharing and staying tuned!
I agree that themes should keep things simple. WordPress is modular, so it makes sense to follow that approach.
It would be great to be able to bundle plugins into a theme install though.
I think the high competitiveness of theme marketplaces has something to do with the explosion of theme options as a way for a theme author to differentiate himself.
Paul, totally agree, bundling plugins into theme installs would be a great idea! Thanks for your comment :)
Some great tips there. Really good point about what would happen if someone stops using your theme, even with something as simple as having the Google Analytics ID in the theme options. Also, totally agree about keeping things simple. So many times you see themes with countless theme options that, in the end, are usually left at their default settings anyway.
Well said Anthony, thanks for your comment and kind words :)
Your post speaks exactly what we have been internally discussing for quite some time at We Are Pixel8. It wasn’t until we entered the premium theme marketplace what we noticed the abundance of theme bloating with options under the guise of features. I have to admit, in the beginning, we, too, fell victim to that temptation.
But now, we have taken a firm stance with our premium theme releases. We do not offer presentational shortcodes. We constantly edit out theme options that are better suited for plugins to insure portability. With two more themes in the production pipeline, we are considering making our custom post types plugins themselves so you can take that with you to another theme.
Good to know Erik, and yet, custom post types are different content models, so taking them to any other theme requires a lot of planning and fail-coding in the plugin. Like how would you display a Listing (real estate) post type in Twenty Eleven out of the box, without editing or childing it, if it’s got 20 meta fields and two custom taxonomies. I mean it’s easy enough to take shortcodes with you since a shortcode is only markup + CSS, but custom content models is a different story. Anyhow, I think we’ll get there eventually ;) Thanks for your comment!
6th tip: call wp_head() in header and wp_footer() in footer. I wonder how many theme developers forget to do this thus breaking plugins.
Nikolay, yes good points! I think that if we’re talking about .org themes, they shouldn’t pass the code review without those two anyway. Let’s hope the same’s happening in premium marketplaces ;) Thanks for your comment!
Hello Konstantin!
I have really been enjoying your posts today. Have read through about 3 or 4 of them (and still a few more to go!). Keep up the good work and continue commenting and sharing! It’s people like you that make me happy and proud to be a part of the WP community.
Maybe you could do a special post in which you provide details on the 5 themes you feel best follow what you have laid out in this post (above) and at the same time would be the most suitable to use as parent themes for one’s own theme development.
I guess I am looking for what most people call a “framework” (although Justin Tadlock has a slightly different view of things in this article (and I definitely see where he is coming from)), but I am looking for what most people out there consider to be theme development frameworks in the more general sense.
What I am looking for are theme “frameworks” that are heavy on the functions, hooks, filters and layout side, but very light on the design site (i.e., kind of like a skeleton framework)). Preferably, they should also be frameworks that are still under active development, with a stream of updates from time to time, with at least a sizable community of users (forums, etc.).
What immediately comes to mind for me are “frameworks” (again, in the loose sense) like:
Hybrid
Thematic
Toolbox
TwentyTen
TwentyEleven
and others…
Might you weigh in on this? Pros, cons of each one, etc…?
Thanks again!
Respectfully,
Chris M.
Hi Chris, yeah I noticed you went on a commenting spree last night ;) much appreciated! Everybody has different idea of what frameworks are, especially after some experience with things like Zend Framework, Code Igniter, Django, etc but in the WordPress world I guess it’s okay to call a theme a framework (but what do you call WordPress then? ;). However, the terminology doesn’t really matter that much since themes are basically allowed to do anything that plugins can do and vice-versa, but child themes is a little bit of a different concept. Mix that with frameworks and you’ll get the parent theme framework api :)
Parent theme because you can create a child theme to override the templates, framework because it provides you with the template files for most of the stuff you’d want to do (sort of a boilerplate) and api because it provides you with the functions, actions and filters to do things like pagination, breadcrumbs, etc. A monster like this requires some serious documentation, otherwise it’ll all just get lost and forgotten, even by the developer who initially wrote it. Anyway … back to your question ;)
Twenty Ten and Twenty Eleven are good for using and especially for learning WordPress. Thematic, Hybrid, Genesis, Thesis, there are many of them, all with their own approach, structure, philosophy and support team, best is to try them out and see what they all have, then compare that to what you need, maybe you don’t need a framework after all? Or maybe it’s easier to create your own boilerplate and start off every WordPress project with that. Honestly I haven’t had good experience with any of the frameworks so I can’t really be a good judge, but their support forums will tell a lot I’m sure.
Hope this helps and thanks again for coming by :)
Thanks for all your great articles. I check this site often. This one helps me on what my focus should be moving forward in my studies on creating WordPress themes.
I’m curious about the Google Analytics thing. Are there repercussions to using a theme that provides this other than having to install a plugin that does the same thing if you switch themes?
This article definitely gave me food for thought moving forward. It doesn’t make sense to add in features that plugins do perfectly well.
Hi Michael, thanks for your kind words! Google Analytics is not about providing the functionality, but rather splitting functionality into groups or areas — one is the plugin area, the second one is the themes area and I believe that Google Analytics should be part of the plugin area because it has no affect on the visual side of your website (which is your theme’s main aspect). Thanks for your comment!
Great post ! I still don’t understand why some themes creators, even well-known ones like woo themes or elegantThemes keep using their own built in thumbnail maker, navigation, or SEO options. Worse is when these options conflict with another plugin you installed.
I agree. Thanks for your comment :)
Pingback: CSS Coding Conventions | Experi:mental