21 Responses

  1. Haluk Karamete
    Haluk Karamete Published |

    How do you disagree with that?

    Right on the dot Justin..

    The matter with the CPT is kind of like the matter with post-formats – which is something in motion. The idea is the same. It works there, why would not here?

    Of course, the idea can be extended to beyond CPTs as well, such as certain custom fields that gained traction, and even some taxonomy names that may make sense… – though I do see that they are a much more difficult battle to get into – so let’s go one step at a time.

    Getting the CPT’s take that direction is a pretty good step forward…

    A personal note… It just dawned on me why you opted in the custom field name ‘thubmnail’ as a default name for your get_the_image plug in – which is probably in use in a million sites. I used to think how come a guy like Justin Tadlock won’t opt in for a prefix for such a thing… now I seem to get it… maybe you sensed and hoped back then, that one time, even that name would be “THE” standard.

    Am I off here?

    Reply
  2. Mike
    Mike Published |

    OK, I don’t agree. It’s not the dotorg’s job to manage this.

    I think we should consider taking things to a lower level.

    This site – http://generatewp.com – offers easy code generation for CPTs, wp-config and more.

    What we need is a way to add raw code to a self-generated plugin on the fly to create this stuff.

    Specialized plugins could offer an interface to select existing CPTs for use. Naming conventions became irrelevant. They would manage the abstract connection between their code and existing CPTs.

    Reply
    1. Haluk Karamete
      Haluk Karamete Published |

      Hi Mike,

      Following standards is better than not following them, unless you are into some or of creatives-art or something.

      As to whose job it is this to manage. I think we got a pretty good situation here that it is exactly the dotorg’s job.

      See, if we were discussing ‘standards’ for a different piece of software, (such as browsers i.e, Chrome,IE,Firefox..), this would not fly. I would have agreed that yeah, whose job it is to decide… Getting those browser makers agree on what and how just would not fly.

      but here, with this CMS, who else is to call the shots, but the dotorg? One point of reference! Bamm!

      So the setup is really ready to go. All it takes is the idea to sink in.

      I get your point on ‘managing the abstract connections’ Mike – that’s many times a good thing of s/w design. But I don’t see that as a valid concern here as much.

      Let’s turn the question around and ask.. What’s the harm here if these standards would have been adaopted?

      What was the harm with post-formats which went thru this same exact idea for example?

      Reply
  3. The WhiP Newsletter #50 - WPMU DEV
    The WhiP Newsletter #50 - WPMU DEV at |
  4. Devin Price
    Devin Price Published |

    I agree with this completely. A list of recommended naming conventions for custom post types on wordpress.org would be extremely helpful for compatibility.

    The “Portfolio Post Type” plugin I released a few years ago uses the slug “portfolio”. Your “Custom Content Portfolio” plugin uses “portfolio_item”. If we had a recommended standard users of these plugins would be able to switch much easier.

    Reply
  5. Bryce
    Bryce Published |

    Completely agree Justin. I’m in the same position with a Recipe plugin I’ve been working on (Recipe Hero – http://recipehero.in/), where I opted to use the ‘recipe’ post type name. It makes building tools/solutions for those switching over from other plugins using the recipe post type 100x easier, as well as leaving room for production of add-ons and themes.

    Would love to work with you on an integration for you restaurant plugin. Feel free to shoot me an email and we’ll chat!

    Reply
  6. Ryan
    Ryan Published |

    I love this idea and look forward to seeing it develop and helping if I am capable :)

    There are two other content areas I see in a great many themes now as well, that would some type of featured content slider and some column/boxed content areas on the home page. Would these be candidates to standardize as well do you think?

    Reply
  7. Week in review: Sass in _s, CPT standards, MailPoet vs Sucuri, and meet me in New York : Post Status
  8. Haluk Karamete
    Haluk Karamete Published |

    Though I like the idea of standardization in the CPT name(s), I’m curious to see how the rest can be taken care of as far as the custom field names (or the custom-taxonomies for that matter ) that go along with that particular implementation of that CPT.

    For example, a vendor implementing a CPT called ‘recipe’ may choose ‘ingredients’ for the CF which holds the ingredients-data whereas another vendor may have opted in to use the name ‘ingredient’.

    Reply
  9. James Steinbach
    James Steinbach Published |

    I’m looking forward to seeing where this push goes. It will also help theme developers provide consistent styling for CPTs. That’ll allow themes to “support” portfolios, events, etc, without bundling a bunch of plugins!

    Reply
  10. Code Standards Project to Take WordPress Into the Future « Lorelle on WordPress
  11. Tweet Parade (no.31 Jul/Aug) = Best Articles of Last Week | gonzoblog
  12. Momekh
    Momekh Published |

    I would want to gasp bundle the Restaurant plugin into the theme.

    In fact, I would hard code the plugin into the theme instead of even bundling it. The theme is for restaurants, and the features that the plugin provides are supposed to be built in. Why give the user another step to perform?

    Kind’a like a framework for restaurant themes, right? You add it everytime you’re building a theme for that niche. Making sense?

    Would that be considered a good marriage of best standards and user-friendliness?

    Reply

Leave a Reply

By submitting a comment here you grant this site a perpetual license to reproduce your words and name/Web site in attribution.

Please use your real name or a pseudonym (i.e., pen name, alias, nom de plume) when commenting. If you add your site name, company name, or something completely random, I'll likely change it to whatever I want.

css.php