8 Comments


  1. Hi Jeff,

    Great post! I’ve only been using WordPress for a year now and just started developing plugins. I often find orphaned tables and directories and wonder why some plugin developers focus primarily on the set-up and not enough on the tear-down.

    When I started working on my current plugin, I determined that it needed a database table. So the first thing I did was make sure the table was created properly on activation, and dropped properly on uninstall, but I only knew about the uninstall hook. I like the thought of keeping the Uninstall code in a separate file, it feels clean. So I’m going to adopt that practice and refactor my current plugin right away!

    Thank you for sharing!

  2. Carl Hancock

    I agree that in most situations that the core WordPress uninstall.php functionality should be used for uninstall situations involving plugins.

    However, with Gravity Forms we have our own uninstall process and implementation. Because of the fact our product is commonly used for information that is considered critical and vital to a business, the accidental deletion of it is something you want to avoid.

    To put it bluntly, some users are dumb. They may not realize “Uninstall” means they would lose ALL of their data. They may use it when they are simply playing around with their site and removing and adding a different version of the plugin, etc. not realizing the implications. They may not realizing that by “deleting” a plugin it’s going to delete ALL of the data and tables that may be associated with that plugin.

    For instance it’s common for us to deactivate and delete versions of GF and Add-Ons on our own test machines via the plugin manager and then upload and install different versions. That doesn’t mean we want to lose all our data. So we certainly don’t want that to occur when we delete the plugin in the plugin manager.

    This is why we chose to implement our own version of a full uninstall within the Gravity Forms Settings area that makes it very clear to the end users that it will delete ALL data and remove ALL database tables.

    So one size definitely doesn’t fit all. But our plugin is atypical. For a lot of plugins the core uninstall.php functionality should be utilized. But that doesn’t mean it should be used by all plugins.


  3. @Carl Hancock – Well you’ve proven to me once again that there usually is no one size fits all. The scenario and situation you provided certainly makes sense for GravityForms. I certainly wouldn’t want to accidentally delete everything after removing GravityForms which is why I think it’s good that you’ve turned it into it’s own unique separate process with a big warning. But, I think GForms is an edge case scenario along with perhaps a few other plugins but I bet the majority of plugins would be just fine with the Uninstall.php method.

    At any rate, I’m glad you wrote your comment to give other plugin developers a different perspective on when it might not be best to go with either the hook or uninstall.php. The one thing I’d hate to see are general typical plugins all coming up with their own uninstall methods.


  4. @Jeffro – I’ve made sure I include uninstall.php in all my plugins that deletes the data. But, I clearly understand Carl’s point above.

    I think a good thing would be that when a person is deleting the plugin via the Plugin Installer, WordPress warns the users that he might lose all data added by the plugin.


  5. @Ajay – Yes, which is why I added If you add uninstall functionality to your plugin, please add a warning of some type so that users will know that all data will be lost once the uninstallation process finishes. to the post but I think I’ll need to bold the entire statement so people see it.


  6. @Jeffro – Actually, I meant WordPress needs to add this just before the user hits the delete button.

    Agreed it’s definitely a good idea to throw it somewhere in the plugin

  7. Robby Chen

    That’s why I’d like to use SQLite to store the options for my plugins. Although I’m just beginning to learn the WordPress plugin development, I think that WordPress relied too much on MySQL database.


Comments are closed.