When you think of uninstall, do you think of completely removing something? The official definition for the word is as follows, (uninstall) To remove completely from a system. I ask this question because I have discovered a problem that needs to be addressed by WordPress plugin authors.
Over the lifespan of a WordPress installation, there may be a number of plugins that are installed and subsequently uninstalled. Typically, the installation of a WordPress plugin consist of uploading files, folders and then activating the plugin within the admin panel. However, some plugins include a bonus. These are the plugins that create database entries either in the form of tables or data.
I’ve used WordPress for over 7 months now, and for those 7 months, I believed that when I deleted the folders and files that were attributed to a plugin, that it was in fact, uninstalled. Only now have I come to realize that this is not the case. Sure, the folders and hardcoded files for the plugin might be deleted, but if that plugin created any database entries, those are left behind unless the plugin author added the ability to delete entries made by the plugin. What does this all mean? It means that over time, your database may be filling up with garbage data that is difficult to get rid of unless your familiar with PHPMyAdmin and working with the actual database. Not to mention, playing with the actual database is risky business. All of this gook that accumulates in the database adds to its size and can cause problems somewhere down the line.
So, I got a hold of a few plugin developers and asked them what the problem was. I thought it had to do with the WordPress Core not providing a way for plugin authors to easily code in uninstall instructions. However, it appears as though this responsibility is entirely of the plugin author. When I consulted with Ronald Huereca, author of the popular plugin WP Ajax Edit Comments and asked him who was responsible for the removal of database code, he replied with:
It is the plugin author’s responsibility to delete any necessary overhead (including options and/or database tables) that a plugin might use. The plugin author can have the user do this manually or at deactivation. But at least have some kind of option.
The purpose of this post is not to chastise WordPress plugin developers but instead, raise awareness of an issue that I don’t think too many people know about. I would be grateful if any of the plugin authors out there would comment on this post and answer a few questions I had.
Why have so many plugin authors neglected to add this functionality to their plugin?
What are some solutions that plugin authors could use to easily add this option to their code?
Should there be tighter restrictions on how a plugin gets into the WordPress.org plugin database?
Looking forward to hearing your responses.
For both of my plugins, I provided uninstall capability. Whenever the user deactivates the plugin, it is effectively uninstalled, removing all data related to the plugin. The user could then do whatever they wanted with the file containing the plugin.
It was easy to do it this way because WordPress provides a hook for action upon deactivation of a plugin.
I think the issue for me is that there isn’t a clear ‘uninstall’ option for the user to select. Instead you ‘deactivate’ the plugin & that has a different expectation. E.g. in http://codex.wordpress.org/Upgrading_WordPress it’s recommended as a way of checking that your plugins play nicely with the new version. So in that scenario I would think most users would be unhappy if they lose all their configuration information at the same time.
You would then have to have an “Uninstall” function, completely separate from the normal “Deactivate” function.
When upgrading WordPress, or trouble-shooting a problem, you constantly active/deactivate plugins. When you reactivate them, you expect all of your settings to have been retained. That’s why “Uninstall” would need to be a separate function.
And then what happens when certain plugin authors don’t bother with an uninstall? They aren’t under any forced rules to offer it (Unless the WP.org directory adds them, like you said). Does that make the plugin worse really? And what if the plugin doesn’t add database entries anyway? It wouldn’t need an Uninstall option, but regular users would get confused at some plugins being able to be uninstalled, whilst others are only deactivated.
I think that adding the option would get a little more confusing than things should be. WordPress have never hidden this (“Deactivate” was a carefully chosen word I imagine). I suppose it’s just a bad assumption that has developed over time (I have it too I imagine. I’ve never gone through my database to properly remove a plugin!).
On the list of programs that waste my database space, WordPress is pretty far down the list. I don’t mind it the way it is. 🙂
Michael, you raise a lot of interesting points, most of which I hadn’t thought of while writing the article. My initial proposed solution would of been just that. Creating a seperate uninstall function that plugin authors could use that would help remove the plugin completely, even the database entries. But as you said, if a plugin doesn’t mess with the database, there is no reason for it to have the uninstall function built in.
I just wanted to raise the awareness of all WordPress users that over time, your database could become a big pile of garbage from all sorts of left over data thanks to plugins. For instance, the left over data from the Sez_Who plugin prevents me from properly importing the database. Now if that plugin would of been COMPLETELY uninstalled, I wouldn’t of had to manually delete the SQL Table Creation entries in the SQL file just so it would import successfully.
Then, on top of that problem, you have the potential of the WordPress reputation being tarnished. I might be making the problem seem like it’s worst than it is, but if enough users install-uninstall plugins and then experience numerous problems, the blame could be unintentionally shifted onto the WordPress software itself, making the software look bad.
A good insight into a problem that is not apparent to many a lay user!
Perhaps someone should write a plugin to remove the legacy “garbage” in the databases left behind by the uninstalled plugins!
Regards,
S.K
S.K. That is interesting. A plugin to remove plugins. How can you not think that is funny 🙂
I think that to have an across the board solution WordPress would have to create a new button concept on the plugins page specifically for uninstall. This could be easily done within the plugin structure by simply adding a new hook that allows the plugin designer to link to the button and have one appear if there was indeed a need to uninstall something from the database–otherwise the button might appear greyed out or not appear at all.
Right now I’ve seen people place uninstall buttons or links all over the place, if at all, so it is currently too confusing a situation for end users.
I would actually suggest that developers supply a separate file that contains the uninstall code, so that this file can be uploaded in the case where someone wants to do the uninstall. Yes, this is somewhat cumbersome, but it also prevents mistaken uninstall. And considering that plugin security isn’t necessarily a generally well done thing right now, imagine a vulnerability where your plugin database entries could be maliciously deleted.
Actually Harknell, I agree with your idea. That is the same solution I came up with in my head. However, I would only want to see the uninstall button if the plugin was deactivated. If the plugin is activated, I want the Uninstall button to be greyed out. We also have to make sure there is a confirmation message when you click on the uninstall button to protect against MISS CLICKS.
Maybe if the database contained information about the ownership of the additional records in the options table & any other tables created by plugins then there could be an overall database cleaning function. Anything that doesn’t belong to an active plugin or the WP system gets removed.
oh my… mean to say, it also accumulate space in the hosting? is it true?
I see a few issues
– The ambiguity in what ‘deactivation’ actually does. Many users of plugins expect their settings still to be there after reactivating a plugin.
– What to do if a user simply deletes the plugin instead of ‘uninstalling’ it cleanly. Nigel says we could record the ownership of options and tables but…
– WordPress plugins pretty much have access to the entire database and we’d need to convince plugin authors to play nicely and record ownership properly rather than just jump straight into the tables.
I’m currently maintaining 2 plugins on WP.org extend plugin. One of them always erase its database entry everytime it gets deactivated, and another one has its own ‘Uninstall’ button.
Yeah.. wordpress should pay more attention to this.
2pt0,
May be someone will come out with such a handy plugin too. (Perhaps you may like to do it too!) 🙂
I found that GaMerZ has provided an “Uninstall” button on the options panel in case of all his 16 plugins, which effectively removes all changes made in the options functions as well database tables created.
High time such a norm is followed by the good folks writing plugins, as a consideration to the users and viewers!
As you have suggested, it may be made as a stipulation for inclusion in the WP.org web site.
Regards,
S.K
S.K. GaMerZ is the inspiration for this post. I remember him posting about this very issue and he took it upon himself to ensure that his plugins had an uninstall feature that removed all traces of the plugin. It’s because of him that I wrote this post.
I’m glad you are mentioning this! Being a plug-in junkie I have tried almost every plug-in out there that interests me at all. I recently upgraded to WordPress 2.3.2 and had some trouble with previous plug-in database entries. By manually going through my database rows in PHP MyAdmin I eliminated over 200 rows of plug-in data that was no longer used. The UTW plug-in left the most… It would be great if ALL these plug-ins when de-activated removed their own database options.
Thanks for all the great information on Weblog Tools Collection 🙂
hah, so someone noticed. yeah i do a lot of live testing of plugins. so every month or so i’d take a database dump of only my entries, reinstall wordpress and upload the entries. a little over-techy-manual but it works for me. if there’s a faster way then let me in on it.
Clean Options can be used to clean up some of the detritus left over from deactivated plugins.
Thanks for the link Toxic, but don’t you find this to be somewhat of an oxymoron? A plugin that removes plugins?
@Jeffro2pt0, @S.K: Thanks for the compliments =D
Because most other plugins don’t. And the plugin development docs does not mention this.
Add better documentation and a plugin “de-install” in wordpress which also delete the plugin files?
I don’t think so.
Jeff,
Thank you for raising awareness to an important issue. I’m a lay developer/WP user and do not currently have the skill to go digging around in my database to extract old plugin data. I encourage the faithful WP developers to use some of the suggestions here to make the process of installation a little easier for both the plugin author and user. Thanks for informing me.
Hi
this wish is chaos – shocking – horror- sleepless nights!
before you upgrade or update you have to deactivate all plugins!
and than after the update no tags, no accounts in postnotification or something else?!
please don’t bound deactivate + clear the database together.
please….. 🙁
kindly regards
Monika
I recently installed the WordPress Database Backup plugin, and noticed that in the admin panel for it, it lists all of your ‘other’ database tables too, and lets you select them in case they are WP-related stuff (plugin tables) that ought to rolled into the backup.
This is an easy way to have a look at your database … and the accumulating detritous. It might also be a start on a way to get rid of it.
Some other systems actually have an install facility where you select a zip file on the system it uploads, unzips, and installs it. Similariy it can then be uninstalled.
Perhaps we should be looking for something similar with an install, and uninstall script that was separate from the plugin itself.
Good point.
I also adressed this issue on my (German) blog last month: http://www.probloggerworld.de/.....-tpbc/337/
A treu SQL database monster seems to be the live stat plugin called “LIVE” (see link in the article). A whooping 70mb only from LIVE trashed my SQL database.
Top Post by Category as well blows up your current SQL database.
LIVE and TPbC won’t delete the SQL entries themselves. You gotta fix that on you own via PHPadmin.
Regards,
René/ProbloggerWorld
I knew this. I just recently cleaned out my DB and found it out for myself. xD
I think the main reason the tables are not removed by deactivating a plugin is that there are several reasons you might do that:
1. Removing the plugin
2. Upgrading WordPress
3. Upgrading the plugin
In case 2 and 3 you really don’t want to lose any options you have set for a plugin.
There’s a function called delete_option you can use for cleaning out everything in the database.
I totally agree with you that it is the responsibility of the plugin developers to delete all settings and tables once a plugin has been de-activated. WordPress provides hooks which can be used by plugin developers to run uninstall process.
Thank you everyone for really putting forth some good ideas onto the table and keeping this discussion on topic and really informative. I’m learning things I never thought of while writing this piece.
@Renee You are not kidding that the LIVE plugin is a monster. Currently, that thing has over 30 thousand entries in my database. I guess what is happening is that, whenever I view the LIVE page in my administration panel, each one of those entries is being stored in the database and the plugin has no option of clearing that information out. Instead, I have to go into the SQL database with PHPMyAdmin and clear out the table entries. Ughh!
I’ve written a post coming up in a few days that details the activation and deactivation.
I don’t see how adding an option and admin page that has a checkbox asking if the user wants to uninstall is that difficult.
I’ll be sure to post about how to accomplish this in the future.
There are plugins that create DB tables that do have the uninstall feature built into the plugin’s options page and of course many that don’t. Usually these uninstalls can be found at the bottom of the a plugins options page as a “Reset and Remove” (or something similar) link. But it’s not just the plugins that create new database tables that are the problem when removing, it’s also the plugins that add files and entries to the WP core files and/or add entries into your .htaccess file that are not removed when a plugin is deleted.
Personally I don’t believe this is WordPress’s responsibility to provide an uninstall option (how many plugins are there that would require different setups?) and removing a plugin’s DB tables when deactivating by as a WP default would be absolutely disastrous. Ever hear of the proper way of upgrading? Since certain plugin authors and even a few theme authors (like K2) already supply a “reset and remove” type uninstall function for their plugins then the capability is obviously there for other authors to use for the same purpose. As far as making it a requirement for entry into the plugin directory for any plugin that makes changes to the the DB (SK2, Awsome News Announcement for example) or adds to the core files (like WP-SuperCache does which is a great plugin by the way) is a matter for further debate although it would be nice to see something like that.
With more and more “non-tech” type bloggers switching to or starting there own custom WP installs these days, it’s probably time to start thinking along these lines.
@Jacob That ought to be an interesting read. Has this issue ever been discussed on the WP-Hackers mailing list?
@Kirk I agree with your points about how the plugins that add information to your database are not the only ones causing problems.
I don’t want options or anything to change when I deactivate a plugin. What I to see is an uninstall button if the plugin was deactivated. If the plugin is activated, I want the Uninstall button to be greyed out. We also have to make sure there is a confirmation message when you click on the uninstall button to protect against MISS CLICKS.
And yes, I don’t believe this is the sole responsibility of WordPress either. However, your common WordPress end users most likely has no idea what is going on behind the scenes. Just like me, I thought I was uninstalling the plugins when I removed their files but it turns out that for some of them, I was not.
If you are the WordPress team, at what point do you place tighter restrictions on the plugins that are created for WordPress? When do you bump up the quality assurance so that, this problem isn’t likely to happen anymore because of tighter restrictions towards those plugins that edit the core code or modify the database?
@Jeffro – Thanks for the reply. You’re right to publicise the difference between uninstalling and deactivating here. Perhaps plugings like SezWho should be treated as special cases?
If a plugin makes a heavy usage of the database that could build up into a lot of data over time, then perhaps it should be expected of the author to include a real uninstall option, like you said. But I can only see that happening from the more dedicated of authors, and from the more popular of plugins. 🙁
@Michael Martin And therein lies part of the problem. There is no governing body or any type of rules or regulations that tells plugin authors what exactly they have to do. Sure, there are a few things your plugin has to abide by in order to be hosted on the WP.org Plugin database website, but those are very relaxed requirements.
As an end user, we are at the mercy of the plugin developer. I was really hoping to spread this around so that all plugin developers can see and understand this problem and include an uninstaller with their plugin if it modifies core code or adds database data.
That be great if the uninstalled plugin delete also the DB tables entry, or if there is some plugin that tell me what tables are from wordpress installation and what are from plugin – with a delete option? ;-)) .
“Perhaps someone should write a plugin to remove the legacy ‘garbage’ in the databases left behind by the uninstalled plugins!”
Are you referring, perhaps, to something like this???? 🙂
It’s very beta, but it turns up some interesting results.
As for developers, one BIG thing we can all do is to make sure that we always serialize our various options in an array. That way each plugin only has one line in the Options table. If it’s obviously and uniquely named (“joesgreatplugin_options”) then it remains relatively harmless, and easily removable if the user ever goes browsing through his options table.
Third, the difficulty of making a stand-alone uninstaller is that the plugin dev is left to screw with the direct SQL. If we’re able to work within the WordPress framework, we can use a very simple function to remove options table data…. but this basically requires us to put the “remove button on our Options screen (assuming we even have one).
I may be off on that last part — I’ll have to play with the deactivate hook and see how exactly that works. Can I entirely pre-empt the deactivation with a different function that runs first?
What I would really like to be able to (easily) do is for the deactivation command to take the user to a different page of my design. Then I can have a “Do you also want to remove options data from the database?” page that does its thing and then passes back to the normal uninstall process.
I think pretty much everyone agrees that there needs to be a separate uninstall button for the plugin, however I don’t think the plugin itself should do most of the clean up.
Instead I would like to see APIs within WordPress that allows the plugin author to create database entries, tables, files and directories specifying that they belong to the plugin. When the plugin is uninstalled, WordPress should use this information to remove everything the plugin created. With this feature in place (and used correctly), most plugins would be easily uninstallable and without having to implement any uninstall code.
I think a good solution for this issue for now (seeing WordPress does not provide an “uninstall” button in the plugin page), is to have plugin authors who uses WordPress database for the plugin functionality to provide a checkbox within their plugin admin panel which says “Remove database entry upon deactivation” and implement exactly that feature using deactivate plugin hook.
btw, I think WLTC should have a follow up post regarding this issue once a conclusion about the best way to uninstall a plugin is reached, hopefully with some insights regarding this issue from WordPress developers.
There has already been discussion on adding an uninstall button based on a WordPress Trac ticket.
However, the ticket is on hold until the new administration is finished. Also, I would have put effort into building the functionality, but since school is coming up I’m unsure how that will happen.
You might still see it in WordPress 2.5 as soon as the new administration is finished. There are a lot of enhancements I would personally like to make. I just wish the pre-activation hook would get in as it would allow you to prevent people from activating a plugin that doesn’t meet your requirements.
There is another 3 months, well two months before the betas to add this functionality.
So I mean, once the new administration pages are finished, I’ll be pushing patches and support for it.
Oh yeah, there has been discussion about an uninstaller, I believe. However, I don’t really think WP Hackers is relevant without WordPress Trac tickets backing the discussion up. Mostly you get a lot of discussions without a lot of action. When you get both discussion and action is where I usually start to pay attention.
I believe one of the conclusions to either the Trac ticket or WP-Hacker thread was that upon clicking deactivation, a popup would come up asking the user if they wanted to uninstall the ticket. If they click yes, it would take them back to the plugins page but would run a new uninstall hook for the plugin in the process, else it would just run the deactivation hook. I think it would be the best solution.
Another discussion was on having an automatic configure page which plugins could hook into, also a Trac ticket. However, that also lost stream since it was dependent on the new administration pages.
However, I mean, this will all still depend on plugin authors knowing about the hooks and using the hooks. Here is to getting the functionality into 2.5, but regardless it isn’t that difficult to do now. Also, there was a discussion on how a person can create an uninstaller on WP-Hackers a few weeks ago.
I just came across this plugin which removes ‘orphaned’ wp_options data.
http://www.mittineague.com/dev/co.php
Off to add an uninstall option to my plugin!
It may have already been said, but I know themes based on K2 have an uninstall option on the theme options page that will delete all the database options for that theme and automatically select the default theme (in other words, it deactivates the theme). It doesn’t seem like that far of a stretch to adapt to plugins.
Then you could deactivate a plugin while leaving its options intact or click a button on the plugin options page to uninstall completely. Of course, that leaves plugins without an option page out in the cold…
I think the problem with option pages is that most users do not know to look there for an uninstaller. If it was on the plugin management page, then they’ll be more likely to see it.
Yeah, it isn’t hard. I did it, so I’m pretty sure anyone can do it.
All of you have great ideas aside from having WP control this or demand uninstall. Because there are so many lay users out there giving them tools to edit the database will result in flame email to the plugin author from the users whom claim the uninstall broke their database.
Plugins that modify wp_options and other core table should somehow backup or track what ‘options’ we set so they can be removed easily by the uninstall script.
I also like have 2 ~ 3 checks that the admin is SURE that they want to remove the settings from the database, tables, etc. So no lay user shoots themself in the foot.
Yes, for a developer to casually hand the general public direct access to MySQL database structures is (too) worrisome. I have wondered myself, whether text-file (CSV) data might be alright for some kinds of plugins. Certainly, I have seen facilities calling in the Battleship MySQL to swat flies. Some applications, which generate lots of data, and/or heavily process it … that’s what MySQL is for, sure. But I am not knowledgeable enough to say whether local (in it’s own plugin directory) text-files make sense for lightweight plugin-data needs (or if it is already widespread!). It has long been done elsewhere though, and MySQL is often overkill.
I knew this reminded me of something, and I’ve just remembered what.
Firefox extensions have s disable button and a (sometimes grayed-out) uninstall button – and I’m pretty sure that nobody confuses the two.
(This comment is all about GUI, of course – I’m not suggesting that firefox extensions and WordPress plugins have much in common!)
My plugin already has this included since it has been released to the public. It will kick of all data from the DB when the user selects it with the button below, afterwards the user can select if he wants to deactivate the plugin or start again with default values (button at the bottom): http://wp-simpleviewer.fuggi82.....nspage.jpg
with all of the solutions and ideas that have been presented thus far, where do we go from here?
I’ve created a sample plugin that adds an uninstall option to plugins that have a pluginfile_uninstaller.php file. This is just to give an example of some of the ideas in this thread.
http://www.wp-fun.co.uk/2008/0.....tallation/
Would there be a way for a plugin author to build a plugin that would check to see if each of the database tables are in use by either WordPress or the Active Plugins? This new plugin could then present a screen that would show you ALL of the tables that it believed are no longer in use you could check off each of the ones you want to remove and it would basically clean-up the database.
I’m not sure if there is a way to do this short of reading through each of the plugins source to determine if it tries to do any SQL.
Just a thought..
Why is anything about wp databased into ones own pc?
Perhaps its more to do with “big brother” in case you upset somebody without worth. The true bad boys have sandboxed pc’s anyway.
Besides, it can be removed with a piddly bit of script without fear or hassle, no problem.