post-page

Uninstall – Is There Such A Thing?

67
responses
by
 
on
January 7th, 2008
in
WordPress Plugins
heading
heading
heading
67
Responses

 

Comments

  1. Nick (1 comments.) says:

    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.

  2. Nigel Dunn (2 comments.) says:

    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.

  3. Michael Martin (5 comments.) says:

    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. :)

  4. Jeffro2pt0 (164 comments.) says:

    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.

  5. S.K (15 comments.) says:

    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

  6. Jeffro2pt0 (164 comments.) says:

    S.K. That is interesting. A plugin to remove plugins. How can you not think that is funny :)

  7. harknell (1 comments.) says:

    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.

  8. Jeffro2pt0 (164 comments.) says:

    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.

  9. Nigel Dunn (2 comments.) says:

    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.

  10. brVince (6 comments.) says:

    oh my… mean to say, it also accumulate space in the hosting? is it true?

  11. James Davis (1 comments.) says:

    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.

  12. huda (2 comments.) says:

    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.

  13. S.K (15 comments.) says:

    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

  14. Jeffro2pt0 (164 comments.) says:

    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.

  15. Ministermark (1 comments.) says:

    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 :)

  16. Gray says:

    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.

  17. Toxic (3 comments.) says:

    Clean Options can be used to clean up some of the detritus left over from deactivated plugins.

  18. Jeffro2pt0 (164 comments.) says:

    Thanks for the link Toxic, but don’t you find this to be somewhat of an oxymoron? A plugin that removes plugins?

  19. GaMerZ (24 comments.) says:

    @Jeffro2pt0, @S.K: Thanks for the compliments =D

  20. Petter (1 comments.) says:

    Why have so many plugin authors neglected to add this functionality to their plugin?

    Because most other plugins don’t. And the plugin development docs does not mention this.

    What are some solutions that plugin authors could use to easily add this option to their code?

    Add better documentation and a plugin “de-install” in wordpress which also delete the plugin files?

    Should there be tighter restrictions on how a plugin gets into the WordPress.org plugin database?

    I don’t think so.

  21. Jonathan (1 comments.) says:

    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.

  22. Monika (40 comments.) says:

    Hi

    It would be great if ALL these plug-ins when de-activated removed their own database options.

    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

  23. Ted Clayton (31 comments.) says:

    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.

  24. Andrew (31 comments.) says:

    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.

  25. Rene Kriest/ProbloggerWorld.de (1 comments.) says:

    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

  26. Jenny (28 comments.) says:

    I knew this. I just recently cleaned out my DB and found it out for myself. xD

  27. Kristin K. Wangen (5 comments.) says:

    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.

  28. Keith Dsouza (82 comments.) says:

    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.

  29. Jeffro2pt0 (164 comments.) says:

    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!

  30. Jacob Santos (3 comments.) says:

    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.

  31. Kirk M (67 comments.) says:

    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.

  32. Jeffro2pt0 (164 comments.) says:

    @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?

  33. Michael Martin (5 comments.) says:

    @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. :(

  34. Jeffro2pt0 (164 comments.) says:

    @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.

  35. Soverato News (3 comments.) says:

    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? ;-)) .

  36. Stephen Rider (10 comments.) says:

    “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?

  37. Stephen Rider (24 comments.) says:

    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.

  38. Windy Road (2 comments.) says:

    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.

  39. eyn (4 comments.) says:

    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.

  40. Jacob Santos (3 comments.) says:

    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.

  41. Alex :: Web Design (5 comments.) says:

    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!

  42. Cody (21 comments.) says:

    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…

  43. Jacob Santos (3 comments.) says:

    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.

  44. JeffNor (1 comments.) says:

    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.

  45. Ted Clayton (31 comments.) says:

    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.

  46. macdo (1 comments.) says:

    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!)

  47. fuggi (2 comments.) says:

    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

  48. Jeffro2pt0 (164 comments.) says:

    with all of the solutions and ideas that have been presented thus far, where do we go from here?

  49. Andrew (31 comments.) says:

    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/

  50. Bill Masella (6 comments.) says:

    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..

  51. Beemer says:

    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.



Trackbacks/Pingbacks

  1. […] löschen. Vielleicht bietet dieses WP Plugin dies bald bequem in der Options Page an, wie zur Zeit diskutiert […]

  2. […] up at a great post by Weblog tools collection, I’m pretty sure there is a pretty good reason (or reasons) why plug-in authors do not wish […]

  3. […] Weblogs tool collection leo una interesante nota, la cual afirma, o mejor dicho, explica en detalle un inconveniente que generan la mayoría de los […]

  4. […] just read a thought-provoking entry on the Weblog Tools Collection about uninstalling plugins. WordPress offers a way to “Activate” or “Deactivate” any plugins that are […]

  5. […] is a discussion going on over at Weblog Tools Collection about the difference between uninstalling, and deactivating, plugins. There are a lot of very good points made about the things that plugin authors can do to help […]

  6. […] especially with WordPress. Go ahead, subscribe to our feed!In response to Jeff’s post regarding uninstalling plugins, Andrew Rickmann has created a tool that adds an uninstallation option on the plugins page. The […]

  7. […] es lo mismo desactivar que desinstalar. Y esto es una auténtica pesadilla para los usuarios de WordPress. Cuando quieres desprenderte de alguno de esos plugins que te crea […]

  8. […] database. While not the end of the world, it takes up unnecessary space and could cause conflicts. Jeffro 2.0 of Weblog Tools Collections brings up the subject of uninstalling Plugins and within a few days, we have the start of an answer. Andrew Rickmann created a tool that creates […]

  9. […] Uninstall – Is There Such A Thing? Earlier this week, I posted an article that took a hard look as to what uninstall actually means when you look at WordPress plugins. This has been a hot topic of debate during the week and I feel it will probably take up most of the show. […]

  10. […] dies hi ha una discusió sobre la desinstalació de plugins de WordPress; la majoria dels plugins no porten un implementat […]

  11. […] Jeff nos hace notar, sin embargo, que al desactivar un plugin no se deshacen esos cambios, simplemente se dejan de utilizar; de la misma forma cuando uno borra los archivos. Y uno termina con una base de datos con un montón de información que no utiliza y pero que abulta y ocupa espacio y posiblemente multiplica las chances de que las actualizaciones causen problemas. […]

  12. […] response to Jeff’s post regarding uninstalling plugins, Andrew Rickmann has created a tool that adds an uninstallation option on the plugins page. The […]

  13. […] put up a great post on Weblog Tools Collection about WordPress and how deleting plugins doesn’t mean that everything with regard to the […]

  14. […] There are plugin activation and deactivation events, but no plugin uninstallation events. The idea, pushed recently by Jeffro2pt0 on WeblogToolsCollection, is something that would clear out the unused data left around by unused plugins (depending on the […]

  15. […] back in the mists of time, following an article on Weblog tools collection, I started looking at writing an uninstaller for WordPress plugins. There was a significant […]

Obviously Powered by WordPress. © 2003-2013

page counter
css.php