[wp-hackers] Custom Post Types and pending incompatibilities

[Paul]

Personally I can't say I like the idea of theses solutions. Having a codex page or central site where you need to somehow register your post type name just seems wrong to me. Too many extra steps to just through. 

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

One idea for the core WP side is to have all the post types proceeded with wp_ and make this reserves for all core post types to that plugin authors cannot register anything beginning with 'wp_'.

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

I agree with your thought here but don't really see a way to control this. It sort of goes against the openness of the WordPress plugin architecture. Consider how many Event/Calendar plugins are currently on WordPress.org (dozens). Some are great and do 75% of what I need. Others not so much. Even without the new custom post type functionality can you see a way to tell these plugin authors "Hey, if you plan to develop an Event/Calendar plugin it must meet this list of function and custom field requirements.". Again, I say it goes against the openness of the infrastructure which makes WordPress what it is. Nor do I like the thought that via a community there will be a combined effort to develop a single kick-ass Event/Calendar plugin. Because my needs for an Events plugin are not the same as your or others. I like having dozens of choices. 

A bigger question is who decided what warrant putting these working groups together?


> 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.
The 'Digg' effect. Personally I don't see it working for any of my client sites. Sorry. 

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

Yeah, but you are talking about the first parameter to the register_post_type function which is different than the labels. I can register an Events custom type as 'THX1138'. The post type 'key' really is insignificant except it needs to be unique for my post type needs. Personally, I worry about having this action in the init process. Why is it required to register a post type for every page load? Why is this not done once like when a plugin is activated? But I digress. 

> 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 my comment from above. Underscore works but why not 'wp_' like most of the functions in core. 



On Jul 10, 2010, at 3:59 PM, Mike Schinkel 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