Extendibility is, to me, the best feature of WordPress, and helps make it the most popular content management system in the world. But when you take it the wrong way, you could accidentally make a WordPress user's life unnecessarily difficult. 

A Short Story

A couple of years ago, I was new to WordPress and I was in search of a quality WordPress theme for a client of mine. After hours of searching, I found the perfect theme. It looked perfect and it seemed to have great features: It had an awesome slider, sleek shortcodes, and a "Services" section with amazing features—the whole package!

When I installed the theme, though, I faced the ugly truth: It looked perfect but it wasn't. It seemed to have great features but it didn't. I must confess, it had a beautiful design, but the code foundation was just awful. I struggled to make it work and I managed to create a working website, but by the time I was—almost—done, a WordPress update came and made my client's website crash with the famous White Screen of Death.

It wasn't WordPress's fault, of course, it was the theme's fault. I decided to switch themes and spent another three hours finding another theme. This time, I thought of checking comments about the theme and the support forum of the vendor and confirmed that there wasn't much to worry about. I purchased the second theme, installed it with great anticipation, and... the Services section was gone. Along with the homepage slider. Along with shortcodes. Along with some of the sidebar widgets. Along with the contact form.

Moral of the story? People tend to switch themes when they don't like the one they're using, and they need their content preserved after changing themes. It doesn't necessarily have to be because of bugs or crashes: WordPress allows us to change themes, and theme authors should respect that choice.

Why Do We Need to Keep This in Mind?

You wouldn't want to leave a bad taste in people's mouths if they abandon your theme to use another one. It must be your mission to offer an excellent service to the people who buy your product, and this includes letting them switch to another theme without losing their data.

In order to accomplish this, you need to know what to include and what to avoid in the themes you craft. In this article, we're going to go over some basic rules.

What Should Be Avoided When Creating a Theme?

We need to determine what we should leave outside our theme's code base. Notice that it doesn't mean that we should give up any parts—we can still integrate cool features, but we should do it some other way. Let's see what we should refrain from including in our themes' main files.

Sliders

Sliders, whether we like it or not, are extremely popular amongst WordPress themes. I personally think that they're a bit useless, but when I work with a client to make them a website, we're almost always stuck about what to put on the homepage; and sliders usually are the best solution we find. 

Since they're so popular, it would be wise to include the feature for the users to create slides with images and flying HTML bits, but you should also think about what your users will have to do when they switch themes: Will they lose all their slides and have to build the same ones for the new theme?

Luckily, most themes are doing it right by featuring great plugins for sliders. You should do the same thing: Find a great slider plugin that's ready for commercial use, if you're going to sell your theme, and integrate it into your theme. You don't have to code it from scratch but if you do, remember to serve it as a separately installable plugin with your theme.

Shortcodes

Shortcodes are one of the best features for WordPress users, from novice to expert. But even if they help with your theme's design, they're bits of functionality and they change the behaviour of content, or create dynamic content. When users switch to another theme, they shouldn't have to clean all your [shortcodes] from their content.

As with the sliders, you should serve your shortcodes as a plugin and make it work with themes other than yours.

Custom Post Types and Taxonomies

A user creates content, decides to switch themes, and sees that their Portfolio and Staff content are gone. They're still in the database but they're inaccessible and your novice user thinks everything is gone. Would you like to get emails with very little-known insults and 1-star ratings because of that? Of course you wouldn't.

That's why you should separate your custom post types and taxonomies from your theme and offer them as—you guessed it—a plugin. There are some extremely useful plugins for creating new custom post types and taxonomies—SuperCPT is one of them. Be sure to read my tutorial on this plugin if you'd like to use it.

...and All Kinds of Functionality

I don't have to give more examples, you get the idea: Functional parts of your theme need to be made available as plugins. There's a term called Plugin Territory in the guidelines of "Make WordPress" and if you're going to showcase or sell your theme in a website that regards these guidelines (like WordPress.org or ThemeForest), you need to comply with it and serve functional bits as plugins with your theme.

The TGM Plugin Activation library is probably the easiest and most efficient way to bundle your themes with plugins. You can "require" or "recommend" plugins (from WordPress.org, inside of your theme folder or any other external website) when your theme is installed.

Wrapping Up

It's a natural instinct for WordPress theme developers to offer quality features in their themes, but you have to be careful about letting your users switch themes without any loss. And that means you have to set functionality apart from your theme's code base.

What do you think about this topic? Share your thoughts by commenting below. And if you liked the article, don't forget to share it!