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

Categorized under:

, ,
Photo of author
Written By Brian Krogsgard

29 thoughts on “WordPress.com and Jetpack should lead the way toward standardizing custom post types”

  1. 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.

  2. 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…

    • Iā€™d rather see it done through core than through Jetpack.

      +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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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.

Comments are closed.

A2 Hosting
Omnisend
WordPress.com