That move was not the first time I had made such a change and, if you’ve read the previous 3 articles I wrote on the subject, you’ll see that I’ve been on a journey to find a flexible and powerful theme framework that meets specific criteria that I don’t think are commonly addressed or even talked about in most theme review posts you may have read in the past. The most important of those for me has become stability, both for the product and the vendor.
These State of my Toolset blog posts are becoming a annual tradition on pixelyzed.com and this year will be no different. If 2012 had been a year of all around stability and growth for me and my business, 2013 was one of continued growth in my business but one of significant change in my toolset.
Those changes were brought by the same desire for efficiency and refinement to my workflow that I’ve described before but also because I’ve been going back to some of the core principles I learned and followed when I first learned my craft and started my business in the mid to late 90’s and early 2000s. I was a strong Web standards advocate then, long before it was popular to do so and long before Web professionals realized that clean, semantic HTML code was good for search engines optimization and accessibility (that was before Google…).
While not exactly bad in that respect, I started to feel that iThemes Builder, my main theme framework in 2012 and the first half of 2013, was not as good as I’d liked in that regard. I was starting to find its HTML markup way too heavy with an overuse of div containers, too many CSS classes and not enough effort placed on semantics. This was done by design at iThemes with the goal to make creating different layouts Builder as flexible as possible. I was also starting to find styling it (CSS) tedious and frustrating because of all those extra containers with similar class names that made the code difficult to read.
In addition to that, my business partnership with a designer has given me more time to concentrate on strategy for my clients in the last year and see what I could do to help them better with their business. This entails many things not related to WordPress but, one of the ways I felt I could improve our offering and our WordPress development process is with natural on page SEO. That means, among other things, clean semantic markup and faster load times. So I started re-assessing my themes toolset and looked for ways to improve it. Again, not because Builder was bad at this but it’s not using HTML 5 elements and it’s heavier markup makes it so search engines have to get through more code to get at the actual content. It’s not a ton more, but SEO is so competitive, I figured that every little bit counts.
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 theme framework 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…
The last few months have been my busiest since I started freelancing full time in August 2008 and I’ve also had to tackle some of my most complex WordPress projects. This means I had to re-evaluate parts of my WordPress toolset to be able to satisfy some of my increasingly demanding clients’ requirements and was forced to make some important changes to it.
I also learned a lot about WordPress as a development platform in the last two years and, after working with ColdFusion for a long time, I’m starting to get far more comfortable with PHP now. This enabled me to appreciate how powerful, elegant and flexible the WordPress platform really is and how much easier it makes things when you use the tools and APIs it provides correctly. This new understanding forced me to look at some of the tools I was using with new eyes and rethink some of the early decisions I made when I first started to work with WordPress. This includes rethinking Headway, the theme framework I’d been using as I was starting to have issues with it and the theme is the most important component of a WordPress site besides WordPress itself.