Just to disclose the truth: I don’t really hate themes. But as a plug-in developer with tens of thousands of users, what I hate is undisclosed conflicts – and themes are a big part of that problem. We’re talking about tech support.

The other day, Pippin Williamson posted this Tweet:

Why shouldn’t a theme developer change the uploads directory? Because it’s a theme. Themes serve a specific purpose: they change the look and feel of a site. To a limited degree, that can also include behavior. But it should be fairly predictable what kinds of things a theme will do.

When I’m providing tech support, one of the things I look at is what other plug-ins a user has installed. Generally, I can make a pretty good guess what kinds of things a plug-in is doing just from the name — I can guess what areas of WordPress it’s filtering, what actions it might use, and what kinds of things it might be changing that could impact my own plug-in. I won’t know everything, but it’s a great starting place.

But themes are a totally different story.

When I see a theme, and it’s a WordPress.org theme, hosted in the repository, I know a few things:

  1. It’s using the standard WordPress scripts enqueued in a standard way.
  2. It’s using modern WordPress standards of coding and functions.
  3. It’s been tested in WP_DEBUG mode.
  4. It isn’t adding crazy new functionality.

I know that a WordPress.org theme is being used to style the site, and any conflicts are almost certainly limited to a JS collision or CSS (Cascading Style Sheets) override.

When I see a premium theme, however, all I know is that it could be doing anything — because it hasn’t gone through the rigorous testing that WordPress.org requires for a theme. It might be a horrifying network of deprecated functions. It might be massively insecure. It might be changing the uploads directory location, setting up payment gateways, connecting to Twitter via OAuth, or any number of things that I can’t possibly predict from the name of the theme.

I also know that this person paid for their theme, and may have spent a lot on customizing the theme with their brand — are they going to redesign their site with a new theme because of a plug-in conflict? Probably not. Instead, they just won’t use my plug-in.

Different premium brands have different expectations — and I won’t go out and say that *all* premium themes exhibit these characteristics — but there are a lot of premium shops, and I most definitely don’t know them all or what I can expect from them.

I can’t count the number of premium themes I’ve installed for testing, then needed to disable debugging for them to work.

Themes are for design. Plug-ins are for functionality. There’s a reason for this — and it saves a lot of headaches in support!

Your premium theme doesn’t need to follow the WordPress.org guidelines – but it should damn well follow the basics – use the WordPress script resources, don’t use deprecated functions, and use WP_DEBUG in development. Please.