Custom Post Types in WordPress themes

Custom Post Types provide a great way for users to add custom, non-blog content to their sites, but implementing them in premium themes is fraught with issues. Is there a best practice we should follow?

I’ve found that Custom Post Types provide a superior experience for my clients to add custom content to their sites. As a conscientious web designer and developer, I also wanted to maintain that improved user experience in my commercial themes, so I was curious to see the best way of incorporating CPTs into themes for sale.

After a lot of research, It seems that there there are four main options, each of which have pros and cons:

  1. Just use normal posts and categories
  2. Build the CPT directly into the theme
  3. Use an off-the-shelf existing CPT plugin
  4. Build our own plugin for enabling CPTs in our themes

Lets look at each in turn:

Just use normal posts and categories

This is by far the simplest way of enabling CPTs, in fact you don’t even need a CPT to do this. Just setup a Theme Option for the user to select which category they want to use for their special post type—for example portfolio pieces—and they just use the normal Post editing screen. Mike McAllister does this with his Okay themes. http://mikemcalister.com/i-dont-use-custom-post-types/ and it seems to work well.

Pros

  • No new knowledge required by the user—it’s simply basic WordPress editing
  • No extra CPT code to maintain

Cons

  • There’s no clear separation in the backend for the Portfolio posts–users will need to use the category filtering to find Portoflio pieces and this might be confusing for WP newbies
  • All Portfolio pieces will use your normal permalink settings, so instead of appearing at a sensible URL like /portfolio/title they will have something like /2013/01/23/title. UPDATE: This code snippet may solve this issue: http://stackoverflow.com/q/11024040

Build the CPT directly into the theme

In January 2013, the general feeling is that building CPTs into your theme is a bad idea. This is due to the Lock-In effect, whereby the user can’t easily switch themes as their CPT data will appear to have been lost. Read more about the Lock In problem here: About the “Lock in Effect” in WordPress Themes and Plugins

I completely agree that locking people in is a bad move, but let’s have a quick look at the pros and cons anyway:

Pros

  • The user only has to install the theme and doesn’t have to worry about obtaining third-party plugins to make the CPT work
  • The developer can customise the interface to the CPT as much as they like and make a superb user experience that is clear and easy for the user

Cons

  • The user is “locked in” to using that theme because disabling the theme also disables the CPT—the data is still in their database, but as far as the user is concerned, it’s vanished. Cue mass panic.
  • Developers providing many themes have to duplicate this code in every theme they release and maintain it, which can become time consuming.

Use an off-the-shelf existing CPT plugin

If we decide to separate our CPT code into a plugin, two choices remain. The first is to use an off-the-shelf plugin. At the time of writing, I think the only one available for portfolios is by Justin Tadlock, and it’s in rudimentary form, simply setting up the CPT but without any metaboxes / custom fields: https://github.com/justintadlock/custom-content-portfolio. WooThemes also offer a couple of CPT plugins for other types: Testimonials and Features.

Pros

  • Standardising on one plugin will make it much easier for theme authors to deliver a consistent experience.
  • Users only need to learn to use the plugin once. And since it really only adds a normal WordPress menu item with a few extra fields/options, the barrier to learning is very low
  • Any themes that use this CPT plugin will “just work”—so when a user switches to a new theme that uses the plugin, there’s no loss of data (perceived or otherwise) and their site continues to work flawlessly. There’s no “lock in”, which is great!

Cons

  • Users will need to download and install the plugin before their theme will be fully usable. For non-savvy users, the TGM activation script can help manage this, but what if a theme requires 4 different CPT plugins—it can become scary for many users to manage those sorts of dependencies.
  • Theme authors are restricted by what’s in the plugin. While the more development minded authors will be able to hook their own stuff into the plugin, many theme authors may be uncomfortable extending a ‘standard’ CPT plugin.
  • Bugs in the plugin may not get fixed in a timely manner. If a theme author uses a public plugin that has bugs, it may reflect badly on the theme author.
  • If anyone can contribute to a public CPT plugin, how do we ensure the plugin does not bloat yet caters for as many themers as possible?

Build our own plugin for enabling CPTs in our themes

Having your own functionality plugin to handle all your CPTs is a nice way of controlling the full experience for your theme buying customers.

Pros

  • You can build a consistent experience across all your themes, so customers buying one of your portfolio themes won’t need to learn anything new if they buy another
  • You can build as many CPTs as you like into your plugin and all your themes can use them, or not, as you see fit.
  • As a developer, you’re in complete control of all the code and don’t have to rely on waiting for updates to third-party plugins or other solutions.
  • You can offer default templates for all your CPTs with your plugin. If a user wants to switch to a theme that isn’t yours, they simply leave your CPT plugin active. Of course, their new theme will need to be adapted to work with the CPTs but this would be a small job for any developer to handle if the CPT plugin provides enough defaults and docs.
  • It’s easier to maintain, and easier to offer support to customers as the developer is in control of all the code for the CPT plugin and the theme.

Cons

  • As with option #3 above, users have to download and install the plugin before the theme is fully usable (of course, your theme should not break without the plugin—the plugin simply adds extra functionality.)
  • If the CPT plugin author doesn’t actively distribute the code, then it’s just another closed proprietary solution (it would be better in this case to make the CPT plugin available on the WordPress.org repo.)

Which option is best?

The answer to many web development questions is “it depends” and this one is no exception. To be able to offer the best possible combination of great user experience and great support, I would probably choose option #4.

But this may not work for your own situation and your own customers, and it doesn’t best serve the WordPress open community as a whole. Option #3 would be best if you want to be truly open.

Tags: Web Design & Development, WordPress