[wp-hackers] Custom Post Types and pending incompatibilities

Mike Schinkel mikeschinkel at newclarity.net
Sat Jul 10 19:59:33 UTC 2010


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



More information about the wp-hackers mailing list