My suggestion is to just require plugin authors to note whether or not an uninstaller is built-in.

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.

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.

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

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.

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?

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

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

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.

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.

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.