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

[Dougal Campbell]

On Dec 9 2009 1:43 PM, Otto wrote:
> On Wed, Dec 9, 2009 at 10:19 AM, Dougal Campbell<dougal at gunters.org>  wrote:
>    
>> 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
>>      
> Generally speaking, most plugins should be using a single option
> holding an array of their settings. I tend to go with
> pluginname-options, personally.
>
> Any "standard" should take this into account, as keeping every option
> in a separate row can be bad practice.
>    

I think part of the reason that consolidating multiple options into a 
single array is considered best-practice now, is *because of* the 
current state of option chaos. That, and the fact that you don't have to 
make 10 separate db calls to get 10 different options. But if the 
options were namespaced consistently you could just SELECT ... WHERE 
option_name LIKE 'plugin:foo-plug:%' and get all your info in one call 
anyways.

Regardless, even if everyone used an array for all options (which is 
fine for probably 99% of the plugins out there), the namespacing idea 
would still make it easier to make sense of things in those rare cases 
when you have to dive directly into the table for some reason.

Again, I'm not sure whether or not its an idea worth trying to champion. 
But at the least, I figure it's at least worth seeing if some more solid 
best-practices could be extracted from the discussion. Currently 
(AFAIK), the extent of best-practices around saving options is "store 
all values together in an array whenever possible" and "prefix your 
option name", with little guidance as to a prefix format.

Do we *need* to define a suggested prefix format? I dunno -- maybe it's 
overkill. There's no easy way to enforce it without making changes to 
core (though I have some ideas about that). Would a consistent prefix 
format be useful? That's what I'd like us to discuss.

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