Imagine that someone starts a shop with a nifty WordPress theme, going for months with that theme, and then wants to change it. Now, imagine that all her sliders, widgets and even products vanish from the website. Imagine her frustration. Would you like to cause that kind of disappointment?

There's a concept called "plugin territory" which specifies the things theme developers should leave out from their themes. In this article, I'm going to go over the basics of this concept.

An Introduction to Plugin Territory

Let's start off easy: The basic mindset behind the concept of "plugin territory" is to leave out things that prevent users from switching themes. This means that you should make themes that are switchable when you stop developing the theme or the user needs (or wants) to change your theme. And you have to keep in mind that a WordPress theme should be about changing the looks of WordPress, instead of how it works.

If you've skimmed through the subheadings of the rest of this article, you probably have a clearer idea of what "plugin territory" is: You can't change the WordPress core, use shortcodes or sliders, create custom post types, taxonomies or meta boxes, provide functionality that benefits website SEO and things like that. 

Why? Because the users of your theme won't be able to switch themes without losing their custom post types, sliders, shortcodes, SEO settings and such, which will cause frustration and the users will be faced with two options: ditch your theme and start the whole website from scratch, or give in and keep using the theme with compulsion.

The Make WordPress blog has a page dedicated to "plugin territory" which covers all the basics with just a few words, but I believe we can elaborate the topic with what we see in the WordPress community and the etiquette of making themes.

Things to Leave Out From Themes

Now that we've established what "plugin territory" means, we can start applying the concept with some examples. Some expressions might seem incomplete, controversial or even wrong to you, so feel free to contribute to this section with your comments on utilizing the concept of "plugin territory".

Let's begin!

Core Modifications & Replications

This one's a no-brainer: Your theme shouldn't alter or replicate core functionality. That is, you shouldn't abuse the powers of the extensibility of WordPress by limiting the functionality of WordPress, and refrain from creating new functions when core functions can do the same work.

Take feeds, for example: You want to make a magazine theme for publishers that will request money from their readers for the content. WordPress has the "RSS feed" functionality, so it might seem like a good idea to make your theme disable the "feed" feature altogether... except it's a very bad idea. 

First off, why do you assume that the users of your theme would want to disable RSS feeds anyway? Second, there are plenty of plugins that can do the deed, meaning you can recommend such plugins and leave the decision to the users. (Here's a tutorial of mine about how to recommend or even require plugins: "Using the TGM Plugin Activation Library in Your Themes".)

Another good example on this issue would be splitting the parts before and after the <!--more--> tag. You don't have to use the explode() function to split the two parts, because there's a function for the deed in the core: The get_extended() function does the job pretty well. (I've got seven more gems for you in this tutorial, if you're interested.) Checking the core functions before writing your own is a time-saving, clever thing to do.

Shortcodes, Sliders and Widgets

Theme developers usually get confused about plugin territory when you say that some design elements fall into the territory as well. And they're right to get confused: How can a slider be in plugin territory, when sliders are one of the most important parts of today's cookie-cutter corporate websites?

Here's how: If a user gives up your theme, they will have to give up the slider(s) as well. As in the example I mentioned at the very beginning of this article, it will create frustration. And the same goes for shortcodes and widgets: Nobody should have to give up drop caps, social media share widgets or Twitter feeds when they stop using your theme. They all have to be served in the form of plugins so your users won't have to create new slides from scratch or clean old, non-functional shortcode bits from their content.

Custom Post Types, Taxonomies, & Meta Boxes

In the case of sliders, custom post types come into play too: In most themes, slides are a custom post type, and if that custom post type is lost when the user activates another theme, the data will be lost. Of course, the case of sliders is yet another example, but it's a very good example on custom post types being in plugin territory.

The same goes for custom taxonomies and custom meta boxes. You can't break the users' contents if they choose to give up your theme, so custom taxonomies should be served as plugins as well. Custom meta boxes are a bit different: If the content of the meta box alters the look (like radioboxes to change post styling), it's the theme's own functionality; but if meta box content changes post content (like a movie review table), it should be served as a plugin.

SEO Settings & Analytics

I don't want to waste your time repeating the same words: You can't drop your users' SEO ratings when they switch themes! But again, nobody will stop you if you serve it as a plugin and recommend it with the TGM Plugin Activation library.

A Special Case on Specialty Themes

About a year ago, I wrote an article titled "The Curious Case of Specialty Themes". Allow me to quote myself:

A WordPress theme must be developed to change the look of a website and avoid offering functionality embedded in its core. (...) But sometimes, a project requires that design and functionality work together. In this case, we have an exception, and the exception's name, used throughout the WordPress market, is "specialty themes".

A "specialty theme" is a kind of WordPress theme that has a very specific purpose like a crowdfunding website or a learning management system (LMS). While it can be extended with WordPress hooks (actions and filters) or redesigned with child themes, websites built with these themes would have to work with the same theme over the course of its lifetime. That's why it's not considered a "bad practice" for these themes to invade the plugin territory.

It's certainly a grey area: ThemeForest, for instance, doesn't allow invading the plugin territory even for specialty themes. I'd like to hear about what you think, too, so let's chat in the comments!

Wrapping Up for Today

As people who earn money developing with WordPress, we naturally want WordPress to grow all the time. Yet, we are the reason for its growth, so we are responsible for contributing to its continued growth. And you can't see growth in inconsistent environments, so we have to be careful managing its consistency. That's why we have to care for "plugin territory" and let plugins handle the functionality, while themes handle the visuality.

For those who are interested, we have plenty of WordPress plugins available for both purchase, use, and to study in the marketplace.

I'm pretty sure you have something to say on this topic, so feel free to share your thoughts in the Comments section below. And if you liked the article, don't forget to share it with your friends!