Make WordPress Core

Opened 4 years ago

Closed 17 months ago

#50799 closed feature request (wontfix)

Clean orphaned custom database tables

Reported by: stuffradio's profile stuffradio Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Site Health Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

There was a ticket I just commented today (#46832) where someone suggested forcing a plugin developer to use the deactivation hook and cleaning the custom created tables. I pointed out how some people might want to keep some data in case they want to activate the plugin again in the future and still have their data.

My idea is to create a section in Site Health where it lists all the non-standard WordPress tables and the plugin that created the tables so an administrator could clean up their database from the admin panel. Another part to this could be to slightly alter the plugin deactivation to have a hard and soft deactivate/delete plugin link where the soft delete/deactivate would simply remove the plugin, and the hard delete/deactivate would delete the associated tables and data.

I'm open to suggestions/feedback on this idea.

Change History (3)

#1 follow-up: @SergeyBiryukov
4 years ago

  • Description modified (diff)

Hi there, welcome back to WordPress Trac! Thanks for the ticket.

Another part to this could be to slightly alter the plugin deactivation to have a hard and soft deactivate/delete plugin link where the soft delete/deactivate would simply remove the plugin, and the hard delete/deactivate would delete the associated tables and data.

Just noting that plugins can already do this by using one of the uninstall methods instead of a deactivation hook.

As noted in the plugin handbook:

The deactivation hook is sometimes confused with the uninstall hook. The uninstall hook is best suited to delete all data permanently such as deleting plugin options and custom tables, etc.

Related: #50346

#2 in reply to: ↑ 1 @stuffradio
4 years ago

Replying to SergeyBiryukov:

Hi there, welcome back to WordPress Trac! Thanks for the ticket.

Another part to this could be to slightly alter the plugin deactivation to have a hard and soft deactivate/delete plugin link where the soft delete/deactivate would simply remove the plugin, and the hard delete/deactivate would delete the associated tables and data.

Just noting that plugins can already do this by using one of the uninstall methods instead of a deactivation hook.

As noted in the plugin handbook:

The deactivation hook is sometimes confused with the uninstall hook. The uninstall hook is best suited to delete all data permanently such as deleting plugin options and custom tables, etc.

Related: #50346

What do you think about the idea of having an "orphaned" table section in site health that shows all the tables un-associated with a plugin, or just something that shows all the tables not created by WordPress itself so a person can decide whether they want to "clean"(remove) that table and free up more resources?

#3 @Clorith
17 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I'm thinking this feels more like a plugin territory case, let me elaborate.

From the perspective of core, it's not possible to know which plugin or theme has introduced any custom database tables, or other database entries, and it's not really in scope for core to maintain a reference of this kind of information.

It would also be "dangerous" for core to offer direct database manipulation alternatives, so saying "here are tables not added by core" as a catch-all would potentially lead to someone reading an article on website performance, and removing them via user interfaces in core.

My view on the core approach to Site Health is that users should be presented with actionable items, that means no options require user interactions to make the right choices (to this extent), but simple action buttons that will do what needs doing, without fear of breaking their site.

There are various plugins already that specialize in this though, and I believe this is best left to them. On this basis I'm marking this as wontfix at this time, but please feel free to provide any new information in the ticket, and it is possible to re-open them in the future if this approach should ever be taken.

Note: See TracTickets for help on using tickets.