[wp-hackers] Storing Arbitrary Data as Custom Post Types

[Mike Schinkel]

On Dec 8, 2009, at 6:22 PM, Christopher O'Connell wrote:
>> Now with custom post types most will be using custom fields (though not
>> all) but we still have the compatibility problem.  Both plugins use an
>> "event" post type but one plugin uses custom fields called "Start Date" and
>> "Start Time" and another uses "Event Date" and "Event Time."  Now both
>> provide complimentary functionality but because they use incompatible custom
>> fields they can't be used together.  That's the problem a shared baseline
>> events plugin could solve.
> Well, I'll go ahead and throw out on the open list something that I've
> already discussed with a couple of people individually -- a way of
> abstracting away the actual storage of data using something like object
> persistence (don't read too much into the word) on top of the posts table.
> 
> In essence, I would very much like to be able to simply define a type (the
> following example XML is for show only):...

Without commenting on the worth of the idea (because I haven't considered how it would work in all scenarios yet) I will say that the idea is orthogonal to the problem of mismatched names across plugins.  Using the approach you propose we'll still have the problem where one plugin called a data item "Start Date" and another calls it "Event Date."  

Yes those two data elements can live in harmony with each other (that's no different from custom fields that are already in WordPress) but that still doesn't allow the two plugins to work together by sharing data. Until they somehow agree that an event's starting date is  named either "Start Date" or "Event Date" then they will be incompatibility and the sum won't be greater than the parts.

That said, I've got no input at the moment on the rest of the proposal.  Still pondering it.

-Mike