WP Tavern reported recently that WordPress Developers are organizing a community initiative to standardize common post types, taxonomies and meta data. Led by Justin Tadlock, popular WordPress developer and author of Professional WordPress Plugin Development, the goals of the community project are to name these common parts of WordPress to create a more stable and portable nomenclature for WordPress.
Tadlock explains that standardization is critical not only to the future of WordPress development but essential to standardize WordPress Themes and Plugins.
However, I’d argue that a little common sense also goes a long way. If you’re making an “events” plugin, don’t name your post type justin_event. Name it event. This isn’t really brain surgery, and I don’t think the WordPress developer community needs that much hand-holding to figure this out. But, if we do, let’s start that Codex page.
The only reason for any type of standards for post type names is so that it helps foster healthy competition between various plugins trying to fill the same space. This is so users can more easily switch between plugins to find the one they like the best.
There are some against such standardization as they feel it would restrict their coding freedom and flexibility, naming things organically rather than meeting a set of required standards. Tadlock and others argue that by adopting existing solutions rather than in-house, custom built solutions, it doesn’t restrain creative coding or proprietary code. He defends his position saying:
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.
Standards are accepted adoption of a way of doing things or naming things. This is part of the evolution of a language and industry.
As we developed the WordPress Codex, Michael Adams led a community campaign to solidify the names of WordPress parts and pieces. He and I created the Codex articles for Administration Panels, which later was renamed to Administration Screens, an example of the evolution of naming standards. In spite of our attempts to comply with the trademark protection of the term “Dashboard” for the entire backend interface, the WordPress Administration Screens continue to be called the Dashboard. Wrong name, but an evolving name standard as it has been adopted by a majority of users.
I fought for and against many of the naming structures in WordPress over the years, but always honored the standardization, and I’m with Justin and the rest of the WordPress Community on this.
Consider the power of using a custom post type like Event as mentioned, or resume, contact form, product, FAQ, recipe, event, news, and other post “types,” the types of frequently published content. While the design may change from Theme to Theme, imagine the basic functionality of a resume item, contact form, product, FAQ, recipe, event, news, and other not changing, behaving in a way that is consistent across all Themes because the naming structure has been standardized, giving designers and developers a faster and easier way to design and develop for these standards.
These standards apply to WordPress Plugins. Several people in the discussion started by Justin about standardizing post types talked about the WordPress Plugin they’re working on for recipe management and presentation. By using the post type name “recipe,” the user could choose from a selection of WordPress Plugins to apply styles and features to their recipe post types, finding the right one for their specific needs.
This is taking WordPress modularization as a CMS to the next level, opening up tremendous possibilities.
If you are interested in participating, check out the Content Type Standards community project.