[wp-hackers] How do you store multiple plugin options

[Otto]

On Wed, Mar 24, 2010 at 12:56 PM, Potkanski, Jason
<jpotkanski at tribune.com> wrote:
> Storing database variables in an array should be considered a bad practice. Doing this is as an convenient  hack that shortens plugin design but has significant consequences.

Many people disagree with you on this. I'm one of those people.

Serializing your options is not a "hack". It's the preferred method. Why?
- Speed: Pulling one row out of the database is faster than pulling
dozens of them.
- Simplicity: Having my options all together makes them easier to
reference instead of having dozens of get_options calls.
- Ease of design: Making settings pages which all use similar options
is easier this way. No need for dozens of "register_setting" calls,
dozens of slow get_options calls hitting the memory cache or the
database, reduced numbers of SQL queries, etc.

> Serialized data in the blog options table denormalizes the database. ReCaptcha uses one blog option setting called reCaptcha. If I want to update the keys across all my blogs in a wordpress MU install, I can not do it via SQL alone, I have to write a php plugin to tinker with the values. (Yes, I know reCaptcha has MU installation option and configuration file). Where I could have help from a DBA to fix something, I now need a developer.

MySQL has search and replace capabilities which work very nicely,
actually, and they can search and replace inside serialized data just
as easily as they can in non-serialized data. You don't need a
developer to adjust things. Although it does strike me as rather
trivial to write php code which basically says "include wp-load.php;
$o = get_option('whatever'); $o['whatever'] = new value;
update_option('whatever',$o);"

> Denormalization also means I couldn't have any systems integration or monitoring on database values without custom plugins.

They're stored as strings. What's so hard about monitoring strings?

> Other programming languages such as Java or Ruby don't have the same serialization functions PHP does, so any other development work that may need access to Wordpress data is restricted to PHP.

Java has tons and tons of serialization stuff, actually. I suppose
you've never seen "implements Serializable"?

Admittedly, the syntax is not the same between the two, in which case
you could either implement a parser (google will find one for you
quickly), or you could switch the code to use a common interchange
format. Probably the easiest way would be to use JSON. Or perhaps XML,
if you swing that way.

> There are autoload features of blog options tables which many plugins are not taking advantage of.

Autoload defaults to enabled, so unless the plugin specifically
disables it for its own options, then it is taking advantage of it.

> There may also be performance penalties to serializing and deserializing arrays all the time that cause performance problems on high traffic sites.

Serialization is built into the WP core. ALL options in WordPress get
serialized and unserialized. If performance was a problem, then it
already would be.

> Correct practice should be to avoid serialized arrays where possible and use proper prefixing in blog options to avoid collisions with other plugins.

I disagree. Correct practice would be to store your options in a
single array as much as possible and to let WordPress handle the
serialization for you as necessary. Only separate options out when you
have a different load case for them (such as options you only need in
specific places and not every time, large options, etc).

-Otto