post-page

Uninstalling Conundrum Part 2

28
responses
by
 
on
January 12th, 2008
in
WordPress Plugins
heading
heading
heading
28
Responses

 

Comments

  1. Alex (10 comments.) says:

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

  2. Mark @ TheLocoMOno (1 comments.) says:

    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.

  3. Ted Clayton (31 comments.) says:

    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!

  4. Kirk M (67 comments.) says:

    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.

  5. Keith (8 comments.) says:

    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.

  6. Matías (1 comments.) says:

    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.

  7. JamieO (5 comments.) says:

    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.

  8. Keith (7 comments.) says:

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

  9. Robert (1 comments.) says:

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

  10. Michael Martin (5 comments.) says:

    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.

  11. BoltClock (24 comments.) says:

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

  12. ulysses ronquillo (15 comments.) says:

    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?

  13. Otto (215 comments.) says:

    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.

  14. JamieO (5 comments.) says:

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

  15. redwall_hp (40 comments.) says:

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

  16. Ted Clayton (31 comments.) says:

    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!

  17. Jeffro2pt0 (164 comments.) says:

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

  18. redwall_hp (40 comments.) says:

    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.

  19. Dave (1 comments.) says:

    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.



Trackbacks/Pingbacks

  1. […] policy for all plugin developments? It seems that everybody is up in arms about this newest hot WordPress topic for 2008. A policy of this nature would only seem fitting for such a great web development […]

  2. […] Missing WordPress Plugins Uninstall Feature: Weblog Tools Collection continues covering the WordPress Plugins lack-of-uninstall features in WordPress and offers tips and recommendations from readers and WordPress experts on where to go […]

  3. […] Missing WordPress Plugins Uninstall Feature: Weblog Tools Collection continues covering the WordPress Plugins lack-of-uninstall features in WordPress and offers tips and recommendations from readers and WordPress experts on where to go […]

  4. […] uninstall functionality that was recently discussed over several posts on this blog, and over at Weblog Tools Collection, was clearly something that should be in the core and would be hindered by being a […]

  5. […] Estas funções foram bastante discutidas, mas ainda não existe um hook […]

  6. […] Uninstalling Conundrum Part 2 […]

  7. […] has made, there is one thing that was mentioned that I hinted to back in January on another post (Uninstalling Conundrum Part 2) and that is, a plugin validation […]

  8. […] all for plugins being able to have an uninstall feature that removes them entirely from WordPress, including the database but in this instance, I want to […]

Obviously Powered by WordPress. © 2003-2013

page counter
css.php