Every plugin that’s more than 100 lines of code has at least one setting stored in the database. The functions that come with WordPress for managing options are ok, but they can be used better.
Here’s how the scbOptions class makes your life easier as a plugin developer:
Advantages
All in one place
scbOptions stores all fields in a single database row. Ask any WP plugin author worth his salt and he will agree that that’s the way to go.
Clean up on your way out
When the plugin is uninstalled, the options will also be deleted to keep the database clean.
Usage
Creating a set of options
$defaults = array( 'color' => 'orange', 'size' => 'large', 'version' => '1.5' ); $options = new scbOptions('pumpkin_settings', __FILE__, $defaults);
The first argument is the option name.
The second arg. is a reference to the main plugin file.
The third argument is an array with default values (optional).
Accessing fields
// Get a single setting $options->color; // Result: 'orange' // Get a single setting (traditional) $options->get('color'); // Result: 'orange' // Get a selection of fields $options->get(array('color', 'size')); // Result: array([color] => orange, [size] => large) // Get all fields $options->get(); // Result: Array([color] => orange, [size] => large, [version] => 1.5)
Modifying fields
// Modify a single setting $options->color = 'blue'; // Modify a single setting (traditional) $options->set('color', 'blue'); // Modify one or more fields $options->set(array( 'color' => 'blue', 'size' => 'medium' )); // Reset all fields to default values $options->reset();
Hi,
I just wanted to say nice work, but I have one comment on this option class you are suggesting.
On our development department, we have been experiencing issues with serialization of large arrays. One solution was using the Pear unserialize function.
Pulling this through to the way WP stores options (nothing wrong with it actually…on a small scale) it can cause errors sometimes.
An alternative on the other hand, can be that a certain plugin developer prefixes the plugins’ option names, for ex.
myplug_option1
myplug_option2
…
With one simple SQL query, you can fetch all the options your plugin would require ( WHERE option_name LIKE ‘myplug_%’ ), and you can then ‘maybe_unserialize()’ the values before returning them as regular options…
I use this technique in a personal ecommerce plugin to fetch a collection of over 100 options… which would otherwise result in a gigantic array of possible problem-values as decimals and sub-arrays.
Just my 2 cents.
Kind regards,
Kim
Hello and thanks for the 2 cents.
I agree that serialized arrays are not a panacea. In your case, I would go even further and suggest a custom table for storing such a large amount of data.