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).
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.
You’re absolutely right; Jetpack is in a unique position here with the ability to push towards standardization. We’ve been developing a theme with a portfolio and were close to using Justin Tadlock’s Custom Content Portfolio plugin precisely because it’s a nice, portable solution.
But it’s all about the numbers: Custom Content Portfolio has less than 10,000 users, Jetpack over 11 million. More users will lead to more developers using it in their themes, and that in turn means that as a theme developer it’s advantageous to support Jetpack’s post type for two reason:
1. It’s easier for your users to switch to a different theme since there is a broader selection available.
2. On the flipside, it’s easier for users to switch to your theme if they’re already hooked into the Jetpack post type.
That said, if the portfolio post type is the only thing you need from Jetpack, it certainly feels like overkill to install the whole plugin just for that, which is where I think Theme Foundry’s approach makes sense.
Cheers,
Eric
My own CCP plugin can never become a standard if all theme authors come at it from this viewpoint. It could just as easily have 100,000s of more users if theme authors would adopt it. I do have some other thoughts to add to this, but I think they warrant a blog post of their own.
Is there any way to support both my plugin and Jetpack? I’m not sure, but I’d be more than willing to add in any hooks or whatever is needed to my plugin to make it easier for you.
Hi Justin,
Sorry if I came across as dismissive of your CCP plugin āĀ that was totally not my intention. And I agree completely that if theme authors do adopt it, it will gain far more users.
I would love to be able to support your plugin and Jetpack. It would be a much better solution for users since it means they don’t have to install Jetpack if they only want the Portfolio post type. It also means that they can switch from Array’s Designer to your Chun theme while their portfolio data remains fully intact.
If your CCP plugin and Jetpack are compatible in terms of data structure, then we’re getting much closer to setting a standard, one that I think is a win for users and developers alike.
Honestly, I’d be just as amenable to looking into making any common post types equivalent between Jetpack/WordPress and yours. Convergence for open standards ftw?
Hmm, very interesting topic. I definitely agree we need better portability between themes. This could help, although to be honest, I’d rather see it done through core than through Jetpack.
I know we normally try to keep things out of core, but we did include common post formats, so why not common post types, especially given the importance of preventing theme lock-in.
Transferring reliance on a third party plugin to Jetpack is a step in the right direction, but there is still a form of lock-in (to Jetpack). So adding it to core would get my vote. That’s the only way to get true portability.
I’m also wondering if someone could create a post type mapper class that could be included in themes, so authors could easily include a function that allow users to migrate post types from other themes into theirs. But I haven’t though that through at all – it might not be a feasible idea…
+1. But rather than include directly in core, I’d suggest finally implementing the “core plugins” concept that were suggested years ago, i.e. include them with the core download but as plugins with their own listing page in the admin.
Hi Mike,
Agree 100%. To be honest I’d almost forgotten about core plugins! But this would be perfect as a core plugin.
Jetpack has too many other things in it (including some commercial services) and it serves other interests. The solution for this needs to be independent and dedicated. Not speaking officially or promising anything, but we’d be far more likely to consider pushing a core plugin over at ThemeForest.
Definitely agree. It needs to have no vested interests that would otherwise cause some to not support it.
Not really what you’re looking for, but I have used the Post Type Switcher plugin to good effect on a site-by-site basis.
https://wordpress.org/plugins/post-type-switcher/
The main thing is to establish “leading” plugins. The rest of us can write tools to port data if we want to use our own solutions. I have a suite of plugins (available on .org) that power my restaurant niche themes. But if WordPress.com’s menu post type becomes the community leader, I’ll happily write a tool to port content between the two plugins.
Automattic can lead the way for this. But I’m always cognizant that the WordPress.com mission is to onboard people to WordPress. Their goal to keep things as simple as possible may run into conflict with the need for flexibility in the general community. A dirt-simple content type like Portfolios might lend itself to this more easily than a Restaurant Menu, which has more rigorous and diverse requirements on the front-end.
One other question is whether the Custom Post Types we ship in Jetpack should be prefixed or not.
We don’t currently have a ‘hard-and-fast’ rule, and honestly I’m undecided on whether the CPTs we’re shipping should purport to establish a standard (which would be non-prefixed), or just be explicitly our own implementation (prefix all the things with Jetpack). That’s something I’m not comfortable making a decision on without a good amount of discussion with both the team internally and the community at large.
Which is why I’m so glad this post is out there. I’d love to use this comment section to get feedback on what the community wants. Would you like to see us name our Custom Post Types as a standard method that is built for extension by third-parties, or would you individually consider that to be too presumptuous, leading to namespace conflicts, and we should namespace all the custom post types that we ship as `jetpack-portfolio` and thereby keep it from being a standard that everyone would use?
I think any standardization of CPTs should happen on the WordPress.org side, perhaps on one of the Make blogs, rather than in any one plugin. Sure we could standardize on the CPTs already defined by Jetpack, then Jetpack could just implement that … but I don’t think a plugin built and maintained by an organization outside of .org should be taking the lead here.
To be fair, this same discussion happened two years ago at the last community summit, and there has been zero progress since then. Wanting someone or some group to take the lead on it, I think, is the impetus for Brian’s post.
I’d be delighted to have a community group stand up and do it instead, I’m just not sure it’s going to happen. The sort of thing that everyone thinks ‘someone’ should do, but noone wants to stand up and do themselves.
So, I’ll wait and see what other folks think — in the community. We’re pretty active in accepting pull requests to Jetpack, so if it does get canonically worked out in Jetpack, it would be with full availability for community interaction, and naturally GPL, so other folks could take it and repackage it as desired.
We shouldn’t give up control by imposing any standards on a popular plugin. Jetpack shouldn’t be an authority for standards; as well as s2Member should never be an authority on subscription logic (even if it was extremely popular).
As I wrote in my response CPT slug names really isn’t an issue. If these businesses want to help customers (by converting them into buyers) they need to provide tools to help them convert from older themes. Technically a CPT slug name is probably the easiest thing to change and an interface to migrate is a days worth of work–more importantly it’s a business opportunity.
I think that what Corey said is a good way to go. The theme has the CPT bundled to allow for use without Jetpack (or whatever other plugin may extend it), and this can presumably be overwritten when Jetpack is enabled.
One issue that would need to be sorted would be versioning. Do you always default to the plugin version of the CPT if it exists? What if the theme wants to extend it? What if the theme makes changes that work for them that don’t need to necessarily replace the plugin version, but modify it?
In order to maintain content portability, we’ll try and keep Bailey’s portfolio CPT class synced with Jetpack’s, and the theme will always defer to the plugin version when it’s available.
Most of a CPT’s properties can be modified after registration with various core functions and hooks, so there shouldn’t be a need to make changes to Jetpack’s class. It’s treated more like a 3rd-party library.
Having some industry standard CPTs (data types, whatever) is a great idea. Many industries do this in order to be able to transfer records between systems, and it works quite well. I do not, however, think Jetpack is the proper driver of this. I love Jetpack, but Jetpack is controlled by a single entity with their specific needs in mind and not the WordPress community as a whole (Not saying Jetpack ignores the community!). WordPress.com and Jetpack can (and are) used as a playground for features that would be neat to see in WordPress core. If core finds a feature useful Jetpack will happily donate it to core for the entire community to enjoy and rely on.
What I instead would like to see is a community repository on WordPress.org where standards could be debated on and built for these CPTs. Similar to how w3c works for html, but with a much faster process ;). These CPTs should not be shipped with core, but added on an as needed basis to keep core small and fast. A mechanism for downloading on the fly as requested and then adding into that site’s core would be neat (add_theme_support() anyone?…).
Even if/after all this standardization happens it is nearly impossible to think of all situations and usages of a CPT so there will always need to be room for additional meta data to be attached. If you need an example check out the Real Estate MLS feeds. From place to place there are differences due to physical features of the land, legal reasons, etc.
I think having standard Custom Post Types for certain things is a good idea. I don’t necessarily think it should be dictated by Jetpack though. In this case it’s not bad, but if you want to truly make a standard that developers can adhere too it needs to be more than that.
Creating a team within the WordPress community specifically to create and define a set of standard Custom Post Types and getting buy in from theme and plugin developers to adopt those would be the way to go.
That doesn’t mean every theme and plugin would use those standards, because one size doesn’t always fit all. But that would be the way to go if you want to introduce some sort of standard in a situation where none currently exists.
Having a plugin to contain standard post types, I think is a good thing. Jetpack is wrong place for it. Jetpack, is a massive dependency, especially if all you want to do is use these post types. I’d suggest that this be a plugin of it’s own. As for prefixing them, absolutely we should. they should be safe to use. Many sites have existing CPTs with names like Project, Profile, and Address. Also, activating this plugin shouldn’t require the user to implement all the supported post types. That should be controlled by the user of the plugin.
The more I think about the comments here, the more I think that having an official CPT may be a bad approach. The beauty of the Page/Post system in core is that there really is very little post meta and the post meta which is there is appropriate in pretty much all cases.
With the exception of comics and FAQs, I struggle to think of another post type which would work as well with a common set of post metadata. With Food Menus, even the most common post meta, price, is not appropriate in all circumstances. Some restaurants serve set menus or have a base/addons pricing system (pizza toppings), for instance. Should a Locations post type support a blob address for ease of use or complex Schema.org metadata that is compatible with addresses around the world? Portfolios, Team Members and Services seem even more prone to diverse needs.
Yes, we can remove and add meta data as we need for custom solutions. But then it seems to me like we’re defeating the purpose of an official plugin anyway. Is a CPT plugin much more than a data architecture? It would make more sense to build consensus around a few plugins for each CPT, which can serve the needs of different use cases. Then build compatibility between them with tools to port data back and forth.
How about standardizing a custom taxonomy called Authors and try to undo the senseless default practice of making Content Owners stand in for Authors? Authors are a taxonomy with a little meta-content of their own; they may or may not be mapped to Users, a whole ‘nother animal.
My what a difference 4 years can make (long thread.)
There are plenty of people smarter than myself who can speak on the technical and philosophical challenges of standardization here. You can see from the comments above that this is clearly a colorful issue, and it has been in the past every time the discussion surfaces.
But similarly to past discussions, the conversation always tends to drift into infeasible tangents or an intense philosophical debate over what entity should “own” what. Don’t get me wrong, I think some quality discussion can come of this and I think its important to consider the implementation. But I also think the discussion can be a bit self-serving. The focus of this discussion is hardly on the user and what standardization means for the majority, which Brian was hinting at. Instead we’re getting caught up on developer preferences and idiosyncrasies.
At this point, I would rather see the portfolio CPT standardized by an (not entirely neutral) arm of WordPress than see the topic curbed for another couple of years until the majority can come to a consensus. Maybe I’m crazy, or maybe I’ve just dealt with non-standardization in the commercial theme space for too long!
It’s clear that if standardization of the portfolio CPT has a chance to catch on anytime soon, it’s with Jetpack since the implementation is already there. It may not be the ideal candidate for some, but the reality is it’s unlikely that any other efforts have more reach or resources than Jetpack does to implement this the right way.
tldr; No, I don’t have a solution, but someone please make a decision already. š
I agree. People have gotten into the responsibility / best practice realm here, and talking about who should drive.
My point was more that Jetpack / WordPress.com should drive from a practical perspective, not necessarily an idealistic one.
Big entities often steer the direction of competing concepts: Blu-Ray vs HDDVD, etc. I think Jetpack can standardize some common CPTs and W.org can adopt around it (with the reserved list, etc) and other plugin companies and theme companies can follow suit.
Don’t think this could have been said any better. CPT’s have been around such a long time now, it’s not like standardising some CPTs would steer WP in new uncharted territories.
I’m a little late to the party, but would like to weigh in with some ideas. Generally, I’m really in favor of some way (any way) of standardizing some basic post types.
* How these are implemented is a secondary discussion to whether they’re needed (I think they are) and what can be standardized. Jetpack does seem like a logical place to look if we’re focused on actually seeing anything happen soon. I could also imagine a “core plugin” (the closest thing we have right now is Jetpack…so we’re back where we started), core (meh), or even just a standards document (most flexible and most-likely to be implemented inconsistently).
* This may be a terrible idea, but I also wonder if core should consider some way of registering a persistent post type. (This might be a new argument when registering the post type?) Since the posts remain in the database even when the register_post_type function goes away, maybe WordPress should somehow store the settings and leave the UI available. In many cases, this is probably more desirable than the post type just disappearing. In the case of a FAQ (more on that in a moment), most themes could probably at last handle displaying the basic post without any custom code.
* How about the prefix that isn’t: “wp_”. Certainly, it would still run into some conflicts but at least fewer. It would also have the benefit of a certain implication of official-ness to many. The new standard also might just treat “wp_*” as a reserved post-type slug namespace to keep options open in the future.
* Standardized meta does seem almost as important as the post type itself. To figure out what meta should be standardized, I think it makes sense to look to existing standards like Schema.org. Data formats could be an issue, but starting with plain text would still get us a long way (for example. a person has a name, a telephone number, and a job title). One question that arises, does certain meta make sense more as an accompanying standardized custom taxonomy? (examples: a “Role” taxonomy for a “Person” post type or a “Type” taxonomy for a “Project” item) The specifics of each taxonomy might vary from site to site (e.g. a “Role” taxonomy could be used for familiar relations or organization structure).
* A FAQ post type is a great starting point for pushing this idea forward immediately, I think. Title = Question. Body = Answer. (Excerpt = tl;dr?). I could even imagine a “Subject” taxonomy that optionally goes with it.
I only see Portfolio CPT in the latest version of Jetpack 3.1.1, but this article says it supports Testimonials, Food Menus, and Comics. Am I missing something?
Does anyone know if the other useful CPT’s (Locations, FAQs, Services, Staff / Bios) are on the roadmap for a future version of Jetpack?
Between Portfolios, Testimonials and Staff / Bios, we’d have fully standardized the most common types used for business and creative websites.
Also, is there full documentation for theme developers on how to add support to our themes? For example, the specific template file names, hooks, etc.
I was wondering the same thing. Currently I only see one CPT (Portfolio Projects) as an option to activate in Settings after enabling Custom Content Types in JetPack.
It threw me for a loop too. You need to add_theme_support() it. jeherve’s explanation.