[wp-hackers] Storing Arbitrary Data as Custom Post Types
Stephen Rider
wp-hackers at striderweb.com
Thu Dec 10 03:40:54 UTC 2009
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/
More information about the wp-hackers
mailing list