Désinstaller un module sans laisser de traces
Retirer un module semble être l’opération la plus simple du monde. En réalité, désactiver, désinstaller et supprimer sont trois choses différentes, et aucune des trois ne garantit que le module n’a plus aucune trace dans votre boutique.
Désactiver, désinstaller, supprimer : trois opérations distinctes
Désactiver arrête l’exécution du module mais ne touche à rien : ses fichiers restent, ses tables restent, ses réglages restent, et ses tâches planifiées peuvent continuer de tourner si elles ont été enregistrées côté serveur. C’est utile pour un test, pas pour un retrait.
Désinstaller déclenche la procédure de désinstallation prévue par le module. Un module bien écrit y supprime ses tables, ses réglages et ses points d’accroche. Un module mal écrit ne fait rien du tout, ou échoue en silence. Sur WordPress, la nuance est encore plus marquée : la procédure de désinstallation ne s’exécute qu’à la suppression définitive de l’extension, pas à sa désactivation, ce que presque personne ne sait.
Supprimer efface les fichiers. Si la désinstallation n’a pas eu lieu avant, les données restent en base sans plus aucun code pour les lire ni les nettoyer : ce sont elles qu’on retrouve des années après.
Ce qui survit à une désinstallation bâclée
- Des tables de base de données qui grossissent encore, sans plus rien pour les lire
- Des lignes de configuration chargées à chaque requête, qui pèsent sur toutes les pages
- Des tâches planifiées enregistrées côté serveur, qui appellent un fichier disparu
- Des entrées de menu ou des onglets d’administration qui pointent vers rien
- Des fichiers déposés hors du dossier du module : surcharges, ressources, images
- Une clé d’accès à un service tiers restée enregistrée quelque part
Comment je retire un module proprement
-
Sauvegarder d’abord, fichiers et base
La désinstallation est destructive par nature : elle supprime des tables. Si ces tables contiennent un historique utile, il faut l’exporter avant, parce qu’après il n’y a plus rien à exporter.
-
Désinstaller avant de supprimer
Dans cet ordre, jamais l’inverse. Supprimer les fichiers d’abord rend la désinstallation impossible et condamne les données à rester.
-
Chercher ce qui a été posé ailleurs
Surcharges de classes, ressources ajoutées au thème, tâches planifiées, entrées d’administration. Ces éléments-là sont rarement gérés par la procédure de désinstallation.
-
Vider les caches et revérifier le front
Un module retiré laisse souvent une trace visuelle jusqu’au vidage du cache, et une erreur peut n’apparaître que sur une page peu visitée. Je passe une commande de test après tout retrait.
Le cas particulier des tables restées derrière
C’est ce que je rencontre le plus souvent sur une boutique reprise : une base qui contient les tables de modules retirés depuis longtemps, parfois volumineuses, parfois pleines de journaux qui n’ont jamais été purgés. Elles ne ralentissent pas directement les pages, puisque plus rien ne les lit, mais elles alourdissent les sauvegardes, les restaurations et les migrations, et elles brouillent la lecture de la base pour toute intervention future.
Le nettoyage n’est pas compliqué mais il demande de la prudence : il faut identifier avec certitude à quel module appartenait chaque table avant d’y toucher. Un préfixe de table qui ressemble à celui d’un module retiré peut appartenir à un module encore actif. Je fais ce tri sur une copie de la base, et je conserve un export complet avant toute suppression.
Pages liées
-
Nettoyer la base de données WordPress
La procédure côté WordPress, y compris les réglages restés en place.
-
Audit du parc de modules
Pour savoir ce qui est encore utilisé avant de décider ce qui part.
-
Sauvegarder la boutique avant intervention
La sauvegarde à faire avant toute désinstallation, sans exception.
-
Les tâches cron ne s’exécutent pas
Quand un module retiré laisse une tâche planifiée qui échoue en boucle.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.