Cleaning up after the WordPress widget party
Posted by Leonid Mamchenkov on August 11, 2007
In one of the recent posts – “Advanced Widgets. Widgets with controls.” – we saw how to create WordPress widgets, which could have configuration options. In one of the comments to that post, Matthew Smith, asked a very good question:
do the widgets leave settings in the database upon removal? Should these be cleaned up using a hook like
unregister_widget()(if it exists, I haven’t looked yet)? Or does WordPress do this automatically?
Nicely spotted, Matthew! Thank you.
Indeed, what happens there?
Widget settings are stored in regular WordPress options. Some widgets can be re-used several times (like Text widget and RSS widget). This can cause plenty of data to be flowing around. That, in turn, can affect web site’s performance and server’s memory usage.
What can we do about it? It’s obvious that we have to do some sort of clean-up routine, but how, when and where?
To answer those questions, let’s refresh our memory with how we got ourselves into that mess in the first place. WordPress options are updated and populate from within our widget control. Here is the control code that we used for that article:
Here we see the call to update_option(), which populates the database with our stuff. This routine is registered as widget control, using the following line (again, the code is from the previous article):
Here is a call to register_widget_control() function. This is how we add stuff. So, to remove stuff, there should be something like unregister_widget_control() somewhere. Let’s look through WordPress code for a bit… ah, here it is, found it! wp-includes/widgets.php (no link to WordPress Source this time, as it features version 2.1-alpha2, which didn’t have widgets yet, so use your own copy of WordPress for reference)has definitions of all widget things that we saw registering – unregister_sidebar(), unregister_sidebar_widget(), and unregister_widget_control() .
OK, now that we know that it would be nice to call unregister_widget_control() and delete_option() for our widget, where is the best place to do so? I mean, if we just add those calls to our widget file, it will get unregistered and we won’t be able to use it. How can we know when is our widget in use and when it’s not and when is it the best time to do the cleanup?
The answer to that, of course, depends a lot on how you do things. There are many places to create widgets (themes, plugins), so there is no single recipe here. But from the first glance, it seems, that putting all widget stuff into a plugin makes sense. When the plugin is activated, both the widget and its control are registered, and the database option is populated. When the plugin is deactivated, the widget and the control are unregistered and the database option cleaned up.
We’ll look at how to create widget plugins in one of the upcoming posts. (There are still a few issues in that area that I need to figure out before I can do a full blown post on that.)