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

Christopher O'Connell jwriteclub at gmail.com
Wed Dec 9 01:11:11 UTC 2009

Well, that's more or less where the canonical plugins come in: If each
canonical plugin adheres to a specification for storing data (whether it is
what I have proposed or something else) than other plugins could access the
data of canonical plugins quite simply.

The advantage of my proposed solution is that other plugins simply need to
load the definition file from a canonical plugin (presumably somewhere in
wp-plugins) in order to access that data.

Indeed I might go so far as to suggest that part of the requirements for
canonical plugins is that those that store data do so in some consistent

~ Christopher

On Tue, Dec 8, 2009 at 4:45 PM, Mike Schinkel
<mikeschinkel at newclarity.net>wrote:

> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list