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

[Mike Schinkel]

On Dec 9, 2009, at 11:19 AM, Dougal Campbell wrote:
> On Dec 8 2009 6:45 PM, Mike Schinkel wrote:
>> 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.
>>   
> 
> Focusing on just the part of this that deals with name collisions between plugins... Back in August, I started a draft post where I was going to propose a standard format for plugin option names, in order to reduce namespace collisions. After writing a few paragraphs, I decided not to publish it, because it was pretty esoteric, probably not of interest except to a few developers, and I had doubts that enough developers would actually adopt anything like it. But since there's a discussion going that's touching on the subject, I now wonder if I should touch my post up and publish it?
> 
> In a nutshell, my proposal was going to be that we use a naming convention like: [area]:[slug]:[name]
> 
> ...
> 
> Any interest in me publishing the post with more details of the pros and cons? As I said, I doubt that it's anything that will take the world by storm, but perhaps the idea could evolve into some sort of suggested Best Practice.

That's an interesting idea and I'd be interested in reading it if you have the time to publish it.  I think is makes sense to decide upon and then publish a best practice.

Point of note however, I wasn't addressing namespace collisions so much as advocating how a shared baseline plugin for a common use case that is deemed not applicable to the core (like adding Twitter or Event support) which would resolve the issue of having two different plugins use different names for options that are effectively the same by simply bypassing the issue.

-Mike