Table of Contents
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.
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.
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.
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.
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.
What Do You See? What Do You See?
What drives you batty?