Why Some WordPress Plugins Leave Orphaned Tables in the Database

Reviews of WordPress plugins on the directory come in all shapes and sizes. Some are really helpful while others are short and to the point. For example, this review from a recent WP eCommerce user, “I uninstalled and it left orphan tables I now have to clean up manually. Poorly done.”

This type of review can be easy to shrug off but Justin Sainton, co-founder of WP eCommerce, responded in the best way possible. He acknowledges the user’s complaint and admits that they bring up an important point that the team could document in a better way.

“We make a very intentional decision to NOT remove tables from the database when people uninstall or deactivate WP eCommerce,” Sainton said.

“Any number of reasons we’ve encountered over the years result in someone deactivating and uninstalling their plugin. Even though WordPress makes it clear (if you have an uninstallation routine) that you’re removing data – this is a notice that is very easy to ignore when you’re on a mission to do something.

“For those reasons, we’ve made the intentional decision to not remove any of the data (much of which would be MASSIVELY detrimental to a business if it were removed unintentionally) upon uninstallation.”

What are Orphaned Tables?

Orphaned tables are those left by plugins that don’t perform a table cleanup when uninstalled. These tables often contain data, including forms, entries, settings, etc. For example, when I installed GravityForms 2.0 on the Tavern’s test site, I discovered that the forms I created six years ago were still in the database. Not only was I surprised, but thankful that I didn’t tell GravityForms to remove the data all those years ago.

Deactivating a Plugin Shouldn’t Remove Data

There is a distinct difference between deactivating a plugin and uninstalling it. The process of deactivating a plugin happens more frequently than uninstalling mostly due to the troubleshooting process. Deactivating a plugin should not remove any data from the database. Think about how frustrating it would be to deactivate a plugin and then have to reconfigure its settings?

Removing Data Should be Explicit

Instead, the removal of data should be an explicit action from the user. Plugin developers who want to give users the ability to remove data when uninstalling can register an uninstall hook and add a Uninstall.php file. From the WordPress developer reference guide regarding Uninstall.php.

If the plugin can not be written without running code within the plugin, then the plugin should create a file named ‘uninstall.php’ in the base plugin folder. This file will be called, if it exists, during the uninstall process bypassing the uninstall hook. The plugin, when using the ‘uninstall.php’ should always check for the ‘WP_UNINSTALL_PLUGIN’ constant, before executing.

Developers who use this method should provide a clear and concise confirmation prompt to users that warns data will be removed. A great example of a plugin that does this well is GravityForms. The uninstall routine is separate from the deactivation process and the warning clearly illustrates to the user that data will be lost.

GravityForms Uninstall Process

In a comment published to the Tavern in 2013, Carl Hancock, Founder of RocketGenius, explained why they use their own uninstall process over the suggested use of Uninstall.php.

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 user that it will delete ALL data and remove ALL database tables.

Orphaned Tables Typically Don’t Impact Site Performance

Some people believe that too many orphaned tables can negatively impact a site’s performance. I asked Sainton if this is true, “Generally speaking, no,” Sainton replied.

“There are certainly instances where the number of tables that exist in your database could potentially impact the performance of certain queries – but those types of queries should never really be run in most contexts – certainly not in most contexts that WordPress developers would be interested in.”

Orphaned tables and the data within them are contained within the WordPress database, something most average users rarely dive into. Most are probably unaware of the amount of data and tables sitting in their database taking up bytes of space. It’s good to know that in most instances, orphaned tables don’t degrade a site’s performance and isn’t something to be too concerned about.

Cleaning Up Orphaned Tables

There are a number of plugins that optimize and clean orphaned tables from the database. A cursory search of the plugin directory provides the following results.

WP-Optimize

P3 (Plugin Performance Profiler)

WP-DBManager

WP Performance Pack

There are more plugins than what I’ve listed here but each one interacts and manipulates the WordPress database. I learned from experience that before using any database cleaning and optimization plugin, you should create a full backup of your site.

I once used a database cleaning plugin and although it did the job, it removed things I didn’t expect like custom post statuses generated by Edit Flow.

Should The Uninstall Process Be a Plugin Directory Guideline?

Like the settings link on the Plugin management page, a number of plugins in the directory don’t use Uninstall.php or register an uninstall hook. I firmly believe that any plugin that adds data to the database should provide an easy way to remove it. It’s a guideline that if enforced would benefit users by helping to maintain cleaner databases.

Developers, let us know in the comments what you do to enable users to remove data from the database after it is added by your plugin.