My Premium Theme Experience

I’ve been working on a design for my girlfriend’s blog recently.

Heather wanted a blog to document her year studying abroad, so I set her up with a WP install on what’s — even if I do say so myself — an excellent domain, http://heather.in/ (and this is made all-the-more better by the permalink setup, so posts are published as heather.in/england/with-a-cold, for example).

I figured the quickest and easiest way to get the site off the ground was to use a premium theme. Heather was after a simple, personal-feeling theme so it made sense as a time-saver.

And so I set about finding The One®.

My first problem came when I wanted to draw up a shortlist to send to Heather for her to look over. Despite all of the “theme galleries” begging for your traffic in order to show you pages and pages of affiliate links, none of these seemed to have themes actually organised into any logical order.

I was thus left to browse through the theme libraries of a handful of vendors I figured would make good options, drawing up my shortlist from that. Not ideal, but no particular cause for complaint. From the shortlist, we were able to narrow the options down to two or three options which would’ve worked well.

As all the themes on the final shortlist were licensed under the GPL, in the end we went for a mix-and-match approach, taking bits of two themes and bolting them on to the other, which we used as a “base”.

The site ended up turning out really nicely, but the moment I stopped using the options panel and tried to do some coding for myself, the problems started.

I’m not going to name names here as it’d be unfair to judge a theme vendor which has many, many themes on the basis of one of those themes, but I was appalled at how badly made the theme I used as the base was. It was genuinely absolutely atrocious.

The fundamental problem was that the theme was built around the options page. The secondary — and in practice vastly more annoying problem — was the theme accounted for the options by adding a bunch of CSS IDs and classes to pretty much everything, which meant the bulk of the CSS was spent burying down into very specific selectors just to align the sidebar left or right.

This meant that when I came along and wanted to do some quick customisation to the sidebar by, say, moving it from left to right, instead of writing:

#sidebar{ float:right; }

I had to write something like:

.two-column.standard-width #sidebar-align #sidebar{ float:right; }

The problem with that? Instead of having a “default” layout where #sidebar was floated left, the “default” was floating the sidebar left by adding a load of classes which were powered by the options page.

I ended up just stripping out most the options-powered functionality in favour of something simple which just worked. After I’d done that it only took me a couple of hours to fiddle around with the look, set up email subscriptions and make the design responsive.

And this brings me around to something I mentioned on Twitter a couple of weeks ago. WordPress themes need to be using scalable and modular CSS so that when customers come around to customising themes, it’s super-simple.

People think PHP code is scary, but CSS is just about manageable. You can go a long way customising a theme just using CSS, too — when I’m answering questions in the WPZOOM support forum, a hell of a lot of the tickets can be answered with a couple of lines of CSS.

So take this as a public service announcement and a warning, if you will. To theme makers: please, please ditch the thousand-option options pages and implement what you do have using CSS that makes sense. I don’t want to have to jump through ID and class hoops to make some very simple changes.

And to theme buyers: just have a read through that stylesheet before you buy next time. You’ll likely thank yourself later on.

It’s not ranting, it’s constructive criticism. Let’s talk it out folks.