As a plugin developer, you want to build something cool and functional. After all, WordPress plugins are yet another tool to add additional functionality to any site. Plugins like Custom Post Type UI and Instago offer a user many ways to solve problems by creating a series of options, such as creating a custom post type or redirecting a specific URL to another. Perhaps you already know that all of these options are stored in your database, but herein lies a problem. When deactivated, shouldn’t a WordPress plugin also uninstall options?

Uninstall options

Some WordPress plugins include a file called uninstall.php. This magic file will run automatically when users delete the plugin. Inside of the file is a set of instructions to uninstall options created by the plugin. Options include, but are not limited to, a color for all of your site links or adding a popup. When a user sets an option created by the plugin, the option gets stored in your database. Once a plugin has saved the option value, it will use the value later in the code.

There are two hooks or methods that you can use to uninstall options: Deactivate hook and Uninstall hook. The Deactivate hook will run every time a user deletes a plugin. It also flushes the cache and permalinks. The Uninstall hook runs at the same time. This hook will delete options from the options table inside of your database and will allow the developer to delete any tables created by the plugin. It’s important to know which hook to use and when.

Here is a very basic uninstall.php file. Our code has created on option in another file. When the plugin is deleted, uninstall.php will run and our option will be removed from the database.

<?php
// die when the file is called directly
if (!defined('WP_UNINSTALL_PLUGIN')) {
    die;
}
//define a vairbale and store an option name as the value.
$option_name = 'plugininze_example_option';
//call delete option and use the vairable inside the quotations
delete_option($option_name);
// for site options in Multisite
delete_site_option($option_name);
?>

The WordPress Developer Handbook says a dev should always uninstall options when a plugin is deleted. However, that’s not always the case. I mentioned some WordPress plugins come with a uninstall.php file. Some WordPress plugins choose to leave this file out. But, why? The answer can only come from the developer. However, I’m going to do my best to explain the decisions a developer faces every day.

Leaving data behind

E-commerce plugins like Easy Digital Downloads and WooCommerce do not delete options and tables when the plugin is deleted. Why? This is due to the off chance someone accidentally deletes the plugin. Even though each plugin has a settings wizard to help you define some default options, there’s still a lot of work necessary when entering products or downloads. You wouldn’t want all of that hard work to get deleted, would you?

WordPress developers will tell you that there have been many debates over this topic. On one hand, you have plugins creating tables and storing data in the database, which is a good thing while you’re using the plugin. But, what about when you decide to delete the plugin or switch to another? Should the data stay in the database?

What you really want to know is: does the size of the database impact a website’s performance?

Most developers will tell you it doesn’t matter. Whether data is being used or not, it won’t have an impact on the performance of a site. Other developers will tell you the performance of the site is directly related to the size of your database. Each time WordPress runs a query, the query has to read every row in a table to see if it meets the requirement of the search.

Think about it like this: each time you load a page or post, WordPress has to find the information you want and return the values. Archive pages are a good example in this situation. An archive page will only show blog posts related to the name of the archive. If you have 5000 posts, and only three are in a category called News, WordPress goes through every post in order to sort posts in the news category from every other post. That’s a lot of data. That’s just to show those three posts on the news category archive.

Now imagine if your database has 500 tables, with 5000 posts in each. You get the picture. It’s a lot of data to sort through.

Generally speaking, the size of your database and the number of installed plugins will not hinder the performance of a WordPress site. When WordPress does a search, your query usually tells the search to only look in a specific table in the database, excluding all of the other tables. Over the years, WordPress has improved its many ways to build queries. Pre Get Posts is a perfect example of a better way to build a query. This hook is called after the query variable object is created, but before the actual query is run. It’s important to know Pre Get Posts is not the best practice for archive templates and single page/post templates.

Making the decision to uninstall options

We’ve all heard the popular phrase, “Your mother doesn’t work here, clean up your mess when you’re done.” The same mentality is used when a plugin is deleted. If you create five options, you should delete five options.

Some WordPress plugins use the default options created by the core WordPress files. Think of user profiles and settings options. The plugin may be using the data stored in these options to create membership pages or using the data in a shortcode.

When a user deletes your plugin, you don’t want to delete a user’s profile settings, or even worse, the General Settings where you tell WordPress the site address to use for this install. If your plugin uses the information in the site address, you would literally crash the site if you uninstall options in the option value.

Keep that in mind the next time you’re creating some settings for the next WordPress plugin you develop. Is this data needed, or can we get rid of it? The real question is: “If I uninstall options in my plugin upon deletion, will the website break?”

If the answer is no, you should probably uninstall options every time. If the answer is yes, it would be in your best interest, as a plugin developer, to mention something to any user installing your plugin. You don’t have to explain everything. A simple message such as, “[Plugin Name] creates two tables in your database. If you delete [Plugin Name], you’ll want to drop these tables from your database, as well” is enough information to inspire the user to take action should he or she decide to one day deactivate your plugin.

Developer Opinions

WPwatercooler is a weekly WordPress podcast. This week’s episode was inspired by this post. Enjoy!

2 thoughts on “Should WordPress Plugins Uninstall Options When Deleted?

  1. I’ve had this discussion with developers more times than I care to think about.

    What I would LOVE to see happen, and this is probably something I should put in a ticket for in WordPress Trac, would be on the plugins list page, when a user clicks Delete on a plugin, a pop-up comes up and says something like “This plugin has created X amount of rows in the options table. Do you want to delete this information when you delete the plugin?” and then give the user the opportunity to delete it or save it.

    I have had had times during testing where I have needed to delete plugins and then reinstall them. You mentioned EDD/Woo. It would hurt SO BAD to lose all your store settings simply because you were trying to get to the bottom of an issue while testing.

  2. 100% agree here. I’d love something to say “This may leave stuff behind in the Database”. Some plugins only have 3 settings. Those I don’t mind too much. Where I start to worry is when you install 30 plugins, with 3 settings each.

Have a comment? Leave a reply

Your email address will not be published.