Don’t you just hate it.  You install a program on your computer to try it out, then when you go to un-install it, it leaves files scattered all over your system.  Whether it’s in the application folder that it can’t delete, or in the Application Data folder or system32, it’s not easy to find a program that cleans up after itself properly.  I’ve got more of a chance of getting my kids to tidy up the lounge room after they’ve got all the Lego out.

This issue isn’t just limited to Windows applications though.  I’ve noticed the same problem with a lot of WordPress plugins.  It may just be leaving a couple of config options in the wp_options table, or it may be as much as leaving multiple custom db tables behind or even files in the WordPress install folder.  I’m of the opinion that once you remove a plugin, it should be gone without a trace.

Now, for plugin developers, WordPress provides a simple way to do this.  The register_deactivation_hook() method lets you register a function to be called when your plugin is deactivated.  In there you can put any cleanup code to remove options, tables files, etc.

But…

This is not without it’s problems.  Often plugins require you to enter some complex config information or they may build up a history that you may not want to lose (eg. a spam filter that learns from what you mark as spam).  Sometimes you need to disable plugins temporarily, in fact the WordPress update instructions say that you should deactivate all your plugins prior to upgrading.

Also, the automatic plugin updates system introduced into WordPress deactivates plugins before it installs the updated version.  So if you put the cleanup tasks into the deactivation hook method, all the user’s settings would be gone after updating.  This really isn’t a good option.

What would be better is if the WordPress plugin admin page had 2 buttons for each plugin: deactivate & uninstall.  Deactivate would do what it does now – turn off the plugin, but leave it in place.   Uninstall would completely remove the plugin, including deleting the plugin file & firing a separate uninstallation hook callback.  Developers could then put all their cleanup code in there, with no fear that users were going to lose settings during an upgrade.

What to do for now

I think for the time being it would be best if developers included a ‘remove all data’ button on their plugin’s options page (if it has one).  This button would remove all trace of the plugin (other than deleting the plugin itself) so that the user can then deactivate it.  This button should probably be restricted to admin users and have some form of confirmation on it. I’ve added a button to do this in the latest release of the FriendFeed Comments Plugin.

There’s already a post about this ideas section of WordPress.org, and a discussion about it on Weblog Tools Collection.  I’m hoping that this gets noticed, because it would be great if developers had a simple way of tidying up after themselves.

If this is something that matters to you, please go vote up this idea on WordPress.org.