Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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?

share|improve this question
    
FYI community wiki for questions was limited to moderators while back. –  Rarst Feb 5 '11 at 21:39
add comment

5 Answers

up vote 1 down vote accepted

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.

share|improve this answer
    
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 Feb 5 '11 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 Feb 5 '11 at 21:50
add comment

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.

share|improve this answer
    
It's a database. User can create really many style without needing you to care a lot. –  hakre Feb 5 '11 at 22:08
add comment

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.

share|improve this answer
    
That is essentially my answer, correct? –  Raphael Feb 6 '11 at 0:10
    
Hum ,You tell us. –  Bainternet Feb 6 '11 at 5:50
add comment

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.

share|improve this answer
    
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 Feb 6 '11 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 Feb 6 '11 at 0:28
    
I understand what you are getting at, thanks. –  Raphael Feb 6 '11 at 1:28
add comment

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; ?>">
share|improve this answer
    
How does this scale when a user wants to have a dozen different background classes, each to use from a different shortcode? –  Raphael Feb 7 '11 at 15:22
    
via some text field (custom class name) or via some drop-down / options field (pre defined class names). –  kaiser Feb 7 '11 at 18:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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