wp site delete leaves custom tables in DB

[JanThiel]

When deleting a site within a Multisite with wp site delete <id> custom tables within the DB created by plugins remain within the database.

Possible solutions:

• Add a flag to remove all tables with the sites prefix wp_<id>_ using SQL
• Remove all tables with the site prefix by default

WP-CLI 2.8.1 WP 6.3.1

[danielbachhuber]

Thanks for the report, @JanThiel

Few questions:

1. Are the custom database tables registered to $wpdb?
2. How does WordPress core handle this same scenario?
3. Can you provide explicit steps to reproduce?

If WordPress core doesn't delete the tables by default, I don't think we'll want the default behavior for wp site delete to be different. We could potentially enable the behavior with a flag, though.

[swissspidy]

This command uses the WordPress-provided wpmu_delete_blog() / wp_delete_site() functions to delete a site and drop its tables. It sounds like the plugins you are using are _doing_it_wrong by not properly hooking into the wp_delete_site hook to delete its custom tables.

Edit: For completeness, wp_delete_site calls $wpdb->delete( $wpdb->blogs, array( 'blog_id' => $old_site->id ) )

[JanThiel]

@swissspidy @danielbachhuber Thanks for your quick response :-)

Sounds like a reasonable possibility that some plugins are simply doing it wrong.

Still the remaining tables are from quite common plugins:

• Gravity Forms
• Layerslider
• Yoast
• WP Mail SMTP

Steps to reproduce: We simply call wp site delete <id> on a site which use the above plugins.

I will open a ticket with Gravity Forms to ask for their reasoning. If they have some, I would vote for the optional deletion flag as that allows a complete cleanup for any case. Even with plugins _doing_it_wrong

[swissspidy]

This sounds related to https://core.trac.wordpress.org/ticket/43162, which has a similar answer:

Plugins can (and should) use the wpmu_drop_tables filter to add their custom database tables to the array of tables that are dropped when a site is deleted.

This filter is fired via wp_uninitialize_site() in wp_delete_site()

[JanThiel]

In any case I would vote for a flag to drop all tables for a site based on its prefix. Like wp search-replace allows with --all-tables-with-prefix. WP-CLI is meant as a tool for people who know what they do. And as you cannot force plugin authors to do it right, a CLI solution for the right cleanup would be a benefit in maintaining WP sites.

[shawnhooper]

I like the idea of having this available as a flag as well @JanThiel. 👍

I wrote a "delete orphaned multisite tables" custom WP-CLI command years ago that has been well received. I think adding this to WP-CLI as an official flag would be a great idea.

https://github.com/shawnhooper/delete-orphaned-multisite-tables

[swissspidy]

With the aforementioned core ticket this would be automatically handled for us, no need to add another flag.

[shawnhooper]

@swissspidy Many plugin developers won't use that filter though, leaving behind a mess. Giving CLI the ability to do some cleanup would be nice I think.

[JanThiel]

@swissspidy Just checked that core ticket. You are right, that will solve this issue directly in core once and for all.

Should we close this issue as wontfix? Should be reasonable not to duplicate functionality in WP-CLI that will land in core shortly.

[swissspidy]

I think we can leave this one open for now and revisit once the core ticket is merged.

[JanThiel]

Just for reference, here is the reply from GravityForms:

There's no specific reason for Gravity Forms to not use that filter to delete the tables when the site is deleted. It's just something that wasn't implemented.