[wp-hackers] Custom Post Types and pending incompatibilities

[Otto]

One would hope that plugins would use a prefix naming convention for
their custom types in the same way we recommend making function names
and such. plugin_whatever and so forth.

I like your ideas, and I would also suggest that plugin authors doing
the same sort of things in their plugins start to collaborate amongst
themselves to build larger plugins with many authors. I think that
plugins along these lines, with a wide variety of authors
collaborating on them, have a relatively decent shot of becoming
"core" plugins. Long term, of course.

Hopefully the 3.org updates will help out in this respect.

-Otto



On Sat, Jul 10, 2010 at 2:59 PM, Mike Schinkel
<mikeschinkel at newclarity.net> wrote:
> Hi all,
>
> Now that 3.0 is out it seems people are diving into using it in really incredible ways.
>
> One thing of course is that there will be an explosion of plugins with custom post types and clearly many pending incompatibilities among plugins that are attempting to address different aspects of the same problem.  For examples:
>
> -- Plugins might model real estate properties using a custom post type named "property", "properties", "re-prop", "real_estate_property" or something else. Even if they have compatible functionality they still won't be able to be used together.
>
> -- Plugins might use the same name like, i.e. "event", but then use different names for custom fields.
>
> -- Most importantly, it will likely be impossible to add any new types to core w/o potentially breaking existing plugins and/or existing custom implementations.
>
> Clearly, there's no way to resolve these issues completely but it would be nice to attempt to minimize the issues. With that in mind I'd like to make the following strawman proposals in order to open up the topic for discussion:
>
> 1.) Create a place on WordPress.org for ad-hoc community "working groups" around an area of custom post type interest (two that are obvious to me are events and real estate properties, but there are many more.) The group could establish an accepted post_type name and collaborate on a common set of custom field names and uses and possibly even create some common shared functionality (which could end up making it's way into a core plugin?)
>
> 2.) Give people a place on WordPress.org to propose new working groups and if they collect enough "+1s" (10 people or more? 25? 100?) then they get their working group.
>
> 3.) Recommend that all values used for post_type in the wp_posts table be either singular or plural (my strong preference is singular but will go with whatever the consensus is) except for in use-cases where the rule would obviously not apply. And recommend that they use dashes or underscores for post type names, one or the other.
>
> 4.) State that all post_type names prefixed with an underscore are reserved for core and core plugins (i.e. "_event") and consider the possibility of backporting at least the newer post type to that approach (i.e. "nav_menu_item" => "_nav_menu_item") if not even post, page, revision and attachment on a long term basis.
>
> Again, these are just strawman proposals; hoping that I can spark and honest and respectful discussion about the potential to  address these issues before they become a bigger mess?
>
> -Mike
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>