Cancel

Sarah Gooding

WordPress Developers Organize Community Initiative to Standardize Custom Post Types, Taxonomies, and Metadata

photo credit: rosswebsdale - cc
photo credit: rosswebsdale – cc

A WordPress community initiative is underway to standardize content types used by plugin developers. Justin Tadlock is spearheading an initiative to create WordPress community-curated standards for common post types, taxonomies, and metadata.

WordPress developers are invited to join the discussion taking place in the Content Type Standards repo on Github where Tadlock outlined the objective: “The purpose of this repository is to create an open set of standards for the WordPress developer community on how to name custom post types as well as related taxonomies and metadata.” This would include common post types, such as testimonials, portfolios, recipes, FAQ, events, and products.

contnet-type-standards

Tadlock, who has historically been a vocal advocate of data portability, is hoping that the standards will enable users to painlessly switch between plugins that compete in the same space, without losing any data. Standards will also make it easier for developers to build extensions in such a way that they can be more widely adopted by theme developers. He identifies a few benefits that both users and developers would enjoy as a result of content type standards:

  • Less worry about what to name things when creating a plugin.
  • We can have competing plugins in the same space.
  • Cool things like add-on plugins become easier to build.
  • Users can switch between similar plugins to find the one they like best.
  • It would be easier to push for things in core WP like custom Dashicons.
  • Theme authors could potentially support multiple plugins.

The project will first be focused on establishing a set of standards for plugin authors to follow, based on the core WordPress methods. Tadlock also suggests a secondary goal of creating a few PHP scripts for developers to copy/paste for registering a post type or taxonomy that make use of the new standards.

The Need for a Community-Curated Initiative

Brian Krogsgard recently published an article calling for Jetpack and WordPress.com to lead the way toward standardizing custom post types. While Jetpack and WordPress.com are in a good position to lead the way on this, there are many community developers outside of Automattic who have valuable input to offer on the creation of a truly open set of standards.

In a recent article that outlines the need for custom post type standards, Tadlock argues that standardization goes far beyond simple naming conventions:

People are still using their own, separate code rather than adopting existing solutions, preferring a solution built in-house instead of joining together with others. That’s the reason we don’t have standards. It really has little to do with post type naming conventions.

The idea behind the community-curated standards is to help WordPress developers work together without the need to reinvent the wheel every time with their own solutions. Instead of closing off products with naming conventions that won’t be able to transfer users’ data, Tadlock encourages developers to work on creating plugins that become standards in their own right.

Standards are created after we’ve made them and they’ve been adopted by enough people. In other words, we create standards by building good plugins, getting users to install them, and having theme authors integrate with them.

The Content Type Standards project is a community initiative that puts users first and helps developers make products that can be more widely used. The first order of business is to establish the post types to standardize so that contributors can then address the naming standards, taxonomies, and metadata for each. If you build products that utilize custom post types, make sure to get in on the discussion happening on GitHub.

Category: , ,
Tags:
11

11 responses to “WordPress Developers Organize Community Initiative to Standardize Custom Post Types, Taxonomies, and Metadata”

  1. It would seem to me these could be classes. Some baseline standard with the option to extend(s) as each dev see fit.

    That said (and thinking out loud), I’m not so sure this is really data portability per se. This is closer to data standardization – which given WordPress’ Wild West approach to growth / market share is a 180.

    Perhaps instead it would make sense to have some sort of XML (?) defined mapper between one plugin and the next? That would still give each dev the liberty to move ahead and the users a backdoor to switch horse if they want to.

    Heck, a great start to that would be an XML export / import standard for plugins setting. Wouldn’t it be nice to config a plugin in dev and just export / import the setting over to production?

    • It is about data standardization. Portability can be a byproduct of standardization though, which is a goal I think we should shoot for.

      I’d also love to see tools that map or do whatever when switching between plugins like that. I think standardization may even help with that.

      • Justin – Please pardon my Devil’s Advocate-ness for the sake of this sub-thread / discussion. (I want to be clear: This is not push back. I for one believe the WP framework product should be mature enough at this point – i.e., 10+ yrs – to begin to address such issues.) That being said…

        It feels like apple and oranges to me. Many would argue that standardization can and does squash innovation, or at least the ability to experiment. On the other hand, (data) portability – which btw perhaps isn’t the right word since the data is staying put, it’s the plugin that’s changing – allows the eco-system to thrive more or less unregulated (if you will).

        Off the top of my head…

        Step 1 – An intra-plugin export / import standard. (In my mind, provide a class / toolkit so implementation is uber ez for devs.) Again, for example, the plugin is config’ed in dev and it’s easy to export and import those baseline setting into staging / production. That (XML file) would provide a level of transparency as to what data the plugin is generating / using.

        Step 2 – As the various approachs to a given solution become clear, chances are good one plugin author – in order to gain market share – is going to write a sub-plugin (?) that will migrate data from competitor A over to their plugin. I believe a couple of the SEO plugins kinda do that now, yes?

        Step 3 – Eventually, the market settles out (if you will) and the deviations slowly become standardization. I’m not sure what the proper economic term is but I’ll go with: Competitive Cooperation (if you will), or perhaps Cooperative Competition :) That is, (for example) “Well, if I do X, Y and Z like industry leader plugin #1 then that’s one less thing to convert / migrate.” Or something like that. Currently, in theory that’s possible but WP’s general Wild West mindset doesn’t see value in NOT inventing the wheel, eh?

        That being said, if nothing else some sort of actual documentation standard would certainly help. Trying to figure out someone else code (e.g., what a given meta data element actually represents) shouldn’t take prayer and monk-esque chanting, as it often does now.

        Such a level of transparency is also a benefit to end users in a buy beware sorta way. I’m not saying they’ll read it, but devs knowing they are “exposed” has a tendency to influence behavior.

        p.s. Ping me if you want to take this up offline. I don’t want to hi-ijack Ms. Gooding’s article, nor suck up your time responding to my madness.

    • Going a step forward, you could have traits that are used by these classes to greatly improve DRY. Though WordPress requires PHP 5.2.4 (released August 2007) and Traits were introduced in PHP 5.4 (released March, 2012)… sigh.

  3. I am against this because I don’t think it’s necessary.
    Instead I support incorporating the technology behind the http://generatewp.com site into building CPT’s into an on the fly plugin that would abstract the data.
    In effect, there would be a interface to assign a particular existing CPT to a particular vertical function for a plugin. As a result it wouldn’t matter what a CPT is called.
    Also building a wizard type interface for basic WP code generation that can be shared by all plugins would be extensible to many uses in the future.

    • The whole point about this is that something like the approach you favor would lead to arbitrary names like “portfolios” and “portfolio” and “my_portfolio.” Apologies if I am missing your point.

      • I don’t favour arbitrary names as much as I don’t think fixed names for anything but the bare minimum is a good idea.
        Instead I am suggesting that the user would assign an existing CPT to a use (portfolio as you suggested). The interface could say,
        “Select an existing CPT for use as XYZ’s Portfolio CPT” with a pulldown of existing CPTs.

    • Based on what I’ve noticed, much of Gen WP can be abstracted (?) into classes and those classes can be (in theory) add to WP core. For me WP Gen is simple proof that a fair amount of WP dev (read: code writing) is simply filling in the blanks (i.e., setting the args). So why can’t we just do that from the get go, instead of having to write the code AND the args?

      A better use of array and classes could – imho – go a long way to making WP dev more efficient AND result in better, cleaner code.

      Or something like that ;)

      p.s. My sense is Justin is talking about something other than code generation. I could be mistaken.

      • From what I can tell, Justin is just a developer with a large audience saying – ‘Hey, can we reduce the insanity that currently exists in the ecosystem.’ He’s right, its nuts out there right now.

        I don’t think it has much to do with code generation or even code in general; he’s just attempting to wrangle in this area of complete chaos. A lot of developers are doing their own thing and it makes much more sense to have some community guidelines about how to approach these things.

        My concern is what does this look like, or how does it impact anything if the effort is successful?

        • As you mentioned, these are only guidelines, and it would be non destructive by design, as previous implementations would still be working.

          Of course in case of post type name collision, it would be care of developers to handle it by either accepting this new set of shared conventions and adapt their code, or ignore them and making their implementations live side by side.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: