[wp-hackers] Custom Post Types and pending incompatibilities

[Mike Schinkel]

On Jul 12, 2010, at 8:39 AM, Michael Pretty wrote:
> I first want to say that I somewhat disagree with the idea of namespacing post types.  Ideally, content shouldn't be tied to the plugin that manages it.  If my site uses events that are either created by a plugin or a theme and I want to switch to a new plugin that manages that content, I should be able to without having to recreate all of those events.  There was a wp-hackers thread a little bit ago about standardizing geo-data so it could be shared amongst plugins.  I think the fields that shape into something like an event or product should also be somewhat standardized.

Great comments Michael.  My thoughts that started this thread are actually more compatible with your thoughts than less. I agree that post types shared across plugins would be an ideal outcome, more so then having every post type namespaced.

I think there is room for both but the current situation has us in a bit of "no man's land."  On the shared post types it's not really realistic to expect what you envision unless there is some collaboration amongst (some of) the people who create and use those post types. Without collaboration we'll arbitrarily get "Event" plugins that name the custom fields that denotes where the event takes place as "venue", "location", "event_loc", "facility", etc.  Clearly you see how that won't enable shared use, right?

To enable this collaboration doesn't have to be complicated, it could be as simple adding a section to the CPT codex page with links to the shared post types to discuss and a suggestion that to discuss a new that the person doing it create a google mailing list for discussion and a new coded page for each.  

***
Actually, if there are no significant objections to me doing that I'll go ahead and update the codex to that effect and see where it evolves.
***

Included with this codex could be evolving best practices on how to build plugins and themes with CPTs that won't conflict but that will share and the evolving list of "recommended" custom fields to add and anything else that needs to be recommended.  

***
As I'm writing this I realize I'm potentially coining a term, i.e. "Shared Post Types."  Is this term acceptable and if not, is there a better one?
***

On the namespaced side, there are going to be people who create custom post types who don't want to collaborate about it at all. They just want to add to their theme or their clients custom post type and move on. They are often heads down on a project and are not contributing to the community. But these people are leveraging WordPress and many things they do stupidly will reflect negatively on the client's perception of WordPress.  Better to recommend these people namespace their post types than have their code cause conflict with plugins down the road, right?

> As for future compatibility with core post types, I really hope that core doesn't ever add any more post types.  If anything, I'd prefer if posts and pages were no longer built in.  With custom post types and taxonomies, we have really opened up the types of web-apps for which WordPress can be the backbone.  Then posts and pages could be a core plugin automatically included in upgrades and installs.

That's a really interesting perspective, and one I really like.  I guess it depends on what the core team decides; doesn't look good based on what Andrew said but it remains to be seen.

> On Mon, Jul 12, 2010 at 8:39 AM, Michael Pretty <mpretty at voceconnect.com>wrote:
> 
>> If anything, I'd prefer if posts and pages were no longer built in. ... Then
>> posts and pages could be a core plugin automatically included in upgrades
>> and installs.
> 
> They'll always be built in, but I'd like to see them become like any other
> post type (which includes the ability for another plugin to unregister them
> without the sky falling), and I imagine we'll be heading further in that
> direction in future releases. Same goes for tags and categories.

It would really be nice to be able to avoid initializing unwanted post types (or most anything else for that matter.)  It really feels like bloat to me to have WordPress initialize something and then require me to remove it. Sure would be nice if in a config file we could remove the code that tells WordPress that we want something instead of having to remove them after they are added.

> Just to clarify the last part, without turning this into a discussion on
> that. The core plugin experiment is still evolving, but one thing that has
> never been considered is that any of them will be bundled.

"Not bundled?"  Can you clarify please?  I hope this doesn't mean what I think it means?  Without bundling you get very few of the benefits that (some of us) have envisioned we'd finally get from core plugins.

Of course if it's an issue of download size then "virtual bundling" addresses the same needs.  For example, having a section for core plugins which lists all of the core plugins with a brief description that allows the user to install each of them easily. This would be separate from the plugin repository search which really requires someone to find and then decided which plugin to choose to meet their needs.

If you need a new thread to discuss this issue, please do...  

-Mike