Seven Things I Hate About WordPress Themes

You’ve just installed WordPress, and you head on over to the Theme Viewer, a repos­i­tory of 1,500+ WordPress 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 WordPress 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 tower 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­eral of my own, with sev­eral for oth­ers as well — and the one thing that has caused the most headaches is man­ag­ing themes. I’m mostly 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 spirit of WordPress Kvetching, here are my top com­plaints regard­ing WordPress themes, in no par­tic­u­lar order.

Pages sup­port, or lack thereof!

WordPress’ built in sup­port for sta­tic pages — includ­ing sta­tic 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­tic website.

One of the rea­sons why I ditched solu­tions such as Drupal or Xoops is because of the overly com­pli­cated method of orga­niz­ing sta­tic 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. Overly clut­tered admin­is­tra­tion pan­els didn’t make those tasks overly sim­ple, either. WordPress offers an incred­i­bly user-​​friendly and pow­er­ful solu­tion for build­ing such sites.

But I have yet to find a theme that works with a richly struc­ture site full of sta­tic Pages! At best, a top level list of pages is added to the header 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 level 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­pected 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 related themes. However, things aren’t much bet­ter if sub-​​subpages or sub-​​sub-​​subpages, etc., are used.

Ideally, on the index page, archives pages, blog pages, etc., a top level list of Pages should be pre­sented to users. When vis­it­ing any of those Pages, all of the des­ti­na­tion Page’s sub­pages should be listed; 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., other Pages on the same level and in the same branch of the Pages heirar­chy) and to all of its subpages.

Such a setup cer­tainly presents some design chal­lenges, but it would make putting together richly struc­tured WordPress sites so much easier.

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

Required plu­g­ins and plu­gin compatibility

I can think of very few instances where a plu­gin 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 WordPress as it is, should con­tain the code nec­es­sary to emu­late the plugin’s func­tions, or should include any required plu­g­ins within the pack­age. However, we shouldn’t be asked to change the func­tion­al­ity of a WordPress instal­la­tion in order to change its appearance.

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

Overworking index.php

I real­ize that a basic WordPress theme can be built rely­ing upon index.php for every­thing from archive pages to search results, but styl­is­ti­cally this results in a very bland look­ing site. No mat­ter how one browses — archives, cat­e­gories, the index page, or even tags if a tag­ging plu­gin 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 overly com­pli­cated file.

So why not make use of WordPress’ extremely 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 included for com­plete­ness’ sake, and while they very much may mimic index.php, sub­tle touches 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 other 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 WordPress users out there, did you know you could apply a cus­tom style to, say, a cer­tain category’s archive? Say your cat­e­gory ID 5 archives should be styled dif­fer­ently than your other 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 classes 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 classes for right– and left-​​aligned pull-​​quotes; some give us spe­cial classes for down­load links, alerts, high­lighted text, and so on.

Switching your theme becomes a much more time con­sum­ing task as you must then make sure all of the classes you have used in your posts are present in your new theme’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 classes for WordPress themes? Not only would theme com­pat­i­bil­ity (with your posted con­tent, not WordPress itself) be vastly improved, but many styles would be infused with loads of new classes 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 empty markup. If you want to add sup­port to your theme for Adsense ads, that’s fine; how­ever, unless users specif­i­cally 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 wanted to add a bit of flex­i­bil­ity to your theme?

Themes for WordPress should be content-​​centric, with markup that reflects that. Anything else sim­ply reflects poorly on not only that blog author, but WordPress as well, in my opinion.

Remove your­self from your themes

More than once I have down­loaded, installed, and acti­vated 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.

Fancy header images? Let us cus­tomize them!

It’s very sim­ple: Can we please have source files for the header image(s) you include in your themes? And if we can, will you please make sure that the source file actu­ally matches up with the header image in use? In one cir­cum­stance, I found that the source file wasn’t a source for the actual header 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 layer cut into it; the thing never did turn out pixel-​​perfect, 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­ity, acces­si­bil­ity, and even usabil­ity. I hope you can agree (on at least some of the above, anuyway :).