Seven Things I Hate About WordPress Themes

You’ve just installed Word­Press, and you head on over to the Theme View­er, a repos­i­to­ry of 1,500+ Word­Press themes, to find the per­fect design for your fledg­ling site. You find a few that have irre­sistible screens shots, down­load them, and upload them to your Word­Press instal­la­tion. Along the way, you notice that the files con­tained in the themes vary by quite a bit. Some themes are amount to ~200 kilo­bytes total, oth­ers tow­er over a megabyte. And upon acti­vat­ing the themes on your site, you notice that some are much more flex­i­ble than others.

And oth­ers take days of tweak­ing just to make it suit­able; you won­der how they were ever released into the wild in the place!

I’ve man­aged around a dozen blogs over the past two years — sev­er­al of my own, with sev­er­al for oth­ers as well — and the one thing that has caused the most headaches is man­ag­ing themes. I’m most­ly curi­ous if oth­ers have expe­ri­enced these same issues and so have the same com­plaints as I do so that I’ll have that bit of com­fort when trudg­ing through future themes; I’m also hop­ing that you theme design­ers out there will hear some of these com­plaints and work toward resolution.

So, in the spir­it of Word­Press Kvetch­ing, here are my top com­plaints regard­ing Word­Press themes, in no par­tic­u­lar order. 

Pages sup­port, or lack thereof!

Word­Press’ built in sup­port for sta­t­ic pages — includ­ing sta­t­ic pages, page order­ing, etc. — is in my opin­ion one of its most notable fea­tures. Using Pages, you can take a sim­ple blog site and build up around it a rich, mul­ti­leveled sta­t­ic website.

One of the rea­sons why I ditched solu­tions such as Dru­pal or Xoops is because of the over­ly com­pli­cat­ed method of orga­niz­ing sta­t­ic con­tent; indi­vid­ual menus must be built and arranged, con­tent must be placed into just the right mod­ule or sec­tion for it to show up, and so on and so forth. Over­ly clut­tered admin­is­tra­tion pan­els did­n’t make those tasks over­ly sim­ple, either. Word­Press offers an incred­i­bly user-friend­ly and pow­er­ful solu­tion for build­ing such sites.

But I have yet to find a theme that works with a rich­ly struc­ture site full of sta­t­ic Pages! At best, a top lev­el list of pages is added to the head­er or side­bar, but what if there are sub­pages? How do you expect vis­i­tors to find a sub­page that isn’t linked to?

Or per­haps that top lev­el menu of Pages isn’t set to ignore sub­pages, and so on sites that do have sub­pages, the style will break as unex­pect­ed con­tent is forced into an oth­er­wise attrac­tive Pages menu.

As of yet, the best imple­men­ta­tion of Pages I have seen can be found in K2, and pre­sum­ably most relat­ed themes. How­ev­er, things aren’t much bet­ter if sub-sub­pages or sub-sub-sub­pages, etc., are used.

Ide­al­ly, on the index page, archives pages, blog pages, etc., a top lev­el list of Pages should be pre­sent­ed to users. When vis­it­ing any of those Pages, all of the des­ti­na­tion Page’s sub­pages should be list­ed; click­ing any of those sub­pages should link not only back to the par­ent page, but also to its “sib­ling” pages (i.e., oth­er Pages on the same lev­el and in the same branch of the Pages heirar­chy) and to all of its subpages.

Such a set­up cer­tain­ly presents some design chal­lenges, but it would make putting togeth­er rich­ly struc­tured Word­Press sites so much easier.

And I admit, this is prob­a­bly my #1 com­plaint con­cern­ing Word­Press themes.

Required plu­g­ins and plu­g­in compatibility

I can think of very few instances where a plu­g­in would be required to use a theme, and I’m not even sure how valid those cir­cum­stances are. Your theme should work with Word­Press as it is, should con­tain the code nec­es­sary to emu­late the plug­in’s func­tions, or should include any required plu­g­ins with­in the pack­age. How­ev­er, we should­n’t be asked to change the func­tion­al­i­ty of a Word­Press instal­la­tion in order to change its appearance.

Fur­ther, while I’m all for themes hav­ing built-in com­pat­i­bil­i­ty with select plu­g­ins, make sure that you place con­di­tion­al state­ments around the plu­g­in code so that if the plu­g­in is not installed, its relat­ed theme code is not out­put. A sim­ple function_exists() con­di­tion­al wrap­ping the plu­g­in func­tion call & relat­ed styl­is­tic ele­ments is enough. Don’t just wrap the plu­g­in func­tion either; there is no rea­son to out­put the con­tain­er ele­ments if there’s noth­ing to fill them.

Over­work­ing index.php

I real­ize that a basic Word­Press theme can be built rely­ing upon index.php for every­thing from archive pages to search results, but styl­is­ti­cal­ly this results in a very bland look­ing site. No mat­ter how one brows­es — archives, cat­e­gories, the index page, or even tags if a tag­ging plu­g­in is installed — it all looks the same. I real­ize this can be over­come by using con­di­tion­als in index.php, but that cre­ates an over­ly com­pli­cat­ed file.

So why not make use of Word­Press’ extreme­ly ver­sa­tile them­ing engine? Files like 404.php, search.php, archive.php, single.php, page.php, category.php, author.php, and home.php should be includ­ed for com­plete­ness’ sake, and while they very much may mim­ic index.php, sub­tle touch­es could be made to each — such as includ­ing author infor­ma­tion in author.php or the use of the_excerpt() as opposed to the_content() in the var­i­ous oth­er files — which not only make them stand out as dif­fer­ent from the index page, but also tend to make a site more inter­est­ing and usable.

And for you Word­Press users out there, did you know you could apply a cus­tom style to, say, a cer­tain cat­e­go­ry’s archive? Say your cat­e­go­ry ID 5 archives should be styled dif­fer­ent­ly than your oth­er cat­e­gories; just cre­ate a category‑5.php, style to your heart’s desire, and upload to your site!

Change your theme, break your classes

If you have spent months blog­ging while styling your images with class­es such as “right,” “left,” and “cen­ter,” what hap­pens when you switch to a theme which expects images to be marked up with “imgright,” “imgleft,” and “img­cen­ter” while not using the style you’re used to? With one click to switch your theme, all of your old posts are now left with unstyled images.

Some themes offer spe­cial class­es for right- and left-aligned pull-quotes; some give us spe­cial class­es for down­load links, alerts, high­light­ed text, and so on.

Switch­ing your theme becomes a much more time con­sum­ing task as you must then make sure all of the class­es you have used in your posts are present in your new the­me’s stylesheet and that they are styled to match the new theme.

Would it be too much to ask for a set of stan­dard typo­graph­i­cal and image han­dling class­es for Word­Press themes? Not only would theme com­pat­i­bil­i­ty (with your post­ed con­tent, not Word­Press itself) be vast­ly improved, but many styles would be infused with loads of new class­es that add pizazz to your posts’ content.

How much fluff’s enough?

Themes should not con­tain — or at least should not out­put — unused or emp­ty markup. If you want to add sup­port to your theme for Adsense ads, that’s fine; how­ev­er, unless users specif­i­cal­ly insert Adsense code into your pre­pared markup, that markup should not be out­put. Why waste band­width and dilute the con­tent of users’ blogs sim­ply because you want­ed to add a bit of flex­i­bil­i­ty to your theme?

Themes for Word­Press should be con­tent-cen­tric, with markup that reflects that. Any­thing else sim­ply reflects poor­ly on not only that blog author, but Word­Press as well, in my opinion.

Remove your­self from your themes

More than once I have down­loaded, installed, and acti­vat­ed a theme only to find that my blog con­tained infor­ma­tion about the author of theme as if he or she was blog­ging on my blog; once it con­tained the theme author’s pic­ture. I’ve even found some that con­tained the con­tact infor­ma­tion for the theme author. Either leave such infor­ma­tion blank (and cus­tomiz­able, keep­ing the pre­vi­ous point in mind about out­putting extra­ne­ous markup) or do not include it at all.

Themes should be as “set it and for­get it” as pos­si­ble, so please leave the rem­nants from your own blog out of your released themes. This includes badges, Flickr streams, and so on.

Fan­cy head­er images? Let us cus­tomize them!

It’s very sim­ple: Can we please have source files for the head­er image(s) you include in your themes? And if we can, will you please make sure that the source file actu­al­ly match­es up with the head­er image in use? In one cir­cum­stance, I found that the source file was­n’t a source for the actu­al head­er image, but for the whole top por­tion of the blog design itself. So rather than replac­ing a back­ground image and some text, the image had to be sliced up and a back­ground lay­er cut into it; the thing nev­er did turn out pix­el-per­fect, but it worked after much work by my dear wife.

Those are my com­plaints for right now. I’m sure I have more that I just can’t recall at the moment. Do you have com­plaints? Or do you per­haps know the rea­sons why the things I’m com­plain­ing about above are the way they are? I’d love to hear from you, so drop a comment!

Theme design­ers: Don’t get me wrong, I love a great deal of the themes I have seen. I just think that the avail­able themes can be so much bet­ter, in terms of ver­sa­til­i­ty, acces­si­bil­i­ty, and even usabil­i­ty. I hope you can agree (on at least some of the above, anuyway :).


Posted

in

by

Tags:

Comments

One response to “Seven Things I Hate About WordPress Themes”

  1. Glen Avatar
    Glen

    excel­lent post. I was on the verge of hat­ing word­press for ever before find­ing a theme that worked with my site. It took me two days of workig to find one. Should be guide­lines for pub­lish­ing themes.

    glen

Join the Discussion

Your email address will not be published. Required fields are marked *

Use your Gravatar-enabled email address while commenting to automatically enhance your comment with some of Gravatar's open profile data.

Comments must be made in accordance with the comment policy. This site uses Akismet to reduce spam; learn how your comment data is processed.

You may use Markdown to format your comments; additionally, these HTML tags and attributes may be used: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Rick Beckman