Skip navigation

Code Standards Project to Take WordPress Into the Future

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.

With the introduction of the body classes function for WordPress Themes, and custom post types, I’ve been longing for some form of standardization. The possibilities are so exciting.

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.


Feed on Lorelle on WordPress Subscribe .

6 Comments

  1. Kerry
    Posted July 29, 2014 at 11:02 am | Permalink

    This IS a great idea. Three things come to mind.

    1) What are the CPT’s i.e. what “objects” do we create as post types? You mention a few – events, resume, contact form, product, FAQ, recipe, event, news – there are many more and the community will need a way to start an effort for anything “net-new”.

    2) Meta collection screens. How will they be organized? Once a CPT is standardized an input screen would need to be created for all the aspects of the CPT.

    3) and of course extensibility. This would help those that are opponents of standardization. The ability to adjust the standard class.

    • Posted July 29, 2014 at 3:20 pm | Permalink

      I’ll try to answer those questions.

      1) Right now, we’re just trying to cover some common post types. This gives many of us some common ground to start from. It’s a way to kick-start the conversation. Once we start diving into things and get a few things standardized, my hope is that we continue branching out and adding new standards as needs arise.

      2) I don’t think you need to standardize on the UI/UX aspect of this. What’s important for standardization is that you use the same meta keys in the database with the same types of data for the meta values. Beyond that, how that is presented to the user will ultimately be “features” of competing plugins.

      3) Extensibility is a huge factor here. We could have three different portfolio plugins, for example. Another developer could come along and build an extension plugin that would work with all three.

    • Posted July 29, 2014 at 9:26 pm | Permalink

      Thanks for jumping in, Justin. This really helps all to understand the tasks ahead. I’m so excited about this! Thanks for taking it on.

    • Posted July 30, 2014 at 1:07 am | Permalink

      Hi Kerry, Justin and Lorelle,

      Would both standardization and extensibility be greatly facilitated, enhanced and/or assured if/when the Object Oriented Programming paradigm has been observed or appropriated in part or whole by the relevant coders and developers, even though the approach might require more effort, planning and collaboration initially?

    • Posted July 30, 2014 at 1:12 am | Permalink

      Thank you very much, Lorelle, for the timely and informative update. :)

    • Posted July 30, 2014 at 9:22 am | Permalink

      Thank you.


Post a Comment

Follow

Get every new post delivered to your Inbox.

Join 21,005 other followers

%d bloggers like this: