WordPress.com and Jetpack should lead the way toward standardizing custom post types

themefoundry-bailey

Two themes were released in the last few days by a couple of theme shops I hugely respect: Bailey by The Theme Foundry (above) and Designer by Array (below).

array-designer

Both themes are for portfolio websites, and both themes use a custom post type for the portfolio.

What’s interesting, is that both themes are offering support for a common portfolio custom post type: the one on WordPress.com and the one coming soon to Jetpack 3.1.

For years we’ve been talking about the importance of not “locking in” users to CPTs bundled with themes. At some point, that gained decent adoption, but people still tended to just package the same code that was in their theme and put it in a separate plugin — a fine practice for sure. But it’s not a practice that makes it much easier to go from one portfolio theme to another; rather it’s a good way to be able to keep your content and support it with custom templates in some new theme.

What does it mean to standardize custom post types?

At its core, a custom post type requires a registration name. It’s common practice to prefix custom post type names, just like is best for any other WordPress thing. For example, if you have two eCommerce plugins installed (because people do strange things), it wouldn’t be ideal for both to register a post type named “product”, because a conflict could exist.

However, for many things, standard post type names make for better portability between themes. If you’re running eCommerce, it’s pretty specific to a particular eCommerce plugin. But if you have a post type for a portfolio, or testimonials, or staff bios, or something more generic, it could be a great thing to standardize so that different themes could support the same post type, which would result in better transitions for users from theme to theme.

WordPress.com and Jetpack can lead the way

WordPress.com and Jetpack have a great opportunity on this front. WordPress.com has a ton of websites and is a significant player in the theme market; most WordPress.com theme makers also release their themes for self-hosted installs.

As more WordPress.com themes begin to support more than blog-style content, WordPress.com is slowly enabling support for more custom post types. This means that WordPress.com — and Jetpack, it’s WordPress.org bridge — can lead the way in establishing some standardized custom post types for WordPress.

Bailey and Designer are great examples of this in action. Forefront, a business theme by Automattic, also has support for testimonials, which would work for their self-hosted version as well.

Current support for standard custom post types

Currently, Jetpack and WordPress.com support four post types:

  • Testimonials
  • Food menus
  • Comics
  • Portfolios (coming in the next version)

Really only portfolios and testimonials are mainstream styles of content. The other two were pretty theme specific add-ons, which Jetpack really just supported to aid transitions of .com users moving to .org.

There are many common post types that Jetpack and WordPress.com could continue to enable, including but not limited to the following:

  • Locations
  • FAQs
  • Services
  • Staff / Bios

There are many relatively common types of custom post types. And I’m beginning to think that some just don’t need prefixes, which would make them more transportable.

This is the kind of common support that is easy to make global, or non-prefixed, and also easy for developers to opt out of. If, for some reason, a developer had a common CPT use case that wouldn’t work well ported elsewhere, they could still use a separate plugin with a prefixed post type, and theme users could account for that when they decide to use the theme.

But for many common post types, I think not prefixing could be the way of the future; and I think Jetpack and WordPress.com are in a good place to support that.

What about metadata?

One of the concerns for this proposal is around meta data and custom fields. A custom post type often requires custom meta data fields to be registered, which are pretty core to the heart of the post type.

Barring a more structured core meta data api, this is a tricky issue. Different plugins name, store, and handle meta data much differently from one another, even if the field is relatively similar. For instance, a “job title” custom field could be handled many different ways from one implementation to the next, making common support for a custom field tough.

I don’t really have the answer to this. Do we prioritize what is important to standardize versus what is not? So, is the post type important to save but the metadata not so? I don’t know, and I lean towards not believing that. So maybe this dream of mine is limited to the most basic of fields in CPTs, or maybe Jetpack could strong arm the custom field naming conventions too. I’m not sure.

Build for the majority

No matter how we determine the specifics of standardization, it’s important to remember that we work for the majority. We need to make this easy on the end user, and as seamless between different themes and plugins as possible. That’s why I like what The Theme Foundry and Array have done with their new themes. They are making their stuff “just work” whether their user is on .com, .org, or moves from one to the other. Or, you could even go from one of their themes to the other, and it will work.

I talked to Jetpack team lead at Automattic, George Stephanis, and he says their reasons for the support are mostly practical:

The main reason that we’re shipping the CPTs that we are is for compatibility with WordPress.com.  If there’s a CPT we use on WordPress.com, it’s going to be abstracted out of the theme it’s meant for, so that other themes can use it as well, so we try to get them shipped in Jetpack for users that want to move seamlessly between the self-hosted and WordPress.com ecosystems.

I talked to Mike McAlister about my concept, and he agrees as well:

I agree with this argument. If they [Jetpack] don’t, no one will and we continue down the road of non-standardization.

And I also asked Corey McKrill — developer at The Theme Foundry — about the details of their integration, and they took it a step further, by using the Jetpack CPT but not requiring it:

We believe the theme should “just work”, so we didn’t want it to require the full Jetpack plugin as a dependency. However, if the user does have Jetpack installed, the theme will use the code from the plugin, rather than the internal version. (We did something similar with the Infinite Scroll functionality in our Oxford theme.) And of course, in terms of content portability, if a user creates a portfolio with Bailey and then switches to a different theme, they can install Jetpack to continue having access to their projects.

Corey also makes the good point that this notion of building on plugin functionality isn’t limited to custom post types; they did the same for infinite scroll in Jetpack. It does make me a little nervous to have CPT registration in the theme; but since it’s not locking the user in, this decision does make life easier on the user and give the most flexibility.

More thinking to do

There are details to work out; perhaps we need to create some best practices and standards around registering common post types. I sort of like the concept of adding common names to the reserved post types list, but basically in the opposite sense — like recommended post type names.

I don’t think this is a standard where there’s a huge role for WordPress core to play. I think it’s mostly a decision that can be made by the market, and the biggest players in it. Obviously, Jetpack carries huge weight, but they aren’t the only ones. I’m interested in what other theme and plugin makers think, and also what developers think about chaining functionality to plugins like this.