Opened 6 years ago
Closed 2 years ago
#46832 closed enhancement (wontfix)
Notice or Warning if a plugin create table and do not delete them
Reported by: | sebastienserre | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Site Health | Keywords: | dev-feedback |
Focuses: | administration | Cc: |
Description
Hello
Lots of plugins are creating their own tables but they don't delete them when the plugin is deleted or deactivated.
Is a way exists (maybe with Healthsite) to check on deactivation if a
CREATE TABLE
exists and if so, if the register_deactivation_hook()
is used...
If not used, surely tables are not deleted so => notices
Change History (8)
#2
@
6 years ago
I have a related question. If a plugin is deleted, any table created by it should also be deleted, which is reasonable. But I think deactivating a plugin should keep a table (if created by it) intact with its data because the same plugin could be activated later on. If table is removed when deactivated, all data in it will be lost. However, this is kind of off topic since this depends on the plugin builders how they see it.
Now, regarding displaying notice, if a plugin is removed completely what is the options left for the core to determine that it was removed but table created by it wasn't if there was no signature of this plugin is left somewhere?
Taking both these use cases into consideration the situations are:
- Plugin deactivated, but ideally a table created by it should not be removed, so notice doesn't have much of an impact.
- Plugin is removed from the system means WordPress doesn't know anymore that there was a plugin which created a table. So, only displaying notice doesn't make any difference here as well. The only option however, as I see, is to check if there are only bundled / shipped plugins are present and there is/are additional tables exist in the database other than that those created by WordPress installation itself.
The bottom line is, is it really a task of WordPress core to do this stuff or it is the responsibility of the plugin developers to clean up tables like this?
Please correct me if I have not understood the underlying issue properly.
#4
@
4 years ago
@sebastienserre I don't think developers should be forced to delete custom tables they create with the plugin. What if someone wants to have a plugin de-activated or deleted but still keep their data in the future? For example if someone has a contact form installed with a bunch of submissions, maybe they want to keep those in the future.
The only thing I could agree with that might be a good idea is to have the capability to list all the custom tables, and maybe have a page in the administration panel list which plugin created them and allow someone to remove those.
#5
@
4 years ago
As a best practices, AMHA Plugin developers should ask if user want to keep their data on deletion.
I think we have something to do to reduce database size of a WordPress install. No need to store and keep alive a Datacenter for unused data.
#7
@
3 years ago
- Component changed from Plugins to Site Health
I am moving this to the Site Health component, as that is where WordPress would need to display such a notice.
In doing so, I don't think this is something WordPress can reasonably do without maintaining a checklist of plugins known to add tables, determining if the plugin is active and then checking if the table exists.
With 59,351 plugins in the wordpress.org plugin repository at the time of writing, I don't think this is a practical task. Limiting the check to the most popular plugins is problematic for other reasons.
I agree plugins ought to clean up after themselves in most circumstances but I don't think it's something WordPress can test for practically. For now, I am leaving this ticket open to allow some of the Site Health component maintainers to review the ticket.
#8
@
2 years ago
- Keywords 2nd-opinion needs-patch removed
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
I agree that it's just not feasible for core to keep track of this. Although it would be possible, the implementation would be resource intensive and bulky from a web application point of view.
Instead, if you feel strongly about it, I would suggest opening this as a discussion point with the plugin review team, of introducing guidelines for authors to follow, at least for the WordPress.org hosted plugins, in proper handling of data.
I'm going to mark this as wontfix
from a core perspective, but it is perfectly fine to discuss further if y'all have other thoughts on it.
By notice, I mean something with https://developer.wordpress.org/reference/functions/_doing_it_wrong/