Uninstalling a module without leaving traces

Disable, uninstall, delete: three distinct operations

Disabling stops the module running but touches nothing: its files stay, its tables stay, its settings stay, and its scheduled jobs can keep firing if they were registered on the server. Useful for a test, not for removal.

Uninstalling triggers the removal routine the module provides. A well-written module drops its tables, its settings and its hook attachments there. A badly written one does nothing at all, or fails silently. On WordPress the distinction is sharper still: the uninstall routine only runs when the extension is permanently deleted, not when it is deactivated, which almost nobody knows.

Deleting removes the files. If uninstalling didn’t happen first, the data stays in the database with no code left to read or clean it: that is what turns up years later.

The particular case of tables left behind

This is what I meet most often on a store taken over: a database holding the tables of modules removed long ago, sometimes large, sometimes full of logs never purged. They don’t slow pages directly, since nothing reads them, but they weigh on backups, restores and migrations, and they blur the reading of the database for any future work.

Cleaning isn’t complicated but it demands care: you must know for certain which module each table belonged to before touching it. A table prefix resembling that of a removed module can belong to a module still active. I do that sorting on a copy of the database, and I keep a full export before any deletion.