When I wrote the 2012 version of this post last year, I did not expect it to become the most commented post on this blog ever. It made me realize that there is a real hunger for information about premium WordPress themes and frameworks out there, a need for opinions from people working with some of these products every day and who are not afraid to speak their mind. I like to think I do that here.
I also try to make a distinction between what frameworks would work well for professional WordPress designers and developers versus casual users. The former is what interests me and most reviews out there are targeted at the latter. Also, you often get a review from someone who tinkered with a framework on a test site for a few minutes or hours. I work with the themes I mention here all the time. Testing a theme framework for a couple hours will not give you a perspective on things like:
- How well do upgrades and updates work? Do updates typically break client sites layouts? Do you need to tweak your child themes every time you upgrade the parent theme?
- How does the framework perform on a real live site with real traffic? Is the site slower or faster with this framework compared to others?
- How does the developer handle support? How fast, how helpful are they. This is key when your client work depends on a product like a theme so heavily.
This post is also a kind of intro to other posts I’ll write in the coming weeks and months where I explain in more detail the reasons I’d choose a WordPress theme framework over others and I’ll finally write some real in-depth theme framework reviews based on these criteria. That is already started.
But for now, here’s the state of my 2013 WordPress themes toolset…
This year’s post will not be as hard hitting as last year’s since the last 12 months have been about continuity and growth for me and my business. No radical changes in my themes toolset in the last year as my main framework has remained the same : iThemes Builder. It continues to deliver for me and I learn to appreciate it more and more as I work on more projects with it. But I took the time to experiment with others frameworks because I did not want to be in the same dead end situation I found myself in 18 months ago when my previous framework stopped meeting my projects’ growing needs and I wanted to find an alternative I could use quickly if for some reason Builder stopped delivering up to my expectations. So now I also use a second theme on certain projects: WooThemes Canvas. More on that later in the post.
A Year of Continuity, Stability and Growth
If I’d been busy in 2011, then in 2012, things just got crazy. That is great news for any business but it adds pressure on me to streamline my workflow and consistently deliver Web sites to my clients that are stable and efficient. I’ve worked very hard on optimizing my business in the last year by taking both large and small steps to improve it. The biggest change I made was to officially partner with a graphic designer I’ve known for over 20 years. I worked with her in my old job in the screen printing industry and have always admired her creativity, talent and business mindset. We learned the ropes of business in the same company after all.
That means that for most of my recent projects, I could concentrate completely on the client relationship, the project’s strategy then on the WordPress development side leaving graphic design almost completely in her hands. As much as I love to design, I know that it’s not my main strength and my clients are better served this way.
So, in spite of my increased projects load, this has enabled me to work at a less crazy pace in the last few months and improve the way I work with my theme frameworks. As the number of existing WordPress Web sites I maintain is also growing, ease of update is more important than ever for me and that means sometimes being able to update not just the parent, but child themes as well. iThemes Builder remains the best framework I’ve ever used in that respect. No update of the parent Builder theme has ever broken a client site layout. Not once, ever. That to me is priceless and goes directly to trust. If a theme fails me and breaks on a site either after a minor update or just like that for no apparent reason as Headway has done for me numerous times before, it’s my own reputation on the line. My clients do not care what theme is used on their site. They just want it to work day in and day out. Builder has delivered that for me and given me peace of mind. For me, that is huge!
The Evolution of iThemes Builder
2012 was also a great year for Builder. I was the year that Builder 4.0 Responsive was released. I do not have to tell you how important a solid mobile strategy based on responsive design is on today’s Web. Builder 4.0 added responsive features in a way that is both very flexible, works great out of the box and does not break existing sites. It’s the kind of revolutionary upgrade that often means a clear break with the past and difficulty upgrading existing sites. But unlike Headway and their upgrade from 2.0 to 3.0 or Thesis with their upgrade from 1.x to 2.x, the Builder 4.0 upgrade was painless. Chris Jean which is Builder’s lead developer at iThemes is someone I truly admire because of his level headed customer-oriented approach to theme development. When you upgraded a Builder 3.x site to 4.0, you needed to add a line of code to your child theme’s functions.php to activate the responsive features. Otherwise, your site was basically unaffected and the layout didn’t change. Again, priceless.
I love this approach to theme development because it instills confidence and you know you can upgrade your parent theme with no fuss or worries and benefit from any security or performance improvements even if you are not ready to use a new feature as big as responsive right away. Updating child themes is not as easy as updating the parent and Builder’s stability gave me time to figure out how to do it before I tackled it on client sites.
The Evolution of my iThemes Builder Workflow
This upgrade to Builder 4.0 also brought updates to several child themes. The one that interested me most is Builder Default as it is the base child theme I’ve used to build all my Builder based client sites so far. The way I’ve worked with it has evolved recently mostly because of my experience creating child themes for WooThemes Canvas. The two frameworks use a different strategy for styling their child themes but the way Canvas does it has pushed me to modify how I do it with Builder.
What I mean is that, when creating a child theme for Canvas, you generally just import the parent theme’s style.css into your child theme’s style.css and either add your own style in that file or use another file named custom.css in your child theme that Canvas loads automatically if it is present (you don’t need to enqueue it yourself). This means that if a parent theme update significantly changes the layout CSS, it’s possible that a site’s layout could break. On the other hand, when you use the Builder Default or any other Builder child theme, the child theme’s style.css file contains all the styles that affect the look of the site (other than built-in framework styles managed by the parent theme exclusively). The style.css file in Builder child themes does not import the parent’s version first then add style overrides to it. They are a complete replacement so the parent’s style.css is not used at all.
In order to add your own customizations to CSS in Builder child themes, you generally either edit CSS rules directly in style.css or add new rules at the bottom of that file to either override default styles or add new ones. The later method is what iThemes generally recommends. But in my own Builder child themes development workflow, I usually went with the first method and modified style rules directly. Old habits die hard and it felt “wasteful” to me to just repeat the same style rules with different values instead of editing the original ones directly. Since Builder child themes do not import or rely on the parent’s style.css at all, it made sense to me to do it that way. I’ve been working on the Web for a long time now, and until not that long ago, the idea of keeping all files as small as possible was still a very important issue that was constantly being drilled into us. But the size of a CSS file these days is not as critical as it used to be. I’m now realizing that this method of customizing a child theme is far from ideal… Live and learn!
What is becoming more important for me is making it easier to update child themes. These updates are definitely not as frequent or critical as parent theme updates but, in the case of Builder 4.0 and responsive for example, a lot had changed in the responsive child themes’ CSS. As I had modified some but not all the rules in there without just adding override rules to the bottom of the file, I could not just overwrite the old style.css file completely with the new one and it made updating my child themes more difficult than it needs to be. This point is moot when a child theme just imports the parent styles like Canvas but Builder’s method is great because it’s one of the reasons updating the Builder parent never breaks a site layout.
So, with time I developed an hybrid strategy in my Builder child themes that is influenced by how Canvas and other themes work. I now create a custom.css file in my child theme and enqueue it in the child theme’s functions,php file. That custom.css file is where I put all of my styles whether they override the child theme’s existing styles or add new ones. This means that the child theme’s style.css file remains untouched and, as my styles are added to my own custom.css file, they are also loaded much later in the head code which makes it easier to override theme and plugins styles without relying on !important. This will make child theme updates much easier too because my additional styles and overrides are segregated in a separate file.
The other major evolution in my Builder child theming workflow is that, on my latest project, I’ve used their new Air starter child theme instead of Builder Default as I always have before. Air is a great starter child theme that has support for many post formats and adds several cool features over the plainer and simpler Builder Default.
The New Kid on the Block : WooThemes Canvas
As I said above, sometime during the last year, I started trying other theme frameworks. I didn’ t do this because I was unhappy with Builder, quite the opposite, I just wanted to have at least one solid alternative I could depend on. I didn’t want to put myself in the same position I was in when Headway stopped delivering the results I expected and I had to frantically search for an alternative while on a project deadline. I doubt that iThemes will ever make Builder unsuitable for my needs but you never know what may happen down the road. A company can disappear or a product can change in ways that do not serve your own specific requirements anymore for whatever reasons. That’s life in the software industry and we have to be prepared to face such situations.
I evaluated several framework over the last 3 years. I had no intention of going back to Thesis (ever) or Headway (for now) so I looked at WooThemes Canvas, Genesis (with the Dynamik child theme) and Catalyst. I now own all 3. Genesis and Catalyst are solid frameworks in their own right but the one that fit my workflow and philosophy best was Canvas. The WooFramework behind it is akin to Builder in that it uses the standard WordPress templates hierarchy and you can edit loop code directly. I explained why I much preferred this over non-standard implementations in last year’s post and this is one of the main reasons I chose Canvas. I also own a few other Woo themes including one of their “application” themes named SupportPress which is awesome as well.
Another reason I settled on Woo and Canvas is that I started using WooCommerce and several of their plugins and developed a healthy respect for WooThemes as a company because they offer very high quality products and support them well. Canvas works great with WooCommerce out of the box.
Finally, Canvas is a very full featured theme that clients love and it offers a lot of built-in functionality like sliders, a few special custom post types (portfolio, testimonials/feedback, etc) and more. It’s also an “options” based theme which means that you can tweak a lot of design parameters directly in the WordPress admin (colors, layout, typography) which can save significant time. Canvas is a fun theme to use and work with. It’s not as totally flexible as Builder in terms of layouts but it’s very easy to style and has a lot of hooks. I could use either one exclusively and deliver quality sites to my clients. Canvas is rapidly evolving and already is a powerful, well supported product. It is WooThemes’ flagship theme after all.
Now why would I choose one of Builder or Canvas over the other on a specific project depends on several criteria. If I need total layout flexibility and I know a project will be technically challenging, I’ll probably choose Builder. For a quicker turnaround, simpler layouts or if I need to use WooCommerce, I’ll probably use Canvas. But the choice is not always this obvious and I’m still working out the process.
This post sets the table for more in-depth looks at these theme frameworks and how they can help you build complex WordPress sites for yourself or your clients. I’ll be writing reviews of both Builder and Canvas soon. But my next post will be similar to this one but about plugins. In the last 3 years I’ve come to rely on a few trusted plugins I use on every projects and others that fill specialized needs. This is another area where information may be confusing or conflicting so I’ll try to direct you to some of my best finds and why I think they are worthwhile additions to anyone’s WordPress toolset.
Thank you very much for reading and, as always, all your comments and questions are welcome!