The WordPress theme market nowadays could undoubtedly be described as huge. There are tons of offers and new options appear every day. Rarely has a week gone by without any “WordPress theme reviews” in my news feed. But when it comes to the selection of a theme for a specific project, such diversity provides more pain than one might expect.
Usually, we just try to find a good looking theme that suits the aesthetic of our project, and has some set of customization options. The problem here is that WordPress themes consist not only of visual goodness, they’re pieces of software, and should be treated as such. This post aims to reveal some factors that affect WordPress theme quality and share some tips to help with the search for and selection of the right theme for you.
Why should you care? Wanting to make good use of money spent on a theme’s purchase is just one thing. There’s more to consider. Your project or your business is relying on it and becomes dependent on its stability, security, and overall quality. If you are developing a site for a client with a theme, it becomes critical in terms of your final product and client satisfaction. The last thing you want is endless support questions due to the poor code and unstable behavior of the theme you’ve used.
So let’s see what to take into consideration when choosing the premium theme for your next project.
Who is behind the product?
Before making a decision, you should figure out not only what are you’re going to buy but also from whom. There are plenty of sources that aim to help you find a good theme provider, like blogs, review sites and themes galleries (even wordpress.org has one). But living in era of marketing hegemony, we should not rely much on such “social proof”, because it mostly reflects the success of the sales strategy, rather than the true quality of product. Instead, try to figure out how the particular theme provider treats its clients in reality, and how influential it is in WordPress community.
What should be taken into consideration?
- Documentation: How well are the themes documented? Do you have access to documentation before purchase? Is there any kind of knowledge base or are you just told to search the messy support forum?
- Support: What support options are available? Do they really work? How active are threads on support forums? Is there an option for pre-sales questions? If so try to use it. Do you receive a helpful reply, or just a general sales letter?
- Does the company or individual provide any information for the community, like a blog, or contribute to WordPress related informational sources? Review such contributions. Is it real expertise, or just self-promotion? The same could be applied to the related social media profiles.
- Does the theme provider contribute somehow in the WordPress development? Do they participate in any partnerships or developer initiatives?
An attempt to answer the questions above will reveal the real company’s (or individual’s) deeds and approach to doing business instead just bright advertising images. You’ll be able to estimate how comfortable you feel with any individual provider. It may seem subjective and unrelated; but in reality we all perform subjectively. So, it could be strongly recommended that you don’t buy from the company (or person) that you don’t like, despite the number of positive reviews on their site.
Test drive options
Being software, a WordPress theme should come with a means to test and preview it in real situations. At a bare minimum, there should be a live demo available from the theme provider. Never, never make a decision based only on screenshots. It’s not a picture of the site you’re going to present to your visitors, but the real site in the browser. Therefore you have to see and test how the theme is prepared for that. Visit the live demo from the different browsers, and test how different UI elements work.
If you are building a responsive site, try to visit the demo from different devices, or at least use some of these RWD testing tools. Use in-browser testing tools (like Firebug or Chrome DevTools) to judge the quality of the previewed front-end code. Test the page load speed, see for yourself how effectively assets, scripts and styles are loaded, whether they produce any errors, how clean and understandable the HTML markup is.
Generally, you can go by this one simple rule: clean and well-structured code is easier to maintain and support. It reduces the probability of bugs and security problems, and appears to be one of the most important signs of quality in the final product. Messy code is the direct road to problems, even if it produces a good-looking result.
The back-end code, unfortunately, often cannot be so easily previewed and judged; but try to find some way to do it. Maybe the provider gives away some “light” or “trial” version free of charge. Or perhaps the theme is built with some framework, that could be obtained for free. Maybe there is some other free product that could help you analyze the developer’s overall approach.
Turn on the debug mode when testing your installation with the following statement in wp_config.php:
define('WP_DEBUG', true);
Effectively developed and tested themes should not produce any errors or warnings in the debug mode; so if it does, it’s a very good reason to look for another theme provider.
Also you can use additional theme testing tools, like these in particular:
- Theme-Check – A plugin that tests whether a theme is up to spec with the latest theme review standards.
- Exploit Scanner – A plugin that can help find malicious code on your site, including code in the theme files.
- The official guide to WordPress theme testing.
Red flags
There are plenty of discussions in WordPress community related to theme coding best practices and how to follow them. Unfortunately, many theme developers, even well-known ones, do not take these into consideration. Sometimes it’s a justified decision, sometimes not. But why is it so important to follow best practices and coding standards? The reason is quite obvious: even the most beautiful and robust theme is not a final site. It’s just a part of the equation, and is going to be used with other software products, like the WordPress core, other plugins, JS libraries or widgets, third-party services (like social buttons or email-marketing services), etc.
When themes are developed for public release (vs being created for one particular project), it’s the developer’s responsibility to make it work as best they can in situations that can’t be predicted. This can be achieved only by following the community standards and common conventions that every WordPress developer should be familiar with. If every developer respected these conventions, there would be few, if any, conflicts between the software from different sources on a single site. Unfortunately, it’s just a beautiful and utopian dream. In reality, we have to deal with theme and plugin conflicts all the time.
Another reason is customization. Modular code that respects conventions could be quite easily altered through the default WordPress tools like actions, filters and child themes. But, a lot of developers don’t use them, thus creating difficulties for site owners who want to customize their products without hacking.
Further, I’d like to discuss some of these conventions and features that many theme developers handle badly. If you manage to test a trial version of the theme you want to buy, see how it handles the following concerns. Some of them may not be critical for your project; they undoubtedly are symptoms of potential problems, if not handled correctly.
1. Not using HTML5 doctype
WordPress has declared HTML5 doctype in default themes since (at least) TwentyTen. It allows plugin developers to rely on modern browser features, especially when they are creating functions to produce front-end markup. There is no reason why other theme authors should not do the same. If you see a theme (especially on some popular and overcrowded marketplaces) that pretends to be “modern, clean, semantic” but doesn’t use HTML5 doctype, it probably means that the product doesn’t match the description.
2. Not including scripts and styles properly
Themes scripts and styles are the heart of front-end code, and yet there is often much confusion here. There are at least two imperatives that every theme should obey at all costs (and they are violated most often):
- Themes should not de-register or re-declare JS libraries that are packed with the core, jQuery in particular. It should always use the built-in jQuery, even if it’s an older version. There are some really good posts about the subject, so I’m not going to repeat them here. I’d just like to warn everyone, if your theme de-registers the built-in jQuery version, it’ll get you in trouble one way or another.
- Themes should use native wp_enqueue functions to load styles and scripts. It should not print them directly in the <head> of the document. It should not print them inline somewhere in the markup. Doing so will cause conflicts and problems with customization, with nearly 100% probability.
Please refer to this excellent guide to loading scripts and styles in WordPress for more information on the matter.
3. Not using default hooks
Many plugins alter behavior of some template parts in assumption that native core hooks like the_content or wp_head are present in theme’s files. If theme developers remove or replace them with their own, they force the site owner to get hacking.
4. Not making the theme localization-ready
For large (or should I say huge?) numbers of customers, such an ignorance of international markets makes a theme absolutely inappropriate for usage. At the same time, it does not require back-breaking effort from the theme developers to make their products localization friendly.
5. Heavily packed with plugin functionality
There is no unambiguous rule to determine what functionality should be included into themes and what should be in plugins. That’s why there are plenty of discussions on the matter.
Many themes include plugin-related functions and options naming the fact a competitive advantage. But in reality it’s not so simple. The classic example of such duality is SEO optimization. A lot of themes claims to provide a SEO tools for site owners, but at the same time there are excellent plugins on the market for the same thing. So the thoughtful site owner would rather use a more sophisticated plugin and separate SEO efforts from the theme, in order to keep them in case of a site redesign. Speaking optimistically, the theme with “SEO tools” may just duplicate the functionality of a plugin; but in the worst case scenario, there will be a conflict that may not be resolved without hacks.
Conclusion
When selecting a WordPress theme, we should treat it like software, not just a design product. Testing and code quality estimation becomes an essential part of the selection process, especially when customers are developers themselves. The tips discussed here are not all-encompassing criteria, but should guide you through the diverse theme market in the hunt for perfect theme.
