I develop a plugin that has a not too small number of settings. So far, there has been a fixed number of them, so I store them in a Wordpress option. Now I consider letting users define (an arbitrary number of) styles, that is sets of options. Since these will still be rather general options, none of the categories listed in the Codex really fits.

Storing all that stuff in one option is clearly not a good idea, but creating a whole database tables does not feel right, either. What are your recommendations?

Note that I post one idea I have as an answer in order to separate it from the question. Would mark the question CW, but that seems to be disabled here?

  • FYI community wiki for questions was limited to moderators while back.
    – Rarst
    Commented Feb 5, 2011 at 21:39

5 Answers 5


The hierarchy of storing data roughly goes like this (from less functional/complex to more):

  1. Transients API
  2. Options API
  3. Settings API
  4. Database Tables
  5. Custom file cache

Since from your description Options are too limited and database too complex, I would look at Settings.

  • Oh, I use settings to manage my options page already. As I understand them, they just wrap options for ease of management. So the same limitations as for options hold, don't they? Or do I misunderstand something?
    – Raphael
    Commented Feb 5, 2011 at 21:43
  • 1
    @Raphael Options is basic database storage mechanism in WP, both Transients and Settings are built on top of Options to use that storage in more specific ways. So if Options mechanics are definitely not a fit then you are probably stuck with custom database table.
    – Rarst
    Commented Feb 5, 2011 at 21:50

To best answer your question I suggest to not answer it ;)

Or more precisely: Encapsulate what varies.

As you right now do not know how / where to store your settings, create objects that are providing an interface to your store and that are hiding the whole storing away from the rest of your plugin.

Some example code:

interface myStore {
    const PREFIX = 'myStore';
    public function get($name);
    public function set($name, $value);
 * option storage: all in one wordpress option
class myStore_Options implements myStore {
    private $data = null;
    private $optionName = '';
    private init() {
        if (null===$this->data) {
            $this->optionName = myStore::PREFIX.'_options';
            $this->data = get_option($this->optionName, array());
    public function get($name) {
        if (array_key_exists($this->data, $name)
            return $this->data[$name];
        return '';
    public function set($name, $value) {
        $this->data[$name] = $value;
        update_option($this->optionName, $this->data);
$store = new MyStore_Options();

Everywhere in your code you can then use $store->get('settingName') regardless of which storage layer you implement.

You can now create another myStore_xxxx class implementing the myStore interface, e.g. for the styles. It will work exactly the same, but you can put the styles to somewhere else.

Normally you only need to read and write settings, so you would only need two functions here in the interface.

You can then - over time or while you continue to extend the number of options values / styles - change the storage methodology w/o affecting your plugin code.

  • I would consider this good general advice, but it does not answer my question. In your terms, I am looking for a decent implementation now. (Although I do not encapsulate that properly atm, bad me ;)) Also, does not WP itself provide exactly that level of abstraction?
    – Raphael
    Commented Feb 6, 2011 at 0:11
  • @Raphael - WP does provide so on a certain level, but regarding what you want to do I would put some air between your plugin and WP to stay flexible in the long run. I'll try to extend my answer a bit with the info you provided, let me look.
    – hakre
    Commented Feb 6, 2011 at 0:28

Add one Wordpress option per style. Since each style has a fixed size and is used in many places, the basic requirement for this technique in the Codex is fulfilled. Options should be named like $pluginname_style_$name.

Retrieving one style with known name is very natural, idiomatic and (hopefully) fast then. Retrieving/deleting all styles is easily possible due to the naming scheme.

Assuming users do not create too many (i.e. at most tens, not hundreds) styles, the options table should not be bloated too much.

  • It's a database. User can create really many style without needing you to care a lot.
    – hakre
    Commented Feb 5, 2011 at 22:08

you can create an array as you dataset and save it into one option for every new style something like:

$new['size'] = ...
$new['fixed'] = ...
$new['blabla'] = ...


hope you get the idea.

  • That is essentially my answer, correct?
    – Raphael
    Commented Feb 6, 2011 at 0:10
  • Hum ,You tell us.
    – Bainternet
    Commented Feb 6, 2011 at 5:50

The Settings API cares about making a performant array and store your options in only one DB-field. You can add to this field from different pages as long as you define to use the same field ("settings section" afaik) on other pages. Maybe you should use different sections for different parts (i.e. styles), so you could store it in a global avaible $var like


$my_plugin_styles = get_option('option_name');

<span style="<?php echo $my_plugin_styles->background; ?>">

or (even better):

<span class="<?php echo $my_plugin_styles->background_class; ?>">
  • How does this scale when a user wants to have a dozen different background classes, each to use from a different shortcode?
    – Raphael
    Commented Feb 7, 2011 at 15:22
  • via some text field (custom class name) or via some drop-down / options field (pre defined class names).
    – kaiser
    Commented Feb 7, 2011 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.