WordPress Plugins – Using the Options Table Properly

Note: if you’re not a WordPress plugin developer, this probably won’t interest you.

I ran across this again today, hence my rant:

I installed a plugin from the WordPress Plugin Repository ( the place that hosts WordPress plugins so you can download them ), THEN looked through the code. This small specialty plugin added 17 options to the options table!

WP developer peeps, there is no excuse for this. By adding so many options, you clog up the options table. Unless you specify the option as an autoload, you’re using a database read every time you call get_option(). What a waste!

What should you do instead? Glad you asked!

Combine your options into an array. Easy smeasy. WordPress will store your options array as serialized data. Return get_option() to a variable at the start of your script, giving you easy access to all its components.

The WordPress core is getting sizable enough that responsible developers need to optimize their code as much as possible. Eliminating unnecessary database reads/writes is a good first step.

If you need an example, leave a comment and I’ll post one.

EDIT: as requested, here’s a couple of examples. First, what many developers do but shouldn’t:

$myoption1 = "ted";
$myoption2 = "fred";
$myoption3 = "jed";

update_option( 'myoption1', $myoption1);
update_option( 'myoption2', $myoption2);
update_option( 'myoption3', $myoption3);

Notice how the above uses 3 different options: myoption1, myoption2, myoption3. These take up 3 rows in the database, and require 3 different calls to get_option() when the data is needed. Now, 3 isn’t very many – but consider when your plugin uses 30 or 40 different options or presets ( some of mine do ). The potential to clutter up the database and cause a slowdown in your page load times is huge.

Here’s how you should code your options:

$myoptions = array( 'option1' => 'ted', 'option2' => 'fred', 'option3' => 'jed');
update_option( 'myoption', $myoptions );

And that’s all there is to it. The update_option function recognizes that you are passing an array and serializes the values for entry in the database. When you need to retrieve the options, simply call get_option into an array variable, and access from there. One call, 40 options. Lotsa overhead saved 🙂

$myoptions = get_option( 'myoption');

now, $myoptions['option1'] = 'ted', $myoptions['option2'] = 'fred', and so on.

Dealing With Duplicate Content Issues on WordPress Comments Pages

I saw a tweet today about WordPress comment page duplication issues related to SEO. While the word is still out as to just how much damage it does or doesn’t do to your ability to get found by the Great G, this specific problem is relatively easily fixed — and not by disabling the paged comments feature that the Wizards of WordPress have so kindly coded for us (you ever had a post with 300 comments? you’ll understand what I mean…).

All it takes is a little bit of code in the functions.php file in your theme. If you’re uncomfortable editing your theme files or don’t know how, leave a comment and I’ll whip up a little plugin. This may be a good time to learn to edit your files, though 🙂

This little bit of code doesn’t affect anything but WordPress comment pages. If you use WordPress for something other than a plain-vanilla blog, you may need the horsepower of Yoast’s Canonical URLs plugin for WordPress.

So in your functions.php file, insert the following code (I split the echo lines up for clarity, normally they’d be all on one line):

function canonical_for_comments() {
 global $cpage, $post;
 if ( $cpage > 1 ) :
  echo "\n";
  echo "<link rel='canonical' href='";
  echo get_permalink( $post->ID );
  echo "' />\n";
add_action( 'wp_head', 'canonical_for_comments' );

Make sure you paste the code before the last ?> characters at the end of the file.

For those of you who care, here’s a quick explanation of what the above code does — you’ll get a short intro into the behind-the-scenes functioning of WordPress.

When a visitor navigates beyond the first page of comments, the variable $cpage contains the page # that’s being displayed. The $post variable contains all of the information about the post. The function tests to see if we’re on a comments page greater than 1, if so, it spits out the <link rel=…./> characters. But where does it spit them?

That’s controlled by the add_action line. We’re telling WordPress that when it’s building the head section (‘wp-head’), to add our special ‘canonical_for_comments’ function.

Simple, easy schmeezy.