Repository navigation
wp site delete leaves custom tables in DB #452
Description
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
Activity
danielbachhuber commentedon Nov 21, 2023
Thanks for the report, @JanThiel
Few questions:
$wpdb?If WordPress core doesn't delete the tables by default, I don't think we'll want the default behavior for
wp site deleteto be different. We could potentially enable the behavior with a flag, though.swissspidy commentedon Nov 21, 2023
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_wrongby not properly hooking into thewp_delete_sitehook to delete its custom tables.Edit: For completeness,
wp_delete_sitecalls$wpdb->delete( $wpdb->blogs, array( 'blog_id' => $old_site->id ) )JanThiel commentedon Nov 21, 2023
@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:
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_wrongswissspidy commentedon Nov 21, 2023
This sounds related to https://core.trac.wordpress.org/ticket/43162, which has a similar answer:
This filter is fired via
wp_uninitialize_site()inwp_delete_site()JanThiel commentedon Nov 21, 2023
In any case I would vote for a flag to drop all tables for a site based on its prefix. Like
wp search-replaceallows 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 commentedon Nov 21, 2023
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 commentedon Nov 21, 2023
With the aforementioned core ticket this would be automatically handled for us, no need to add another flag.
shawnhooper commentedon Nov 22, 2023
@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 commentedon Nov 22, 2023
@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 commentedon Nov 22, 2023
I think we can leave this one open for now and revisit once the core ticket is merged.
JanThiel commentedon Nov 22, 2023
Just for reference, here is the reply from GravityForms:
swissspidy commentedon May 27, 2026
Still no movement on that Trac ticket. So yeah maybe we need to resolve this ourselves. A
--delete-tables-with-prefixflag could work. And once the Trac ticket is fixed, we can deprecate the flag.