Hot damn! Our biggest ever sale is almost over. Ends Sunday. Save up to 50% now.

To save or not to save: WordPress plugin data

By Drew Strojny on October 16, 2013

If you look at the best practices expounded by most WordPress professionals, you’ll find one related to plugins that goes something like this: when a plugin is deleted, it should remove all traces of itself. No meta data, no extra tables, nothing.

This approach sounds great and it feels downright refreshing to any seasoned WordPress developer. It’s clean, and it respects the existing plugin system, which follows this two-step logic:

  • When you deactivate a plugin, nothing is removed, but the plugin is disabled.
  • When you delete a plugin, you get a confirmation screen, and then everything is removed.

Easy right? If you’re thinking about maybe using a plugin again later, you should just deactivate it. If you never plan to use it again, you should just delete it.

The big problem: Most WordPress users have no idea about these subtleties, nor are they 100% sure if they’re going to use a plugin again. The even bigger problem: Removing certain plugin data can have disastrous consequences. If someone has used a plugin extensively to set up their site, deletes it for any multitude of reasons, and then re-installs it, everything is gone.

An example: An SEO plugin that sets lots of custom data for each post or page based on a user’s specific settings and content. If the plugin follows this best practice, all that data is wiped when the plugin is deleted.

Reasons why someone might delete a plugin and re-install it:

  • Someone tells them to disable all their plugins as a debugging exercise. They might just delete them because they don’t know the difference.
  • They’ve tried modifying the plugin using the editor and want to get back to a “clean” state.
  • They delete it in an act of despair, and then later realize they actually do want the plugin again.
  • They’ve been told to try “reinstalling the plugin”.

In all of these situations, the user will be happy to see all of their settings and data in place when they reinstall the plugin. On the flip side, if they spent lots of time setting up a plugin, they could become enraged if everything they set up is suddenly gone.

We have two competing interests: the potential for a very angry and discouraged user vs. a pile of leftover plugin data. Most developers (myself included) cringe at this leftover pile of data. It just seems so wrong to leave it lying around. But, is it really that bad? I would argue no. The potential for disaster and disappointment far outweighs keeping things clean and tidy.

Keeping things super clean and tidy should be relegated to developer level tools, for people who care about that sort of thing. For example, an AppZapper like plugin for WordPress. AppZapper is an application for Mac OS X that labels itself as the “the uninstaller Apple forgot”. The premise: Applications install support files on your computer that generate clutter. These files save settings and other data used by the application. AppZapper finds and destroys them. This is a great tool for people who find this important (I’ve used it myself). The key takeaway: this isn’t something Apple “forgot”. It’s likely something they did intentionally to make the user experience better. They chose to always preserve user settings at the cost of some extra hidden clutter. I’d take that trade every time. Would you?

Enjoy this post? Read more like it in From the workshop.


  1. Alex

    I’d wouldn’t mind seeing a prompt asking whether or not to remove all data when deleting a plugin, but I wouldn’t want a plugin to silently leave all its old data behind. But then again, I’m a developer.

  2. Drew Strojny

    Good point Alex. One thing Zack brought up in our internal discussions was adding a checkbox (unchecked by default) to the delete plugin reminder screen that gave you the option to “delete all files and data”. Checking that box would result in permanent removal. Most people that aren’t comfortable or familiar with the repercussions would probably leave it unchecked, which would minimize the risk of data being lost by mistake.

  3. Mark Root-Wiley

    Good point overall.

    +1 on the checkbox. I’ve seen a ones (usually unchecked by default) in some plugin options pages. Until WordPress puts something into core, that feels like the next best thing.

  4. Luc

    I don’t think it should be a checkbox in core… It goes against one of the main principles of WordPress; ‘we prefer decisions over options’. The average user wouldn’t know what to do with a checkbox like that, and they might (without knowing it) lose there plugin-data.

    That being said; I would love a new constant a plugin of mine can check against… something like WP_AUTO_DELETE_PLUGIN_DATA , if that’s set and set to true, I can rest assured somebody made an informed decision.

  5. Otto

    Honestly, I think that deleting all data on uninstall is a reasonable thing to do, but perhaps the user experience should be a bit better. When using the uninstall in WordPress, it tells you which files will be deleted. Perhaps it could go a bit further and tell you that the plugin’s data would be deleted as well.

    This wouldn’t be difficult to allow plugins to specify. A simple header in the uninstall.php file would allow for this sort of thing.

    Realistically, a checkbox situation is one of those unnecessary options. It’s forcing the user to make a choice that they may not fully understand and honestly should not have to make. As we’re all pretty well aware, “re-installing” a plugin never does anything of value, nor will it realistically solve any problems. We should eliminate the bad-advice people receive to do this sort of thing, and focus on the actual problems instead. People shouldn’t be uninstalling a plugin if they want to keep the data from it, and the question we should ask is how to properly inform the user of what is going on in a way that allows them to make meaningful decisions in this respect. Adding a third option to the deactivate/delete scenario just throws the problem back at the user, it doesn’t solve it.

  6. Mark Root-Wiley

    A good reminder that we shouldn’t get too dogmatic with “decisions not options.”


    This does strike me as causing a problem for some users so we should focus on:
    1. Is it a real problem? (I personally think this article establishes that it is.)
    2a. If so, why? (Because some users delete plugins for odd reasons and some plugins store a LOT of data)
    2b. If so, how can we fix it? (tbd)

    Step 2 might involve an option, but only if it’s justified by step one and then considered the best option. If there are legitimate use cases for doing something two ways, that is potentially a great reason to put in an option. If there’s an option-less way to fix a problem, that’s great. If there isn’t, that’s cool too.

  7. Alex

    I agree with Otto that deleting the data when a plugin is deleted is completely reasonable. But as Drew pointed out, just because something is completely reasonable doesn’t always mean that it creates the best user experience. Even I mentioned an extra prompt in the first comment, I don’t really think that is a great user experience either. Really, a checkbox would simply be duplicating the difference between plugin deactivation and plugin deletion. A warning such as Otto mentioned should serve as a deterrent for those who don’t know what they’re doing.

    But really, it seems that this whole discussion leads to a different question: does a plugin author have a responsibility to create hidden backups for someone who should already be keeping backups of their own?

  8. Otto

    Mark, this isn’t a case of dogma. Your step 1 defines that a problem exists, but really your step 2a defines the actual problem instead of a solution. If users are deleting plugins for odd reasons, then those odd reasons should be addressed directly instead of applying band-aids to eliminate the symptoms.

    Adding an extra option here doesn’t necessarily solve the underlying problem: why do people delete plugins and are then surprised when the settings are deleted too? It seems like a rare case, possibly rare enough that plugins which often have this issue have solved it themselves. Maybe we should look at those solutions.

  9. Mark Root-Wiley

    Otto. Sorry if I wasn’t clear. I’m totally for addressing the underlying problem sans option if at all possible. I was mostly trying to get away from the “decision not options” line and focus on the specific issue at hand.

  10. Drew Strojny

    Regardless of whether it’s a good idea to add an option to core, it’s important to recognize that there are possible exceptions to this best practice. Someone who doesn’t choose to remove data isn’t consequently “doing it wrong”.

    It should be up the plugin author to make this decision based on the plugin and the data at hand. If you’ve got a basic plugin without much configuration or data stored in the post meta, then it’s obviously a no brainer to remove it all. If you got something a bit more involved, like an SEO plugin, it might not be as prudent to be so destructive with the data. Basically, the stakes go way up at that point, and in my mind, the preservation of the data becomes more important than some extra clutter.

  11. Phil Johnston

    This seems like a non issue to me. Leave the data where it is. If you run a site big enough to worry about minute amounts of clutter, then you probably have a developer on hand who can remove it manually.

  12. John

    As what is probably a typical WordPress user, i.e. not too up on coding and not so sure of what to delete and what to keep when removing a plug-in, I’ve had both good and bad experiences.

    I use a premium membership plug in and when upgrading to the latest version the routine is to delete the plug-in and install/activate the new version. All data is retained…phew!

    However, I also recently deleted a security plug in because it was causing issues on my site and hassles for users; some of which remain after deletion.

    No answers just a comment.


  13. Peter Knight (@peterrknight)

    The problem is even bigger on the other end of the things with plugins not providing a way to delete the data it generated. The answer is clearly not “just leave the data in tact”. Plugins that leave their data because it could potentially create unintended data loss should at the very least provide a means to automatically delete their data and this very rarely happens. A clearer UIX so that a user knows what is happening when they hit delete is one step forward.

    Even for plugin developers, things can be confusing as the verbs deleting/uninstalling/deactivating aren’t used very precisely and consistently in the docs and ui. For example, the user sees ‘delete plugin’ and ‘Are you sure you wish to delete these files?’ OR ‘Are you sure you wish to delete these files and data?’, whereas on the code side this procedure is referred to as uninstalling. (At least I thought that was somewhat confusing)

    Also worth keeping in mind that users have 3 (non-programmatic) ways to disable a plugin: they can deactivate, delete via the interface, or delete via the filesystem. The option to do any of the three in different cases is important because they all accomplish different things. User just needs to be informed and directed as to what to do in what situation.

  14. Drew Strojny

    John: Thanks for sharing from a user’s perspective.

    Peter: Good points! Thanks for jumping in the discussion.

  15. Brian Coogan

    This problem is also related to the size of the plugin and it’s relevance to the site. Deleting a plugin with data from several hundred hours of user work could be a huge problem. it also depends on where the data is installed; whether it’s in separate tables or not (and for most, it definitely shouldn’t be, of course).

    One scenario where a user might delete a plugin is to reinstall from a file. There is currently no way to upgrade a plugin from a file, that I’ve found.

    A non-trivial solution occurring to me is for the plugin to backup it’s data in a file (somewhere??) and restore the data when reinstalled.

  16. Margherita

    I echo Brian Coogan above.
    I’m not sure how to do an upgrade from a file without overwriting it via FTP.

    The developers from a really well known plugin recently instructed me to do an *upgrade* as part of trouble shooting (ironically the updater wasn’t working). I didn’t want to loose the settings and could not see how to achieve it otherwise. When I questioned further they actually meant that I should deactivate>uninstall>reinstall. To me this wasn’t an update, this was a total reinstall, and in my experience I would have been manually re-entering the settings afterwards. Apparently with this plugin this was not the case..

    I think a settings migration facility should be mandatory. (maybe baked into WP, that’s not too difficult for the average user to understand)

    i.e export-reimport settings – like W3 Total Cache has.

Comments are closed.

“My website is absolutely gorgeous, and the support service is literally unlike any other I’ve experienced, probably in my whole life, in any industry!”

Jacqueline Smith

“I’m blown away by the generous and effective support provided. Super accessible, laid back, and knowledgeable!”

Micah Davisyes
Discover our WordPress Page Builder Now

(Over 600 small businesses got started last week)