How It Is

What Themes Get Wrong

There are things themes do that drive me up a wall.

I neither create nor review themes. I can fix a theme and edit one and hack one, but I don’t design them because I don’t visualize that way.

But boy do I see a lot of themes doing things in a way I can only describe as wrong.

Packaging and Requiring Plugins Packaging and Requiring Plugins

A lot of themes do this, and I can understand why. If you make a theme that’s meant to be a store, then of course you want it to be used with an ecommerce plugin. That makes sense. But then we have to think about the drama of Revslider or TimThumb and we have to question the themes that throw every feature into their code. Part of development is maintenance. This is an accepted responsibility and, in the case of plugins, we’re all used to upgrading them for maintenance. The same isn’t true of themes. People hate upgrading their themes, and it’s the fault of themes themselves, doing things wrong.

Top ↑

Forcing Users to Edit Files Forcing Users to Edit Files

The first week of February I lost my mind at a theme. I had found a user who had run into a mod_security error. They were trying to edit their theme via the WordPress theme editor and hitting save tripped the scanner. Why? The code in the functions.php file was phrased in a way that spooked the scanner. We walked her through SFTP, which worked, and I helped review the security rules to see if we could safely change them. But then I asked her why she was editing the files directly.

She wanted to edit her footer, to remove the ‘powered by WordPress and Theme’ line, and the only way was to edit the file.

That couldn’t be right, I shouted at my screen, but I tested and used the theme and was stunned. Yes. The theme was written in a way that the footer wasn’t editable unless you could code and use a hook to unset the action and make a new one. Even just a simple child theme wouldn’t help because the footer was handled in a function and not footer.php

No wonder users edit themes. But then it got worse.

Top ↑

Forgetting About Cache Forgetting About Cache

The top line in the header.php was a forced setting to create a new PHP session. There are a few problems with this. In many cases, having PHP sessions causes a cache to not serve cached files because the forced session tells it that the particular visitor is meant to have a unique sessions and its trying to honor that. The other common situation is that the first person makes the cache with their unique data, and all subsequent visitors get that cached data. Neither is desirable.

Why do people do it? I presume because when they built their features, they wanted to make sure each user got an individual view. But sessions are a cheap and dirty way about it. Sadly so are cookies, which a cache will either ignore in order to serve cache, or honor and slow a site down.

People remember to test a theme for speed and features, but so often they forget to test for cache.

Top ↑

Un-WordPress Designs Un-WordPress Designs

When a theme makes its own custom interface, it’s harder for users to know what to edit and where. It’s the kind of cognitive dissonance that happens when you’re reading a book or watching a tv show and suddenly everything feels wrong. Like if Harry Potter and Dolores Umbridge started dating. Right. That’s how uncomfortable it is to see a theme with its own custom design for the admin pages.

Let WordPress be WordPress.

Top ↑

Accessibility Accessibility

I don’t meant on the front end. I mean did you know that there are very few themes that, on the back end, are fully accessible to the blind? It’s just not something people think about and it’s the worst thing a theme can do to the world. You may think that only a small part of the world is blind and you may not worry too much about such a small potential user base. But look back to the previous point. The less you design like WordPress the worse it is for users. All users.

Top ↑

What Do You See? What Do You See?

What drives you batty?

15 replies on “What Themes Get Wrong”

You’ve hit most of what annoys me about themes when I work with them. That said, I wanted to expand upon what you said in the first section about requiring/packaging plugins.

On the one hand, I can somewhat understand when a theme requires a plugin (though, in 99.9% of cases, that alone drives me batty). That said, there is absolutely no reason that plugin should be packaged with the theme; it should be something the theme requires the user to install from the repository.

Unfortunately, even when I see themes that get that part of it right, they often fall down in testing for those requirements. If the plugin is not installed or active, the theme completely breaks (in many cases, with a fatal error, since the theme attempts to use a function that doesn’t exist).

If you’re going to write a theme that “requires” the use of some sort of plugin functionality, you absolutely need to avoid packaging that plugin with your theme, and you absolutely need to test for that functionality before trying to use it.

Outside of that, and the other points you’ve already made, I don’t see too many other things that truly bother me about themes anymore. Thankfully, it’s pretty rare for me to see any of the items that used to really cheese me off (including jQuery the wrong way; not including wp_head(), wp_footer() or body_class(); etc.). Hopefully we can slowly work toward moving theme developers away from these new annoying habits.

Themes that force their own version of jQuery to be loaded. The amount of times that I have to remove this in themes while providing support for my plugin is ridiculous.

@Nick: Ditto. I finally started telling people that if their theme was doing things that wrong, I wasn’t going to fix my plugin. If I’m doing it wrong, yes, I will fix asap. But I won’t make my code account for other people doing wrong. I’ve rejected plugins when people want to enqueue their own jquery just in case a theme removed it.

We cannot keep saving people like that! They’ll keep using the bad code if we let them!

What drives me crazy are themes designed with the idea that they somehow need to support every single thing that WordPress allows for. For example, there’s no reason every theme should support widget areas, comments, or even custom menus.

The truth is, most of these features tend to be either copy pasta design or barely designed at all. Very little or no deliberate design thought goes into these various sections. Especially into specific widgets.

One of the biggest pains about WordPress themes, Premium Themes that is, for me is their sales model. (This applies to many Premium Plugins as well, but I’ll address this as themes)

I frequently acquire new clients who need work done on their sites… Or they’ve gotten hacked (with no backup) and the site needs to be effectively reconstructed with known good files.

Often, the WP developer who originally made the site has used a premium theme… We’re fine so far… There are some great premium themes out there!

But, say the WP developer has taken advantage of the Theme maker’s (or distributor’s) developer or bundle license… And that can be a great deal for the WP developer.

The problem is that the license for using (i.e. downloading a new copy) and for updating the theme is (almost always) owned by the WP developer and the owner of the site for which the premium theme has been used has no standing with the folks who originally sourced the theme.

If the original WP developer is out of the picture, for whatever reason, the site owner is out in the cold and if I need a clean copy or an updated version of the theme to fix their site, the site owner is on the hook to purchase new rights to the theme for themselves… effectively paying again for something they have already purchased. They tend not to be pleased!

All too often the WP developer has not ever raised this possible scenario, nor likely mentioned if the theme license has a yearly renewal for support and updates and who is responsible for the payment.

I have contacted some theme developers and explained the problem and they have graciously sent me the updated theme, pro bono. I hate to say it, but they are the exception.

I remember tapping out this rant to Josh Lobe, the developer of the WP Edit Pro plugin, and to his credit, in his plugin’s license authentication my developer’s license is entered so that should I get hit by a truck tomorrow (OK, I’m in Montana… Maybe a snowmobile LOL) my client will continue to be able apply updates going forward. Nice, eh?

Myself, when I make a WP site for a client, I do my best to subscribe to the “run over by a truck” way of doing things. If the site needs something premium, I purchase it in their name so that they have the rights to it and also let them know if there will be additional costs down the road for upkeep. It will probably cost a little more and I will probably make a little less, but the way I see it, I provide a service to my clients. It’s my job to make them happy with my work, even if a truck runs me over.

Wouldn’t it be nice if theme and plugin developers, for that matter WordPress site developers as well, kept the end user in mind when they make things?

I tend to take a similar approach to premium plugins & themes, Ken. I give my clients the option of using my license (assuming I have an unlimited license for the product), but I warn them multiple times that that means they are tied to my license and, if I fail to renew it at any point in time, their product may stop working properly. I then encourage them to purchase their own license.

I also always try to make sure I send original copies of things (like premium themes) to the clients, so they have them, but they almost never keep those copies.

One very popular theme vendor has a parent theme for which child themes can only be modified with the use of a proliferation of poorly documented hooks. The simplest edits are difficult to do without grepping the source and sinking significant time to comprehend the poorly documented code. It slows me down, which ends up costing clients more.

The product family has grown in popularity, partly due to effective marketing. But as they company have grown, their support for developers hasn’t: the documentation has remained in the same malnourished state for years. I find this particularly frustrating.

The only way to speed up is to spend significant time becoming deeply familiar with the product family. I’d honestly rather be spending time learning wordpress.

I’ve encountered similar problems outside of that the world of that particular vendor: themes and templates doing unorthodox things. Sometimes it’s because good php programmers aren’t familiar with the the API, so they end up reinventing the wheel. (I’ve seen this more on bespoke wordpress themes.)

@Sunil: My two favorite theme suites are both well documented with regards to their hooks. But yeah, there’s a lot of weird reinventing of the wheel there with that stuff. And some of it makes sense.

At least with StudioPress, my license gives me access to docs that let me do everything.

Theme bloat is my current pet peeve. I don’t need 10 slideshow options, 20 sidebars and 30 page templates all wrapped up into a theme that advertises “the last theme you’ll ever need!” That’s insanely overwhelming. Give me a simple, purpose built theme any day. 🙂

Comments are closed.