Seven Things I Hate About WordPress Themes

You’ve just installed WordPress, and you head on over to the Theme Viewer, a repository of 1,500+ WordPress themes, to find the perfect design for your fledgling site. You find a few that have irresistible screens shots, download them, and upload them to your WordPress installation. Along the way, you notice that the files contained in the themes vary by quite a bit. Some themes are amount to ~200 kilobytes total, others tower over a megabyte. And upon activating the themes on your site, you notice that some are much more flexible than others.

And others take days of tweaking just to make it suitable; you wonder how they were ever released into the wild in the place!

I’ve managed around a dozen blogs over the past two years — several of my own, with several for others as well — and the one thing that has caused the most headaches is managing themes. I’m mostly curious if others have experienced these same issues and so have the same complaints as I do so that I’ll have that bit of comfort when trudging through future themes; I’m also hoping that you theme designers out there will hear some of these complaints and work toward resolution.

So, in the spirit of WordPress Kvetching, here are my top complaints regarding WordPress themes, in no particular order.

Pages support, or lack thereof!

WordPress’ built in support for static pages — including static pages, page ordering, etc. — is in my opinion one of its most notable features. Using Pages, you can take a simple blog site and build up around it a rich, multileveled static website.

One of the reasons why I ditched solutions such as Drupal or Xoops is because of the overly complicated method of organizing static content; individual menus must be built and arranged, content must be placed into just the right module or section for it to show up, and so on and so forth. Overly cluttered administration panels didn’t make those tasks overly simple, either. WordPress offers an incredibly user-friendly and powerful solution for building such sites.

But I have yet to find a theme that works with a richly structure site full of static Pages! At best, a top level list of pages is added to the header or sidebar, but what if there are subpages? How do you expect visitors to find a subpage that isn’t linked to?

Or perhaps that top level menu of Pages isn’t set to ignore subpages, and so on sites that do have subpages, the style will break as unexpected content is forced into an otherwise attractive Pages menu.

As of yet, the best implementation of Pages I have seen can be found in K2, and presumably most related themes. However, things aren’t much better 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 presented to users. When visiting any of those Pages, all of the destination Page’s subpages should be listed; clicking any of those subpages should link not only back to the parent page, but also to its “sibling” pages (i.e., other Pages on the same level and in the same branch of the Pages heirarchy) and to all of its subpages.

Such a setup certainly presents some design challenges, but it would make putting together richly structured WordPress sites so much easier.

And I admit, this is probably my #1 complaint concerning WordPress themes.

Required plugins and plugin compatibility

I can think of very few instances where a plugin would be required to use a theme, and I’m not even sure how valid those circumstances are. Your theme should work with WordPress as it is, should contain the code necessary to emulate the plugin’s functions, or should include any required plugins within the package. However, we shouldn’t be asked to change the functionality of a WordPress installation in order to change its appearance.

Further, while I’m all for themes having built-in compatibility with select plugins, make sure that you place conditional statements around the plugin code so that if the plugin is not installed, its related theme code is not output. A simple function_exists() conditional wrapping the plugin function call & related stylistic elements is enough. Don’t just wrap the plugin function either; there is no reason to output the container elements if there’s nothing to fill them.

Overworking index.php

I realize that a basic WordPress theme can be built relying upon index.php for everything from archive pages to search results, but stylistically this results in a very bland looking site. No matter how one browses — archives, categories, the index page, or even tags if a tagging plugin is installed — it all looks the same. I realize this can be overcome by using conditionals in index.php, but that creates an overly complicated file.

So why not make use of WordPress’ extremely versatile theming engine? Files like 404.php, search.php, archive.php, single.php, page.php, category.php, author.php, and home.php should be included for completeness’ sake, and while they very much may mimic index.php, subtle touches could be made to each — such as including author information in author.php or the use of the_excerpt() as opposed to the_content() in the various other files — which not only make them stand out as different from the index page, but also tend to make a site more interesting and usable.

And for you WordPress users out there, did you know you could apply a custom style to, say, a certain category’s archive? Say your category ID 5 archives should be styled differently than your other categories; just create 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 blogging while styling your images with classes such as “right,” “left,” and “center,” what happens when you switch to a theme which expects images to be marked up with “imgright,” “imgleft,” and “imgcenter” 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 special classes for right- and left-aligned pull-quotes; some give us special classes for download links, alerts, highlighted text, and so on.

Switching your theme becomes a much more time consuming 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 standard typographical and image handling classes for WordPress themes? Not only would theme compatibility (with your posted content, 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 contain — or at least should not output — unused or empty markup. If you want to add support to your theme for Adsense ads, that’s fine; however, unless users specifically insert Adsense code into your prepared markup, that markup should not be output. Why waste bandwidth and dilute the content of users’ blogs simply because you wanted to add a bit of flexibility to your theme?

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

Remove yourself from your themes

More than once I have downloaded, installed, and activated a theme only to find that my blog contained information about the author of theme as if he or she was blogging on my blog; once it contained the theme author’s picture. I’ve even found some that contained the contact information for the theme author. Either leave such information blank (and customizable, keeping the previous point in mind about outputting extraneous markup) or do not include it at all.

Themes should be as “set it and forget it” as possible, so please leave the remnants from your own blog out of your released themes. This includes badges, Flickr streams, and so on.

Fancy header images? Let us customize them!

It’s very simple: 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 actually matches up with the header image in use? In one circumstance, I found that the source file wasn’t a source for the actual header image, but for the whole top portion of the blog design itself. So rather than replacing a background image and some text, the image had to be sliced up and a background 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 complaints for right now. I’m sure I have more that I just can’t recall at the moment. Do you have complaints? Or do you perhaps know the reasons why the things I’m complaining about above are the way they are? I’d love to hear from you, so drop a comment!

Theme designers: Don’t get me wrong, I love a great deal of the themes I have seen. I just think that the available themes can be so much better, in terms of versatility, accessibility, and even usability. I hope you can agree (on at least some of the above, anuyway :).

One thought on “Seven Things I Hate About WordPress Themes

  1. Glen says:

    excellent post. I was on the verge of hating wordpress for ever before finding a theme that worked with my site. It took me two days of workig to find one. Should be guidelines for publishing themes.

    glen

Join the Discussion

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

Comments must be made in accordance with the comment policy. Use your Gravatar-enabled email address while commenting to automatically enhance your comment with some of Gravatar's open profile data.

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>