I will soon be writing reviews for some of the main WordPress plugins and theme frameworks that I use in my client projects. But before I do that, I wanted to write a post explaining the basic criteria I use to evaluate a theme because they are not necessarily the same you’ll read about in most other reviews out there that focus on workflow features alone. I’ve read many theme framework reviews in the last 3 years and I found most of them to be lacking in substance. That’s not because they were bad reviews or because the people writing them were doing a bad job, they were just aimed at a specific kind of user (non-coders, beginners or casual users) and limited themselves to what I consider “surface” criteria that become far less relevant when you build Web sites with WordPress for a living. When your business and reputation depend on the quality of the themes and other products you install on client sites, “features” like drag and drop and especially “no coding required” quickly take a second or third seat to more important matters like performance, stability and flexibility.
So here I’ll explain 4 of the basic criteria I use to evaluate a theme framework’s suitability for inclusion in my workflow to be used on specific projects. I’m concentrating on issues I rarely if ever see mentioned in theme reviews so I won’t talk about things like ease of use or flexibility of any workflow related features here. Those things will be included in my specific theme framework reviews. I hope this article will help you make more informed decisions if you are looking for a theme framework to use on a client site and are not sure which one would be the best fit for your workflow and your client’s needs.
Who Is This Post For?
This post is mostly aimed at professional or serious WordPress developers, designers and users. If you can’t code and are not interested in learning because this is not your job or responsibility or you are a hobbyist and nobody’s income depends on the reliability of the WordPress sites you build, then this article is not written for you. Keep using WordPress, keep having fun and move on.
But, if you are building or want to build WordPress sites for paying clients on your own without depending on an outside developer, or if you are not a coder but work in an agency, studio or team where you have a say about the WordPress tools your team are using, then read on. This post is for you.
I make this distinction because, so many WordPress theme framework reviews concentrate only on theme aesthetics or other debatable criteria like the aforementioned and bullshit “no coding required”. They often fail to qualify the review’s intended audience and forget other important aspects in choosing a suitable theme framework. Many reviewers often use a theme only for a few hours and rarely use it on mission-critical client sites to see how the theme performs over time in the real world before publishing these reviews. When you wait to go through a few WordPress or theme updates, it can reveal very unpleasant surprises if the theme’s developer is not using WordPress standards or is not careful with changes that can affect the layout of a client site when the theme is updated. In that respect, theme frameworks are definitely NOT created equal! Trust me, I’ve wasted countless hours fixing sites after a theme update broke the layout. To me that is completely unacceptable and quite avoidable if the developer is careful. But surprisingly, no review I ever read has mentioned this issue!
Furthermore, a good theme framework takes a significant time investment to master. A seemingly solid framework may have limitations and defects that are not immediately obvious to a new user. They may only be revealed when you need to implement a client requested feature that falls outside the basic theme’s capabilities, or perform a theme update that breaks a site. These are things I experienced personally and they made me waste many unbillable hours. Wasting my time because of someone else’s carelessness is one of the things that irritates me the most.
So, if you too care about your time, know that most of the themes I’ll be reviewing in the future are themes that I’ve used at least once on real world client sites or on my own. If that is not the case, that will be mentioned in the review and you can weight my findings and opinions accordingly.
What Are WordPress Theme Frameworks?
You’ll find plenty of explanations of what theme frameworks are on the Web but I want to quickly define what a theme framework is in my own words so can you better understand where I’m coming from later. Unlike a regular theme, a theme framework is generally a reusable starter point used to integrate your own designs and functionality into a WordPress powered Web site. They are a known baseline you start from to create custom Web sites for your clients. Many theme framework vendors also sell their own pre-designed child themes or skins but, for my purposes I’m mostly coming at it from the perspective of someone integrating custom designs from a framework’s “default” or base look or a “starter” child theme. This article still applies to themes that are pre-designed but can still be heavily customized through a child theme or other means.
To accomplish this customization work, each theme framework comes with a varying number of user controlled options which can be used to modify the behavior or appearance of the site. Some frameworks have few design options while others have extensive admin sections one can use to change fonts, colors, layout, etc. Some have sophisticated SEO features or come with their own Widgets, shortcodes or even their own Custom Post Types. Some have front end drag & drop UIs used to build page layouts while other have more indirect means to do the same from the WordPress admin. All of this makes it hard to compare frameworks on features alone as they are often not direct apples to apples comparisons.
If you’ve worked with WordPress for some time you are probably already familiar with the parent/child theme concept. I won’t explain that here and you can look it up if you are not familiar with it. Most theme frameworks work using that standard parent/child themes paradigm but others have their own proprietary “skins” system. Not surprisingly, I strongly favor the first kind for several reasons, including the fact that it makes it a lot easier to reuse code if you need to switch themes and believe me … you will! Learning how to personalize a parent theme through a child theme is also a skill that will be much more easily portable to other themes when come time to switch than working with some kind of proprietary “skinning” system.
My 4 Basic Criteria to Evaluate a WordPress Theme Framework
Before I begin I want to clarify one more thing. If you’ve read some of my earlier material here, you may know that I used to work exclusively with one theme framework. That is no longer the case for reasons I’ve explained before. I now own 6 different theme frameworks and I have used 4 of them over extensive periods of time either on client sites or on this site here or on my business site where I’ve used 3 different frameworks in the past. So I’ve lived with these frameworks on real projects for a while. I went through at least one major upgrade with each and several minor ones. I’ve also built very different kinds of sites with them, some simple and some much more complex where I needed to get my hands dirty in the code to get specific results. So I know them well.
Nowadays I try to choose the best theme framework for the project at hand and that choice depends on two main things : one is how complex will the layout be and second, how complex will the functionality be (will I need to use many Custom Post Types, etc.) These have a direct impact on my choice as not all frameworks are as easily customizable as others. So without further ado, here are my criteria.
1- Does the Theme Framework Respect WordPress Standards and Best Practices?
This criteria is one I rarely see mentioned in theme reviews if at all. It’s not on many WordPress users’ radar either because non-coders do not know how to evaluate the technical quality of a theme or framework. That’s why they need help from a review! But this criteria is absolutely key and the people who pay no heed to it are often the ones who are the least able to deal with the issues a poorly coded theme often creates.
What I’m talking about here are things like, does the theme support and use the parent/child theme paradigm. Most modern and popular frameworks do support child themes except for Thesis. To me, that is key as, like I said above, using child themes enables you to modify the parent theme’s default look and behavior without modifying the parent theme. This keeps your customizations safe inside a child theme when the parent theme gets updated. All themes get updated at least once or twice a year or more often so you never want to modify a parent theme directly.
Secondly, does the theme expose WordPress loop code for user modification in standard templates than can be overridden in a child theme? Some frameworks like Genesis do not expose loop code in standard templates directly but offer a sophisticated hooks system instead. I used to be adamant about avoiding themes like that thinking it would be limiting for customization. But as I’ve started to work with Genesis, I realized that using hooks is just a different way of customizing a theme and can work just as well. Sometimes it can even be cleaner as you just need to manage exceptions to a standard loop. Other popular theme frameworks work exactly the same way. My previous go to frameworks, iThemes Builder and WooThemes Canvas do use the WordPress templates hierarchy and these templates contain real loop code you can modify at will. I’m used to that. It makes sense and I used to prefer it but, as I said, I no longer consider this an issue at all as a great framework like Genesis has other means to achieve the same result. I think it actually enables the parent theme to remain more stable. Exceptions are managed in the child theme where they belong with hooks that can override the default loop.
What is far more important to me now is if the theme plays well in the WordPress ecosystem. Builder, WooThemes and Genesis certainly do that. Headway, not so much and Thesis even less so. For me, that is a real problem. When you need a “connector” plugin to support other sometimes very popular plugins and make them work in your theme when that same plugin works out of the box in most other themes, you are not working so well in your chosen ecosystem.
When you start using WordPress as a CMS and get requests from clients for custom functionality, you’ll need to rely on complex plugins and advanced WordPress features like Custom Post Types to be able to deliver them to your clients. If your framework respects WordPress standards, that will be a lot easier than if it doesn’t. Again, this criteria is rarely if even brought up in theme reviews when it should be front and center IMO as it is very hard to gauge when you have not used the theme or are not very technical.
Lastly, another issue related to WordPress standards is that a theme should generally limited to controlling the look of a site as much as possible leaving behavior and content control to plugins. For example, many themes and theme frameworks add portfolio functionality to Web sites. Most do it through Custom Post Types. If that content should survive a theme change (as portfolio data usually does), it should be implemented through a plugin and not the theme. I’ve used and still use themes that “break” this rule but, if it has other weaknesses this might be the detail that pushes me to not choose it. Another example is SEO settings. Most frameworks have them but I prefer to use a plugin because those settings will survive a theme change in a plugin. Weigh these considerations carefully for your own projects.
2- Does the Theme Framework Support Industry Standards and Best Practices?
In other words, is the Theme’s HTML and CSS code well organized and easy to read and modify and is the HTML valid and as clean and semantic as possible?
Fortunately, this criteria is easier to judge than the first from the theme vendor’s demos where you can look at the theme’s HTML and CSS code directly. You can check for code validity, see if the code is clear and readable, etc. Theme framework vendors cannot hide their product’s weaknesses if any here. If the theme’s front-end code is sloppy, it might be a good indication that the back-end code is the same.
Theme demos can also give you an idea of the theme’s speed but they are often hosted on powerful dedicated servers that do not reflect a more typical shared hosting environment if that’s what you are using. You can still compare themes with one another and get some idea of their respective speed. Unlike other things, many of the most popular frameworks have been compared for speed and performance before.
For people like me that often use a framework’s basic started child theme to integrate a custom design this criteria is essential. Theme frameworks’ basic started child themes are often quite plain which is normal. When building a child theme and adding my own styles, I don’t want to fight the theme’s built-in styles every step of the way. So their CSS needs to be well written and the selectors can’t be too specific. Overuse of !important will also make your customization work harder. Inline CSS styles should also be avoided. You can easily replace a theme’s style.css completely in a child theme but most frameworks have other “fondational” or layout stylesheets they rely on. These styles should also be easy to override if you have to alter the layout significantly.
Regarding HTML, a framework often has to balance flexibility with clean and semantic HTML code. Here, Genesis, Headway and WooThemes have an edge over Builder which uses a lot of div containers to offer total layout flexibility. This didn’t bother me at first but it’s starting to become a much bigger deal for me now. Since I started working with WooThemes Canvas (and other WooFramework based themes) as well as with Genesis, I really started appreciating how much lighter their HTML output is… without limiting my ability to change layouts so far. Builder is a fantastic framework in all other respects but their HTML is heavy and harder to read. Like Genesis did when upgrading from 1.9.x to 2.0, iThemes could change this without breaking existing sites and offer an HTML5 option that would output much lighter and semantic HTML code while preserving the legacy markup for existing sites. I really hope they improve this soon. Which brings me to my third selection criteria.
3- Is The Theme Stable Through Minor Updates and Major Upgrades
This one is HUGE for me. WordPress is by far the most popular CMS out there. With that popularity comes the reality that it is a target for hackers. So all components of a WordPress site, be it plugins, themes or WordPress itself need to be updated frequently to remain secure. In the nearly 4 years I’ve been working with WordPress, few updates have caused me issues like layout changes or broken functionality but, the issues I have encountered were, by far, most often caused by theme updates, not by WordPress or plugins. This criteria is impossible to judge and review after using a theme only a few hours or a few days. That’s why theme reviews never mention it that I have seen but, to me, it’s now a deal breaker.
Here I’m talking about a parent theme updating from version 5.2.3 to 5.2.4 for example. Or from 5.2 to 5.3. These are usually bug fix updates although theme vendors often add new functionality in minor updates too. Ideally, minor parent theme updates should never bring changes that can break a site’s layout or functionality. In all the theme frameworks I’ve used, iThemes Builder stands alone here. A Builder update never broke a client site for me. I’ve not used Genesis long enough to make a final judgement but, from reading user feedback after upgrades from 1.9.2 to 2.0 (which is a major upgrade), it’s on par with Builder. You needed to add specific code in a child theme’s functions.php file to enable HTML5 and schema.org markup in Genesis the same way you needed a special line of code to enable the responsive features introduced in Builder 4.0. I had many sites on Builder 3.x when iThemes updated it to version 4 and none of theme were adversely affected by the update.
I can’t say the same for WooThemes Canvas as some early 5.x updates brought markup or CSS changes that were important enough that I had to make some adjustments in some of my child themes. Later updates up to 5.3.0 were far more stable. But even the early changes were relatively minor requiring only a few minutes to fix. These breaks may also have been caused my my lack of familiarity with WooThemes Canvas at the time as my child theme’s custom CSS for it tend to be much smaller than before now.
By far, the worst in that respect for me has been Headway 3.x. Early updates had markup changes that were very important like removing IDs in footer markup and replacing them with classes which had the effect of completely breaking the custom CSS that was relying on that ID. That was with a minor second decimal update (3.0.4 to 3.0.5 if I remember correctly). Thankfully, I had only one site on Headway 3.x at that time… and I still have only that one site on it. For me, changes like that are unacceptable. It revealed very poor planning on the developer’s part as these kinds of decisions should have been made long before releasing Headway 3 and the markup should not have changed this significantly after that. If I’d had dozens of sites on Headway 3 at the time like I have on Builder now, I would have lost countless non-billable hours fixing sites for no good reason. That’s one of the main reasons I stopped using Headway completely and I do not plan to ever use it again. I lost all trust in them to not cause me costly trouble in the future. That was one thing after many others I won’t go into here.
Which brings us to major upgrades.
Here I’m talking about upgrading major versions like from version 1.x to version 2.0 for example. That is a major number change that usually brings major new functionality and change. Theme vendors have two very different philosophies when it comes to major upgrades and the validity of each philosophy is much less clear cut than in the case of minor updates. In the latter, stability should be a given IMO. I can’t be expected to have to fix my custom code every time a theme releases a minor second decimal or security update.
But in the case of major upgrades, theme vendors sometimes treat that as an opportunity to do total rewrites that break with the past completely. Headway did that when they released version 3.0 and Thesis did the same more recently when they released Thesis 2.0. Both broke completely with the past and sites running the previous versions cannot be updated to the new version without major rework. It’s basically like switching to a new theme from a different vendor.
I have stopped using Thesis long ago but I lived through the 2.0 to 3.0 Headway upgrade and it was painful for me and many others. They long promised some kind of upgrade path from Headway 2 to 3 but that has never come and it’s now almost 2 years later. I have many sites on Headway 2.0.x still and I cannot justify the time I’d require to update them to my clients as the sites visual design would not change. This would not be a redesign and the choice of using Headway was mine, not theirs. So what do I do? I have to live with my previous choice for now… and change the theme on my own dime if it ever stops supporting new WordPress versions down the line before my client decides they want a new look. Not a good position to be in that’s for sure!
In the case of iThemes Builder, I’ve lived through 2 major upgrades now: 3.x to 4.0 and just last week, 4.x to 5.0. In both cases, no sites of mine have been broken and no rework was required. In the 3.0 to 4.0 case, I could take my time and decide with my clients if they were ready to pay for the time required to add the responsive features of Builder 4.0 to their sites and modify their custom child theme to do so. In all cases, the time required was less than a couple of hours per site. From what I’ve seen, Genesis upgrading from 1.9.2 to 2.0 was a similar experience for their users.
So here you have a decision to make when you choose a theme framework. You will need to look into the vendor’s history and see how they treat major upgrades and how those have affected their existing customers. In the case of iThemes (Builder) and StudioPress (Genesis), you get theme vendors that offer backwards compatible major upgrades that do not break existing sites. In the case of Thesis and Headway, you might get complete breaks from the past. Some would argue that the changes in both were substantial enough that the break and major rework required to upgrade existing sites was justified. To me, they were not, but only you can decide that for yourself.
Another thing to consider is that, when a theme releases a major upgrade, it may be time to review the site’s design anyway so that upgrade’s stability or lack thereof may not be a bid deal to you. At that point, you may decide to change the site’s look completely anyway. The only thing is that you need to be aware of it BEFORE you choose a theme framework as future upgrades may be either painless or a major hassle if you want to stay with the same vendor. Nothing will give you a definitive indication of how smooth or difficult a specific framework upgrade may be, but you can easily ask around on social media or read a theme vendors forum to try and find out in advance how these things were handled in the past.
In my case with Headway, I feel like they have let me and their other pre 3.0 users down. They’d say it’s the cost of innovation and many agree with them. I don’t, so I made my own choices and they lost me as a customer and evangelist. But I still have to pay the price of living with a mostly unsupported product that was left without updates with a known and serious security vulnerability for over a year. There was an old and insecure TimThumb version in Headway 2.0.13 that was the current version when Headway 3.0 was released and this was updated only when 2.0.14 was released over a year later. To me that is downright reckless and irresponsible. So Headway has failed to meet the responsible upgrade criteria for me in every way and I’ve added this example here as I will not be reviewing Headway in the future and I want to convey as strongly as possible that your choice of a theme framework should be based on far more than a list of features…
4- How Solid and Reliable is the Theme Framework’s Vendor
Regardless of the technical aspects of theme selection described in the 3 previous points, a theme vendor’s reliability may be the most important criteria. Here I’m talking about the ability of the vendor to support and improve their product adequately over time. In my experience, larger companies like iThemes (Builder), StudioPress (Genesis) and WooThemes have provided me much better support and a better overall customer experience that smaller 2-3 persons companies like Thesis and Headway (both may have more people now). Companies with larger staffs can generally handle more customer support requests and can invest more resources in the planning and development of their products. This should weigh in your choice too but don’t judge a product solely on this criteria. Smaller outfits like CobaltApps (makers of the former Catalyst theme and the Dynamik WebSite Builder and Extender plugin for Genesis) are doing incredible work on very focused products and they support and document them very well. It’s just one more thing to take into consideration.
But, for me, WooThemes and iThemes both take the cake for the quality of their support in the entire WordPress ecosystem to this day. Both have gone the extra mile repeatedly for me and provided the best support I’ve experienced from any theme vendor so far except for the developers of the fantastic MemberPress plugin which I will review eventually. Both WooThemes and iThemes have often helped me with unique issues and even provided specific code snippets to solve my issues when other WordPress products vendors have simply referred me to obtuse documentation or simply ignored my pleas for help. The quality of a product makes me an enthusiast, but the quality of a vendor’s support makes me a fanatic and extremely loyal customer. Both iThemes and WooThemes have done that for me and, as I work more with Genesis, I have a feeling it will be the same with StudioPress. I feel much more confident choosing a theme framework for an important client site when I feel the theme’s vendor has my back no matter what. That’s probably the most important criteria for me here.
As you may have guessed, my first selection criteria is quite hard to judge if you do not already own a specific theme framework and cannot try it in a local or development test environment first. So are the quality of the vendor’s support and their ongoing product improvement. Most theme vendor’s pricing is quite reasonable IMO and, as these products will likely enable you to serve several clients, you could make an investment in more than one of them as I did and test them thoroughly before you decide on one for a specific project. That is what I’d advise you to do. Points 3 and 4 will require some research on your part but that time investment will pay off in the future. It may help you get passed a positive first impression of a product based on an impressive list of features or marketing copy and push you to look deeper at these not so obvious things that can have a huge impact on your experience with a theme framework.
I hope this article has been helpful to you. You can look forward to specific theme framework reviews in the future but you will now know the 4 basic criteria I look at before I even dive that deeply into features and workflow. I hope this helps you make more informed choices!