How to store a medium amount of options?

3 Views

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?

Read More

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?

Post Views: 3

Related posts

Leave a Reply

5 comments

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

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

  4. 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'] = ...

update_option('new_option_name',$new);

    hope you get the idea.

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

    call:

    $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; ?>">