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

[Stephen Rider]

On Dec 9, 2009, at 10:19 AM, Dougal Campbell 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
> 
> 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).

I do almost exactly that in a tutorial I wrote a while back:

***quote***
First off, let's decide what to call our new single setting. We might just go with “shrinkylink”, or “shrinkylink_settings”, but part of the point of this exercise is to keep the options table tidy; and in the interests of clarity, I'd like to go the further step of specifying in the option name that it was made by a plugin. Let's use “plugin_shrinkylink_settings".
***end quote***

On Dec 9, 2009, at 12:43 PM, Otto wrote:

> 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.

Heh.  And that's what the tutorial was showing authors how to do!  ;-)

<http://striderweb.com/nerdaphernalia/2008/07/consolidate-options-with-arrays/>

Stephen




-- 
Stephen Rider
http://striderweb.com/