only you can decide how many is too many. If your site does everything you want it to do, if the response times are OK with you, if it doesn’t fry the hardware every other weekend, if your bandwidth consumption is within your budgets, if … you get the idea. :)

P.S.: good job with the theme there

Yes, there is a way to do things on theme switch. The way it works is like this (from wp-admin/themes.php file):

1. User clicks on activation of new theme in the admin interface.
2. Option ‘template’ is updated with the new value (if set in the URL)
3. Option ’stylesheet’ is updated with the new value (if set in the URL)
4. Action ’switch_theme’ is called with parameter of current theme (retun value of get_current_theme() function which is defined in wp-includes/theme.php).

So you can hook to ’switch_theme’ action and check if the name of the supplied theme is NOT the same as your theme, then do the clean-up stuff.

Performance issue is a whole topic on its own. There are many variables. Even the question that you mention depends on the way you have things set up. Opening and reading one file is faster than many files. But many files can be conditioned and open/read only when needed. And stuff like that…

I hope we’ll touch WordPress optimization in some of the upcoming posts, even though I haven’t done much of it myself (but there is a guy now interested to do guest blogging on WordPress Bits about this subject).

Because I am currently focusing on theme design (and haven’t moved to plugins or more in-depth core tinkering), I wonder if there is a way to hook the function that changes themes (once again, I don’t have time to look right now). If so, when your theme is deactivated you could have a “cleanup” function that removes all preferences related to your widgets and theme (for more advanced themes).

Another interesting point was brought up on the performance side of things; I need to do a more indepth study of the performance effect of widgets, plugins, and other files. For instance, is it faster to place all your widget code in a single file (functions.php) or is it faster to uses include() statements to pull in the the widgets (because of overhead involved in opening files, etc)?

I have really enjoyed your articles and they definitely make it a bit easier to jump into wp hacking (especially since I have more knowledge of C and java than php and mysql).

Thanks for the link. Yeah, the tool looks like the best shot possible without WordPress actually registering plugin options.

Here are a couple of scenarios that would be almost impossible to catch with a plugin like this:

Scenario 1 (option name is a constant):


define(OPTION_NAME,'my_ugly_option');
add_option(OPTION_NAME, 'test value', 'test description');


Scenario 2 (option name is a dynamically built variable):


$option_name_prefix = 'my_ugly_';
$option_name_test = 'test';
$full_option_name = $option_name_prefix . $option_name_test;
add_option($full_option_name,'test','test description);


However, the plugin might still be useful for catching most of the stuff out there. I see the examples are all about RSS feeds saved in the options table – it makes a lot of sense to clear those out, as they tend to grow easily.

you can cleanup your options table using any SQL administration tool (PHPMyAdmin, for example). Make sure to saave the table as it is before you do any changes, so that you can restore and try again, if something goes wrong. ;)