Plugin Authors: Please Provide Uninstalls

… but OMG (plugin authors), please don’t confuse a disable with an uninstall!

hmm.. thats true.

i was going to say that the OP had a point..realizing that the one plugin Ive made that actually creates a table doesnt provide a way to delete those tables.

But then you raise that equally valid point. Since my plugin stores bad domains that, chances are, the user wont remember, much less want to, once they’ve entered them, a deletion of tables due to a simple deactivation would really suck.

The option: include yet another page where you can delete tables? hmm.. I dunno, seems like alot of wasted space just to delete a table.

After thinking that through, Im inclined to think that if someone is plugin shopping (so to speak) and is concerned about a cpl extra tables that arent being accessed anyway — theres always phpmyadmin.

I like the idea of an uninstall. Some plugins don’t just create their own tables, but also rows in the options table. Some of those rows are quite cryptic as to their intent.

It could never be made idiot-proof, but if there’s a separate uninstall option that pops up an “are you sure you want delete all tables, options, etc. – if not use disable” and “have you backed up your DB lately?” messages, anyone who deleted something they shouldn’t have has no one to blame but themselves.

It could never be made idiot-proof …

true, and those are the ppl that end up back at your site complaining ??

I’ll take this into consideration the next time I upgrade wp-deadbolt.

Yes, but they’d have to be able to figure out how to upload plugins before they could start complaining about the uninstall. ??

This is a tricky issue. I’ve been thinking about it myself a bit since my main plugin does add a ton of stuff to the db. However, placing the uninstall link anywhere easy can lead to problems, especially if it gets activated by mistake. Also, what if your site getes hacked and the hacker sees a nice easy to click “erase all my data” button and adds that to the destruction.

What I might do is instead of adding an uninstall to the plugin, I might create a separate plugin that does the uninstall that only needs to be uploaded and activated if they want to uninstall, then they can delete it and the entire folder/plugin when they are done. Keeps it somewhat simple, only gets used when they actually want to uninstall, and minimizes the possibility of malicious hacking (let’s also imagine a hacking scenario that somehow activates the “erase” function remotely if it’s in the regular plugin…..)

harknell: that is what I am thinking, if not you can have a tab to do the uninstall.

I’ll probably look into doing my plan with my plugins starting after this next development cycle.

I will provide uninstalls into my individual plugins in the next release.

Check this plugin, it might be of interest to you.

And don’t miss this one, certainly it’s going to help you.

I agree with dylan. Perhaps authors could just simply include in their documentation or README file what tables the plugin will create and utitlise? That way, we’ll simply have to check that and be able to drop the tables when we delete a plugin.

That’s of course for those with phpMyAdmin access of course. I know that’s not everybody but it’s definitely a good sum of ‘everybody’.

Plugin authors can also make this situation better by putting options in an array and thus adding only one record to the Options table. Name that array/option after the plugin, and it will be clear what that record contains. Far too many plugin authors litter the options table with a new record for each separate option in their plugin.

Also, if you change from multiple lines to an array in an update, stick in a cleanup function that will take the separate lines, convert them to the array, insert the array, and then _delete_ the old ones.

SHORT VERSION: Give your options self-evident names and even manual cleanup is relatively easy. ??

Rok’s links are broken. Here are the correct links for those plugins:

https://henning.imaginemore.de/pluginstaller/
https://www.ads-software.com/extend/plugins/clean-options/

If a plugin has an “uninstall” capability, then it’s perfectly possible to make a plugin deactivate itself. Just remove your own name from the ‘active_plugins’ option.

So a good uninstaller for a plugin would clean up the database options, edit the active_plugins option, then return a redirect to the main plugins page. Done and done.

or people could stop plugin-shopping with their live site, and setup a testbed installation.

The problem with offering an uninstall is that only the really decent plugin authors are ever going to do it (properly)… and chances are that those are exactly the plugins you’re not going to uninstall.

The ones you uninstall are too basic, too crap, or just plain don’t work. Can you trust THAT author to make a clean uninstall when they can’t even make their plugin do what it’s supposed to?

That’s always been the problem with installing crappy stuff to test out. You don’t know its crap until it’s already on. Plugins, PC software, its the same issue.

The only way uninstall can work properly is if wordpress forces plugins to use it’s functions to access the DB, thereby allowing wordpress itself to track changes in an uninstall table.

This is a big restructure… and therefore not likely to happen overnight. In the mean time, even if authors do offer an uninstall, I’m not likely to trust it.