CMS Development Tracking

First off, I want to thank each and every one of you who put your thinking caps on and came up with some awesome ideas and solutions for this perplexing problem. I think its time to consolidate the ideas that we came up with, and review what the underlying problems are.

Nick was first out of the gate

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.

The problem that I and many others have is that, deactivating a plugin should not have the same affect as uninstalling it. This is wrong. Who wants to reconfigure their plugin after deactivating it, when all we’re trying to do is upgrade WordPress?

Michael Martin then chipped in and offered up his opinion:

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

Michael raised quite a few interesting points. First off, I completely support the Uninstall function of a plugin becoming seperate of the Deactivate function. His next point is one that seriously needs some undertaking. He is right. There are no rules or concrete guidelines for how a plugin should be uninstalled. Which means, there are no guidelines for which to enforce upon these plugins. This a problem in and of itself, at least with all of the plugins associated with the official WordPress.org Plugin Database.

As for Michaels next point, this is one of the problems that I haven’t been able to come up with an answer for. He is right though. While some plugins would have an uninstall button, others would not, causing the end user to be confused. So help me out, how do we solve this particular issue?

Toxic happened to mention a plugin called Clean Options.

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

Kirk M reminded us that it’s just not the plugins that add or modify database information that are the problems.

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.

And that is indeed true. Which goes back to the topic of how there are currently no strict guidelines that discuss how a plugin should be removed, if it happens to modify core data or modify database information.

Andrew Rickmann actually created a tool that adds an uninstallation option to the plugins page. However, the option will only show up if the plugin is deactivated, and if the plugin author has created an uninstall file. Andrew’s tool has been very well received. But the problem lyes again with every plugin author not including this installation file which then, makes this tool somewhat obsolete.

And last but not least, Keith has created a WordPress Plugin Framework (WPF) which allows plugin developers to deactivate and uninstall their plugins.

Where Do We Go From Here?

The only way of fixing the uninstalling problem, is a round of solutions to what I believe are multiple problems. As for uninstalling a plugin, as an end user, this is the way I’d like to see it done.

I don’t want options or anything to change when I deactivate a plugin. What I want to see is an uninstall button if the plugin is 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.

As for tighter restrictions on the official WordPress plugin database, I feel they are necessary. I talked with Photomatt himself today, and suggested that WordPress come up with a quality assurance team or what can be called a plugin validation team. This is a similar approach that folks from PHPBB3 have taken with their mod database. This is how I explained it:

PHPBB 3.0 which is a complete rewrite of their forum software, they have a mod validation team. Mods are submitted to the database but the validation team has to go through the code and ensure that the mod was developed, following the coding guidelines they have set forth. This ensures maximum compatibility and it also keeps crappy coded mods from entering the official mod database.

So what I’m proposing is that, the WordPress team should get together along with the community and develop a series of coding guidelines. These are the guidelines that third party plugins would have to abide by, in order to be housed within the official WordPress plugin database. This is the only way WordPress would be able to somewhat control the quality of plugins that are coded and released to the public. Granted, you’re not going to solve the problem completely as people will still be able to code plugins for WordPress and release them via their own website, but then, end users of WordPress should think twice about those particular plugins and realize that the only safe route to go should be through the official source of plugins that being the WordPress.org plugin database.

Matt thought the PHPBB3 mod validation process was interesting and has stated that perhaps in the future, parts of their process could some day be implemented into WordPress.org. Until then, we will need to use the solutions that have been provided by the community.

Related CMS news: