I know it's now the common wisdom to not build functionality into themes, as advised by WordPress, Envato, and others. This includes the likes of content types, taxonomies, sliders, shortcodes etc, to make themes as flexible as possible when used for different applications. I know I don't like downloading themes which have more functionality built-in than I need.

Suppose that a theme has been purpose-built for a client with specific needs. As much functionality as possible has been delegated to plugins, however this does create a dependency on plugins when such functionality can be part of the theme itself.

For example, I've used Pods to establish custom content types and custom taxonomies; it's been great for quickly building up these content types and their fields, but creates a dependency on Pods where it is not really needed. These ends can readily be achieved through the theme itself.

It's normally advised to not include custom types or taxonomies in themes as the themes will be less useful to other users, and would not be accepted by the WordPress theme repository. However, in my case, this theme is custom built for this client and the client's needs, and it is not intended to be used elsewhere. I also have an ongoing relationship with the client to support the site and make revisions to the theme.

In such a scenario, would it be acceptable to include the custom types, taxonomies, and fields into the theme? Is the no-functionality-in-themes more a guideline than a rule, applied more heavily on distributable rather than custom work?

  • Your question don't really fit site rules as it relies on opinion based answers, and not factual answers. My suggestion would be however, why not create a must-use plugin and include that with the theme. Commented Sep 8, 2014 at 6:08
  • Why don't you create a site specific plugin. Commented Sep 8, 2014 at 6:22
  • @PieterGoosen It's a question about guidelines provided by WordPress. The answers so far don't look very opinion-based to me. Commented Sep 8, 2014 at 17:22

2 Answers 2


while agreeing 95% with Drew's answer I would like to attend to another point

It's normally advised to not include custom types or taxonomies in themes as the themes will be less useful to other users, and would not be accepted by the WordPress theme repository.

The word of the maintainers of the wordpress.org repository is not the word of god and it changes from time to time. What was "Normal" just a year ago was to pack all functionality inside the theme. Both criteria should not be held in too high regards if you are not going to submit your theme to the repository and care more about serving your clients then scoring coolness points in the community.

The issue here is about leaving your clients the option to interchange or remove part of the site's functionality without losing its design and functionality

When you develop a commercial theme you need to focus on the design and try not to include functionality that can be achieved with popular plugins (for some subjective definition of "popular") because a potential client might already use a plugin for this functionality and to use your theme he will need to convert or recreate his data. A great example is SEO functionality that many themes used to include, but it was rarely equivalent to yoast SEO and the only thing it done for the themes is bloating them with code which was rarely used.

A site development is a different beast as your client is rarely interested in the software architecture of the site. Once he accepts the site he is very unlikely to replace yoast SEO with all-in-one SEO on a whim. Software modularity should be based on actual requirements from the client and since clients rarely understand the issues involved, and you need to decide for him. My rule of thumb is that 3rd party integration like SEO, FB, twitter should be isolated as much as possible since their requirements change all the time, but things that are internal to the site like special post types can be part of the theme as they are essential for the functionality of the design and are unlikely to change without changing the design of the site.

  • Perfect answer. +1 Commented Sep 8, 2014 at 7:17
  • I agree on the plugins. I assumed by "custom" functionality he meant things that plugins don't already do exceptionally well. Good answer :) Commented Sep 8, 2014 at 14:17

I don't think there's anything wrong with including functionality in a client theme. We do it with almost all of our custom builds as standard practice.

What's really in play here is the difference, I think, between 'commercial' and 'client' work. The prevailing wisdom on not including custom post types/custom functionality in themes is more aimed at the commercial theme shops and people who buy those mass-produced themes than anything else.

In the commercial space, the goal of separating functionality is to prevent "lock-in" when changing from theme to theme. But when you're working in the client space, "lock-in" is inevitable. It's a "custom" theme. If it's not a "custom" theme, just a "custom-ized" commercial theme, then yeah, I'd probably keep it separated as much as possible.

I'd suggest talking to your client(s) and finding out what their immediate and future needs are going to be. That should be the simplest guide you need to deciding how to handle custom functionality.

Not the answer you're looking for? Browse other questions tagged or ask your own question.