Deleting database tables after uninstalling plugins

Some plugins like WooCommerce or Gravity Forms don't remove database tables after uninstalling. That makes your database bloat with redundant tables if you don't plan to use these plugins in the future. In my situation, we have a multisite for premium WordPress themes demos. Most of them have WooCommerce installed. When we deleted a site in the multisite network, WooCommerce tables are left in the database. That makes the database bloated with many redundant tables. FYI, WooCommerce creates a lot of custom tables.

Why do plugins keep database tables?

For a simple reason: if you plan to use the plugin in the future, you won't lose the existing data that the plugin already stored in the database.

Which plugins create custom database tables?

Many plugins do. Here are some of them:

• WooCommerce
• Yoast SEO
• Gravity Forms
• Fluent Forms
• ProfilePress (previously WP User Meta)
• WP Smush
• Duplicator

How to deleting plugin tables with UI?

You can use a tool like phpMyAdmin, HeidiSQL, Sequel Ace, Table Plus, or any database management tool to delete tables in the database manually. This works well, but you need to be careful because it might brake your database.

How to delete plugin tables with code?

To avoid manual action, I prefer to create a script to delete tables. This is the core of that:

function dbt_remove_tables_for_site() {
    global $wpdb;

    $tables = [
        'woocommerce_sessions',
        'woocommerce_api_keys',
        'woocommerce_attribute_taxonomies',
        'woocommerce_downloadable_product_permissions',
        'woocommerce_order_items',
        'woocommerce_order_itemmeta',
        'woocommerce_tax_rates',
        'woocommerce_tax_rate_locations',
        'woocommerce_shipping_zones',
        'woocommerce_shipping_zone_locations',
        'woocommerce_shipping_zone_methods',
        'woocommerce_payment_tokens',
        'woocommerce_payment_tokenmeta',
        'woocommerce_log',
        'wc_webhooks',
        'wc_download_log',
        'wc_product_meta_lookup',
        'wc_tax_rate_classes',
        'yoast_indexable',
        'yoast_indexable_hierarchy',
        'yoast_migrations',
        'yoast_primary_term',
        'yoast_seo_links',
        'ppress_forms',
        'ppress_formsmeta',
        'ppress_meta_data',
        'ppress_plans',
        'ppress_coupons',
        'ppress_customers',
        'ppress_ordermeta',
        'ppress_orders',
        'ppress_sessions',
        'ppress_subscriptions',
        'smush_dir_images',
        'duplicator_packages',
    ];
    foreach ( $tables as $table ) {
        $table = $wpdb->prefix . $table;
        $wpdb->query( "DROP TABLE IF EXISTS $table" );
    }
}

If you need to remove tables from another plugin, then change the list of tables in the script. If you run a multisite like us, then you need to loop through all sites like this:

add_action( 'init', 'dbt_remove_tables' );

function dbt_remove_tables() {
    // Single installation.
    if ( ! function_exists( 'get_sites' ) ) {
        dbt_remove_tables_for_site();
    }

    // Network.
    $sites = get_sites( [
        'fields'            => 'ids',
        'number'            => 0,
        'update_site_cache' => false,
    ] );
    foreach ( $sites as $site ) {
        switch_to_blog( $site );
        dbt_remove_tables_for_site();
        restore_current_blog();
    }
}

I usually put this script in the wp-content/mu-plugins and run it only once. Note that, to make the script works well, you should:

• Deactivate the plugins before running the script
• Do not delete the site from the multisite (if you run a multisite), because if you delete a site, the script won't be able to get it

Recommendations for plugins

A long time ago, WordPress developers recommended:

• Keep the plugin data when deactivating it
• Remove the plugin data when uninstalling it

Recently, I see users switch plugins quite a lot. They often try one plugin and then switch to another to try it. So, keeping the plugin data is good for users. However, it will make your database bloat if you try too many plugins. So, it's best if plugins offer an option to users to keep or delete their data (including options and custom tables) when they uninstall the plugin. This way, users (not the plugin author) decide to clean up the database.

This is the behavior we implemented in Slim SEO, where we create a custom table to monitor 404 URLs. The log increases over time and when users fix all their 404, they might disable this feature and delete the 404 log table. And that's a win-win for both users and plugin authors.