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

Dougal Campbell dougal at gunters.org
Wed Dec 9 16:19:10 UTC 2009


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]

For example, if you had a plugin named "Tweet Fu" (which has the slug 
'tweet-fu' in the respository), you might have an option named: 
plugin:tweet-fu:last_tweet_timestamp

Or if you have a theme that saves its own option: 
theme:my-theme-name:header_image_filename

Basically, area is the "realm" of the option, like 'plugin', 'theme', 
'core', etc., and slug is generally the plugin or theme nicename (or a 
placeholder like '_wp_' or '_transient_' for core options).

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.

-- 
Dougal Campbell <dougal at gunters.org>
http://dougal.gunters.org/
http://twitter.com/dougal
http://twitual.com/


More information about the wp-hackers mailing list