1

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?

closed as primarily opinion-based by mrwweb, Pieter Goosen, birgire, gmazzap, Tom J Nowell Sep 11 '14 at 0:17

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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. – Pieter Goosen Sep 8 '14 at 6:08
  • Why don't you create a site specific plugin. – Brad Dalton Sep 8 '14 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. – Grant Palin Sep 8 '14 at 17:22
3

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 – Pieter Goosen Sep 8 '14 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 :) – DrewAPicture Sep 8 '14 at 14:17
2

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.