Poor Practices Previously Encountered in WordPress Themes

January 25, 2016

Categorized: WordPress
Tagged: ,

I haven’t worked with an abundance of other people’s themes so I’m in no way an expert. I’d say I’ve played with somewhere in the neighborhood of 50 premium, paid themes built by other people. It doesn’t give me a huge range of experience to see all that can possibly go wrong… but I’ve seen a fair amount!

Pre-Made Themes

Why Pre-Made Themes Can Have Problems

Before launching into the tirade, I figured it was only appropriate to say something about pre-made themes. After all, they’re terrible, the worst, inexcusable, etc. etc. etc. right? Some marketplaces are better than others, some theme studios are okay — but pre-made themes are always a waste of time for the experienced web developer.

Not really — at least, I don’t believe that.

Yes, many have problems with “doing everything all-at-once.” Many have problems with defining lots of custom post types I don’t use, and lots and lots of options I prefer to avoid. Some load lots of unecessary scripts and plugins, and are nightmarish to optimize.

And sometimes — yes, nightmares happen. I’ve personally purchased a theme that turned out not to be responsive, as well as a theme so buggy I had to return it, despite its high sales. I’ve also had issues with data importing and exporting, broken or neutered tools for theme option back-up.

But many of the issues I’ve found were silly, too. It’s tough to fault a theme developer for failing to end a HTML comment properly on a sub-$100 theme.

Splintering

There’s another drawback — any time you pick up a new theme. Different themes are made by different developers. That means you have to figure out how the wheel was built in many instances. Everyone does it differently, and it can be time-consuming and an exercise in frustration.

The same thing goes for support — there’s no consistency in the way developers offer support (and there couldn’t be, really, as they’re all independent!). Some developers want you to comment on a forum itself. Some want you to go to their website and register for a specialized ticketing system. Some want you to e-mail.

It’s time-consuming to register/manage usernames for all of these different support sites, and remember how to get support when you need it. You shouldn’t need to pick up your theme’s documentation to remember how to get help — but because every theme seller is different, you have to.

Retirement

Themes do stop getting updated or are discontinued. What happens to an out-of-date and vulnerable WP? Nothing good. Yet in these situations it’s seriously not possible to tell the client, “oh you could get hacked in the future so we need to change your whole theme.”

It’s also incredibly painful to pick through a theme in search of vulnerabilities, considering the prior point. Every theme is different. At least when you’re using the same base framework for all your sites (like Underscores) it’s a little less painful to update everything — there’s a bit more consistency. Of course, we’ve all experienced the pain of going back and modifying our own older code… so no matter how you slice it, updates can be painful!

Why Pre-Made Themes Are Still Useful

Despite the problems, that doesn’t mean they are wholesale terrible. Most of the problems listed above? They are problems you can find anywhere, they are not exclusive to one marketplace by any means. I don’t think branding any marketplace as a whole “bad” is at all fair.

Even if they have problems, pre-made themes work for some clients in some financial situations. There are plenty of times when a client doesn’t want to pay a ton of money for a totally custom theme. When done right, from-scratch custom themes — even built from Underscores — are not a cheap thing.

Basically — if the client isn’t willing to pay for custom development prices but still wants a new website, a pre-made theme can suit their needs just fine, and provide a relatively quick money-maker for you. I’m not going to spend the time to make a wonderful Underscores-based custom theme for them, but I’m also not going to walk away from their money, if they’re willing to pay the appropriate amount.*

It is easy to dismiss these clients out-of-hand, and if you’re at that point in your career where you can, more power to you. Many of us aren’t quite there yet, and leaving quite so much money on the table doesn’t appeal. Pre-made themes provide a way to bridge the gap for those clients and developers. Yes, you can totally argue it’s ruining code/web/whatever, but people still need to eat — so the practice isn’t going away anytime soon, I don’t think.

* This is one thing to beware. It’s important to avoid undercutting yourself because you’re “just installing a theme.” Some clients are more savvy than others, and may be aware of the DIY in using a pre-made theme. That doesn’t mean you have to accept their lowballing — if you’re a WordPress developer with even just HTML, CSS, and PHP customization skill, a lowballer can find someone who only installs themes and changes theme options, who will be more within their budget.

… But Why I’m Still Avoiding Them, Where Possible

I think most of these things are personal preference rather than actual problems, so they’re separate from the above:

  • I don’t use many features. I never use shortcodes or custom post types bundled with themes, because I know when I change the theme they will break. It’s also easier to troubleshoot problems with totally separate solutions — I prefer being able to disable a plugin to see if something’s broken than sorting through a theme’s gigantic includes/ folder with twenty different functions.php files. I also prefer to avoid theme-bundled sliders, because they also break even without a theme change…
  • Many of the features the themes do provide, I will prefer another solution. The theme is often optimized to work with the pre-determined solution, and my preferred solution doesn’t integrate so well.
  • Page builders. I hate page builders. It might be irrational and I might be hurting myself but I really hate pagebuilders. And so, so, so many pre-made themes come bundled with pagebuilders. They are usually whitespace sensitive, so you end up with a massive blob of impossible-to-edit gunk if you’re not using the building or visual mode. All of them are different, requiring a harder gear shift when editing different sites. Most of them feel painfully slow to me when editing on their interfaces; even though I know it’s probably not true, I feel I’d be so much faster just writing the dang code myself. I also have zero evidence for this, but I suspect you could cause some real optimization/speed/server problems with them (in extreme circumstances, such as thousands of page builder codes on one page or execptionally poor shared hosting).
Example of the gunk and mess that a page builder produces on the text editor.
Example of the gunk and mess that a page builder produces on the text editor.

The Poor WordPress Theme Practices

Pre-Made Theme Mistakes

These are mistakes I’ve found in pre-made themes I’ve purchased.

Use of Theme-Tied Shortcodes

Shortcodes that are connected to the theme are a problem. Obviously, when they’re embedded into the theme, all of these shortcodes break when the theme is changed. No bueno. I’ve had to edit 50+ pages of sites and hand-remove all the shortcodes — because they appeared in different ways and different contexts, MySQL queries were more dangerous/more trouble than they were worth.

I personally don’t mind structural shortcodes when they are plugin-based. I almost always write a custom plugin file with custom functionality. I also like Column Shortcodes, but I do make some CSS changes by dequeueing the default stylesheet and adding in my own. I use different responsiveness, and I adjust it so that the padding for the grid is built into the CSS rather than declared with the plugin’s interface.

Use of Theme-Tied Custom Post Types

I’ve seen this in custom-developed sites and in a lot of the ones bought through marketplaces, too. This one’s usually not too bad to fix when changing the theme, usually. Just a matter of figuring out where the post types are declared and what kinds of functionalities tie into those post types. This can be a little more painful if the post types were created through plugins, and even more painful when created through a theme-tied plugin for creating custom post types.

When your custom post types are tied to your theme, obviously, when you change the theme… your custom post types all disappear. This is usually not a good thing, especially when the custom post type is, for example, the services offered by a firm/office/doctor, or the items on a restaurant’s menu. These things should probably persist through theme changes.

On the other hand, a good example of a custom post type that could be tied to themes are theme-based appearance things, like sliders or images that are tied to themes (not tied to pages, etc.). But again, as aforementioned, I don’t prefer theme-bundled solutions in most cases.

Massive Do-it-All Templates

One thing that’s a bit more subtle is when a theme uses a lot of customized templates and options — instead of hooks/filters or even breaking it up into different files. It might bet better, instead of 50 lines dedicated to getting author info in a post template that’s already 350 lines long, to just break that up into a separate file and do an include. It makes it easier to edit the templates and harder to get lost in them.

Sample Data

Some themes are very rude. When you activate them, these themes decide — for some reason — that you must want their sample data. They create 150+ pages (no, seriously, there were over one hundred and fifty) and add dozens of big stock images to your library without asking.

This is inexcusable in my opinion. Even if it’s “only minutes” to delete this data… I didn’t want it there in the first place. And plenty of other themes manage to offer import for their sample data. With these less-intrusive options, I really don’t see why a theme should ever add stuff to your WordPress without you asking for it.

Documentation: Hidden or Locked

This one is not a technical problem, but it’s really annoying. Some theme developers do not publicize their help documentation — you either get it bundled with your download, or you have to sign into a certain account on their website to access the documentation. For obvious reasons, this can be painful. Clients often lose track of their login information; it’s hard enough pulling site and hosting account logins from them. Forget about other sorts of logins. If the developer has locked the theme documentation behind a wall, or only offers it with download — it’s harder to support that theme, obviously.

Developer Mistakes

These were mistakes I didn’t find in pre-made themes, but in sites others had developed prior to to my adoption of those sites.

PHP in Widgets

This one was just a bit scary. I went to edit a theme and found there was PHP and MySQL queries in the widgets. I think in general it’s probably better to write a shortcode, or even a custom widget, than place PHP code directly in widgets. Although it didn’t seem to break the whole site and just threw a PHP error for that widget in particular, it was still harrowing to edit! I also believe it’s not great practice to allow PHP code to be passed through in these places — there’s a good reason WP doesn’t allow it by default..

It also makes things more complex for someone who is maybe good at the WordPress administration panel, but isn’t so good at PHP or coding. They’ll look at all that widget code and squint their eyes at it. It restricts them from editing widget-based content, which is exactly where you should probably avoid complex code. Someone editing widgets might not know how to even access the site via FTP to edit templates and PHP.

Theme Shortcodes

I edited a theme where the prior developers used [backtotop] — a theme-included shortcode — on every page to add a back-to-the-top button. The fix was a simple MySQL query to remove them, but it was a really odd thing to encounter. Fixed-position buttons are super easy to add to the footer, and if you want something in a particular place, it’s possible to just add it in with templates or hooks. Either way seems a better solution than a shortcode.

Conclusion

Unfortunately… the problems I listed aren’t problems you’re typically going to find before selecting a pre-made theme. Many of them are only visible once you’ve installed the theme and gotten it up and running on your WordPress. So there’s not a lot you can do to prevent these issues in pre-made themes you buy, other than picking trusted developers.