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

Peter van der Does peter at avirtualhome.com
Wed Mar 24 19:28:24 UTC 2010


On Wed, 24 Mar 2010 12:56:42 -0500
"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.
> 
> 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.
> 
> Denormalization also means I couldn't have any systems integration or
> monitoring on database values without custom plugins. 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.
> 
> There are autoload features of blog options tables which many plugins
> are not taking advantage of.
> 
> There may also be performance penalties to serializing and
> deserializing arrays all the time that cause performance problems on
> high traffic sites.
> 
> Correct practice should be to avoid serialized arrays where possible
> and use proper prefixing in blog options to avoid collisions with
> other plugins.
> 
> --
> 
> Jason Potkanski
> Tribune Technology
> 
I understand what you are saying, so what is your solution to this
problem?

Storing every option separately in the WordPress options table creates
an overhead on MySQL calls. Reading the database 10 times for 10
options would be a lot slower as calling the database 1 times and
unserializing the option.

Currently under WordPress you either have to read the database 10 times
for 10 different options or serialize the data and use 1 database call.
I think the 1 call would be quicker.

I can think of a solution that would take out the serialization but it means rewriting the
get/update/set_option functions and adding a table.


-- 
Peter van der Does

GPG key: E77E8E98

IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes

WordPress Plugin Developer
Blog: http://blog.avirtualhome.com
Forums: http://forums.avirtualhome.com
Twitter: @avhsoftware


More information about the wp-hackers mailing list