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