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.
I don’t know if this solution has already been proposed; in my opinion it is the cleanest:
The WP core should have an API hook for uninstalling a plugin. A plugin can register a certain function to this hook, if that function is called, the plugin will uninstall all its customizations. Then, if a plugin registered an uninstall function, add a link on the plugins page for the plugin to be uninstalled, e.g. right underneath “Deactive”. (Of course, uninstalling implies deactivitating.) Additionally, a plugin must have the ability to return if it was successful, and if it wasn’t, it must have a defined possibility to issue a message (e.g. steps to be performed manually).
This is perfect timing as I am currently dealing with the hassle of my theme being borked due to certain plugins overloading my CPU allotment.
It would be great to learn more about how certain functions within a plugin would cause a large CPU usage like if it depends on the database to retrieve information or not. This would help understand the uninstall process much better.
Hope that made sense.
This is an important matter which is being taken up very well. These preliminary suggestions help make sense of some confusing areas. I would caution, though, that a course which results in plugin-making becoming an area that requires a better level of expertise, and more-specialized knowledge of WordPress-development particulars, might tend to reduce the pool of folks who take up the plugin-making activity.
Indeed, it seems to me that plugin-making is often the avenue taken by ‘late-stage beginner’ or ‘early-stage intermediate’ developers in the WordPress environment. If we adopt additional technicalities that become prerequisite to engaging in this activity, it may no longer serve so handily as an entry-point.
An additional concern is … not to put too fine a point on it … that, e.g., v2.4 just got skipped. There are obviously workload and burden-distribution factors that already absorb the available pool of development-talent – especially at the higher levels where the variability and unpredictability of plugin functionalities would place the review process.
In summary, I like that beginners can hope to tackle plugins. I think it is good & in the spirit of WordPress, that more not fewer be encouraged to dabble, even if imperfectly. To deal with these matters by putting additional, and ongoing review-duties on elite personnel seems to face problematic realities.
Great discussion – thank you!
Alex and Ted bring up some good points and their opinions flow along with the gist of the post. I agree that setting up specific guidelines for developing plugins is needed. It shouldn’t have to be off-putting for beginners if presented in a simple and straight forward manner. It’s not like trying to write the plugin for them but rather just to provide a set of guidelines for them to follow in order to set up the basic framework for their plugin so it adheres to certain parameters. In fact in my past experience in writing maintenance procedures, tech and operations manuals, I found that setting up basic guidelines similar to those being talked about here actually helps the people doing the work rather than hinder simply due to the fact they’re all working according to the same standard.
Oops…did I say standard? Well why not a standard? It doesn’t have to be followed verbatim, only as it applies to a particular plugin and it’s functions and effects to a WordPress install.
And I agree that this process should be taken one step at a time as far as being incorporated into WordPress.org. Obviously something like this should be thought out and implemented carefully, in other words; The thing’s gotta work before it’s presented to the general public. And who knows? The community might just develop most of the standards themselves.
I never really considered this a big problem until I saw the previous topic about this. I guess I really should go clean out my database.
I think the cleanest solution would be to make API functions to do it, but I think a better way would be to tell WP what database tables and such a plugin is making. That way, WP (not the plugin itself) can clean things out completely without each plugin having to reinvent the wheel.
I think that there are no issues whatsoever. Wether a plugin makes database modifications or not, the plugin must register itself thanks to the activation hook. Same thing goes for the uninstall one.
A compromise would be to provide the uninstall option for all plugins but if it didn’t register any uninstall option then nothing would be done. This has the added advantage of backwards compatibility with existing plugins. I would rather, though, have WP issue a warning about the plugin not having an uninstaller option so DB modifications may still remain. If a plugin doesn’t make any DB modifications then it’s as simple as defining a function to the uninstall hook that returns success no matter what.
If WordPress had an adequate set of documentation for the plugin hooks and integration process – API documentation from a standard programming concept – it would make that entire process easier.
What about a set of default uninstallation procedures added? The most generic level of uninstall would be a function with variables / parameters based on Kirk M’s quote of standard items to remove. The beginner / intermedia developers and plugins which are decent simplicity can call this function and do a few simple tests to confirm it cleans up their code droppings in a nice fashion.
For the more advanced developer / plugin, they can write their own uninstall solution which it sounds like already exists but few go so far as to do, or it isn’t presented in a consistent place within dashboard for people to know to use it. If a plugin doesn’t need to be uninstalled, you could call the empty function and report success to give people peace of mind that their system is ok.
The other item that I would like to see addressed – which might require restructuring some of the admin UI – is that all plugin options pages be located in one area. Why not have the plugins page be the primary (only) spot for people to access options. They can then present their own “page” inside the options tab and have as many sub-pages as are needed for administration of the plugin.
For plugins which require regular usage (spam filtering, link support, user management) the dashboard could become the equivelent of a widgetized sidebar – each plugin can create it’s own widget for admin elements and the user can configure how they would like to position them.
I agree – great to see these types of things getting discussed. The QA group to vet functionality and viability of the plugins is wonderful.
My WordPress Plugin Framework (WPF) attempts to address most of these issues that have been discussed with deactivating and uninstalling plugins.
Plugins built on the WPF are automatically provided with “Deactivate Plugin” and “Uninstall Plugin” buttons within the plugin administration screen. When the administrator clicks the “Uninstall Plugin” button the WPF provides a confirmation box prior to uninstallation of the plugin. Once the command is confirmed, the WPF removes all traces of the plugin from the database then masks the plugin’s administration interface with a notification box informing the user that the plugin has been uninstalled and needs to be deactivated. This prevents the user from attempting to access the plugin resources once the plugin has been uninstalled. There is probably a way to automate the deactivation after the uninstallation but I can’t seem to get past the “headers already sent” error. If anybody would be interested in helping me with this project please contact me via my website.
The WPF is still in the early stages of development and currently only supports creating database entries in the wp-options table. However, future releases will support creating and deleting new database tables as well.
I will also look into adding custom hooks inside the WPF that would allow the plugin developer to handle the uninstallation of custom generated files and file modifications (such as the .htaccess mods mentioned above).
Until the WP gurus get this ironed out, I would be satisfied if someone just made a list of what plugin creates what db table(s). I have various tables in my various blogs that I have no idea what plugin they’re created by 🙂
Well said. I think the idea of a quality controlled database would work well. With WP 2.3’s upgrades, getting into the Extend database is pretty important for a plugin. It might be enough to get a lot of people to follow the rules. 🙂
(And the point about greying out the Uninstall option when the plugin is active is very good)
As for the user confusion, I suppose that could be solved by adding a line to the plugins page, explaining what Uninstall means, in comparison with Deactivate.
I love how phpBB.com site staff has teams to validate MODs and styles before they make it into their official databases. Their method has been around for a few years now, so I’d like to see it happening for WordPress.org too. Thanks for letting Matt know about this 🙂
Some plugins create their own tables. Some use the wp_options table. Some plugins provide their own scripts to delete database entries. Others you have to manually delete when you no longer need them.
Other plugins use the wp_options table. It tends to bloat over time as plugins are installed/uninstalled. Sifting through the wp_options table and deleting entries can be a daunting task.
Maybe, WP needs to standardize on one plugin table like a wp_plugins for example to simplify things when plugins are removed from the system?
I agree with Alex. Just like there are register_activation_hook and register_deactivation_hook functions, there needs to be a register_uninstall_hook function.
Having such a registered hook would allow the plugin page to create an uninstall link for that plugin. This link would only be available if the plugin was already inactive. This leads to a natural two step process: deactivate then remove. We don’t want an implied deactivation, since this forces plugin authors to consider two different approaches to deactivation and uninstallation. Keep it simple.
The uninstall button will call the uninstall hook for the plugin, which would take appropriate action to remove its options and tables and such.
Seems like the best solution and keeps the interface clean and easy.
@Keith – That sounds quite awesome. Hopefully the Automattic guys are aware of it as something similar to that would be an ideal solution to the issues happening currently.
@Otto – And if they are modifying the plugins page to include a column for uninstall, why not also add a column for an ‘options’ link. When the user clicks that, takes them to the options page(s) for the plugin.
This would clean up many of the ‘where do I find options for plugin X’ and plugin bloat issues people have. If plugins need more prominance, convert the dashboard into a widget-able area where admin can control the plugins they want to see much like the sidebar is today post major revisions.
“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.”
Not a good idea at all. That would just make it harder to find perfectly good plugins. I’m perfectly fine with manually purging tables from the database. Imposing restrictions like that is against the spirit of open-source software. Plus, everyone has their own coding style, and it would be idiotic to restrict the way people code. It would be like saying “you can only write with monosyllabic words because some people don’t know what ‘monosyllabic’ means.”
I suggest, if table deletion is really a problem, suggesting that plugin authors incorporate uninstallers into their plugins. Do not, whatever you do, make it mandatory. Perhaps a flag could be added to the plugin directory to tell a user whether the plugin has an uninstaller.
I have a specific, simple, probably-agreeable suggestion: on the WordPress.org plugin site, and other places where plugins are offered for download, it would be nice to have the size of the download-file displayed. The size of the install-files varies commonly over 2 orders of magnitude, and the outliers span 3 orders!
As a sort of plug & pointer for the learner, beginner and casual plugin author, let me note that very often, small-size plugins are simpler, easier … and often written by other beginners, who will go a lot gentler on your budding skills!
The file-size is not a perfect indicator: in some cases there are screenshots included that balloon the size, and some simple plugins have fairly large Admin Panel and Help/docs pages.
File-sizes posted with plugin-downloads – thanks!
@Redwall How is my suggestion going against the spirit of OpenSource? The coding guidelines would only be applicable to the extend area of WordPress.org. So plugin authors who do not feel like following those guidelines could just as easily code and release plugins via their own site, which means the open source part of WordPress would still be alive and well.
PHPBB3 has a series of guidelines that plugin authors must follow and although it’s tougher to code a plugin, the end results over the long haul will prove their worth.
By trying to regulate how people code, you’re acting like a big corporation, rather than letting the programmers code the way they want. Some guidelines are fine, they can get out of hand. Imposing restrictions like that aren’t a great idea, in my opinion.
My suggestion is to just require plugin authors to note whether or not an uninstaller is built-in.
This is one of the reasons I prefer working with Drupal rather than WordPress. Drupal has a set of coding standards regarding code style, installs, uninstalls, etc that the core Drupal code follows and expects any module developer to follow as well. The variance of code quality of different WordPress plugins is so vast I could never know what to expect when trying out a plugin, let a lone checkout out its source code.