[wp-hackers] Custom Post Types and pending incompatibilities

[Mike Schinkel]

On Jul 13, 2010, at 1:46 PM, Simon Blackbourn wrote:
> I strongly believe that being open with post type & custom fields rather
> than namespacing them is the way to go in the long term. Closing things off
> and saying "this is my post type - hands off everyone else!" is antithetical
> to the whole ethos of the WordPress project.

Point of note, I don't think anyone is saying "Hands off."  The concept is instead for someone to think "I'm working on something and I don't want to accidentally tread on anything someone else is doing or might do so I'm going to do it off in a corner where my stuff can't hurt anyone."  

The "wp_" prefix isn't "Hands off of my post type" either, it's just "Don't start your post type with 'wp_'  because if you do it will almost certainly conflict with something added to WP in the future." (that assumes the 'wp_' convention would be adopted by the core team but even if not that is what was proposed, not a "hands off.")  

> But rather than setting up yet more working groups and discussion forum,
> etc, which seems to me over-bureaucratic and unlikely to result in success,

No more bureaucratic than the hackers list and trac+codex.  That works.

> what if plugin authors simply put the information visibly on their plugin
> page, then over time 'the market' decides and those plugins that don't
> follow the standard set by others will become less popular.

Problems with that are several fold, but can be easily illustrated by ancient Chinese proverb:

Man with one watch knows the time; man with many watches never sure.

> Clearly stating the post type and custom fields on your plugin page would
> encourage other developers to use the same type/fields in their plugin (or
> not to use the same if they want to avoid conflict). They could then say
> "compatible with the Blah Events plugin".

So where would the specs of "Blah Events plugin" be posted?  (Back to the need for a central point of authority.)

> So rather than having to dig through code to find these things out, it's
> right there out in the open on the plugin page for all to see.

A central place can be open too.

> It might take a while to get the ball rolling, but once it gains critical
> mass then take-up should grow. Just a few high profile plugin authors doing
> this and writing about it on their blogs should kickstart things.

If this would work there would already be a similar movement sorted in the Drupal community.  I could write a lot more about why it won't work, but I think Kevin Kelly tells a story in his book "New Rules for the New Economy" that says it much better than anything I could write:

"Without some element of governance from the top, bottom-up control will freeze when options are many. Without some element of leadership, the many at the bottom will be paralyzed with choices."

To drive the point home you can read his anecdote in the five (5) paragraphs that precede the above quote here:

http://www.kk.org/newrules/newrules-1.html

BTW, for those who have never read "New Rules for the New Economy", highly recommended. If there were only one business of technology book I could read for the rest of my life I'd still pick it.


On Jul 13, 2010, at 4:28 PM, Edward de Leau wrote:
> its still a bit unclear without some architectural guidelines that would be
> handy to add in the mix of standardization.
> 
> I think the thing is that every software project touching this area is in
> the same boat. 

I think any attempt to model an event perfectly (or anything else for that matter) would by definition be crushed by it's own weight, and fail miserably.

Instead what I've been discussing would be lightweight and basic structures that cover the well-known pattern upon which most reasonable people agree and leave anything else to specific plugins.  So in a sense, plugins that implemented a given well known post type would have their own "core" set of custom fields and maybe some other aspects.

And there is nothing to say there couldn't be multiple plugins that address similar aspects differently.  For example, maybe there would be a generic "Event" post type, but  then another group creates a "Concert" post type because they need something more specific than "Event" can and will be. Would having both "Event" and "Concert" be perfect, after all plugins that work with Event probably won't work with Concert?  No, it wouldn't be perfect; life isn't perfect either. But it would be better than total chaos.

Further, someone might choose to create "Simple Event" in addition to "Event" because they are not happy with the direction of "Event."  That could be okay too.

The less process applied to this the better; what is simply needed IMO is a well-known central place to gather to discuss and document efforts.

> I don't think there is an essential difference between
> taxonomies/terms/term-relationship and cpt in terms of what they are. I
> really would like some theoretical background on that  to determine when to
> use movie as a taxonomy term and when as a CPT and when as a custom field.

I agree that the namespacing problem is definitely similar between CPTs and taxonomy terms, if not the same.  

OTOH, CPTs represent a much greater opportunity for benefit if interoperability can be achieved. CPTs can form the basic of complete modules including sophisticated workflow. High level business functionality can be built around CPTs whereas taxonomies not so much.  Taxonomies can be used to elaborate ends but fundamentally they really are just about classifying content.  CPTs, on the other hand, enable end-user benefits in a wide reaching manner that taxonomies simply can't match.

On Jul 13, 2010, at 1:46 PM, Simon Blackbourn wrote:
> Which then raises the question as to whether there should be some consistent
> place/format on the wp.org plugin pages for displaying this information?
> (either in the FAQ or Other Notes?)

Basically, that's what I've been suggesting, a central place.  

Anyway, I'm going to go ahead and put a stake in the ground by adding my ideas to the codex as soon as I have a spare hour to work on it.  From there we can see how it works or if it needs to be adjusted.

-Mike