Désinstaller proprement les modules

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Submitted by webmestre on

Bonjour,

la majorité des modules, même venant de drupal.org, ne peut être désinstallé proprement et surtout définitivement. Ils n'apparaissent pas tous dans l'onglet "désinstaller".

Une tentative précédente de suppression pure et simple à partir du FTP des modules désactivés a donné une dé-sélection de tous les modules. Ca calme car il a fallu tout cocher manuellement pour réparer en live.

MA QUESTION : comment supprimer manuellement des modules sans tout planter ET alléger par la même occasion la BDD (203 tables : 49Mo avec 20 inscrits et moins de 100 nodes) ?

Forum : 
Support général
Version de Drupal : 
6.x
Tags : 
désinstaller modules

Soumis par drupalfrance le 7 Novembre, 2010 - 18:53

Salut,

Un module ne possède pas obligatoirement du code de désinstallation. Concrètement, la plupart du temps, la désinstallation d'un module sert à supprimer les tables et les variables créées par le module dans la BDD. Si un module ne crée ni table ni variables, il n'a pas besoin de code de désinstallation.

Pour supprimer manuellement un module qui a créé des tables et des variables, une "astuce" est de supprimer manuellement les tables et les variables dont le nom commencent par le nom du module (ex : supprimer les tables toto_data et toto_log pour un module "toto"). A utiliser avec précaution, car rien n'oblige un module à nommer ses tables et des variables d'une certaine façon.

En revanche, je n'ai pas du tout compris ta remarque : "Une tentative précédente de suppression pure et simple à partir du FTP des modules désactivés a donné une dé-sélection de tous les modules. Ca calme car il a fallu tout cocher manuellement pour réparer en live." Effacer le code PHP sur module sur le serveur n'a aucune conséquence sur la BDD de Drupal. Je ne vois donc pas le rapport entre manipuler les modules sur le FTP et la BDD.

Soumis par webmestre le 7 Novembre, 2010 - 19:15

Merci de ces conseils.

Pour ce qui est de la suppression déjà testée d'un seul module via ftp, proprement et alors qu'il était dé-sélectionné, cela a généré la dé-sélection de tous les modules ajoutés après l'install. Seuls le modules core et optional de base (help, comment...) ont survécu.

Il m'a fallu tout re-cocher par la suite.

Ce butterfly effect est-il normal, docteur ?

Soumis par drupalfrance le 7 Novembre, 2010 - 19:58

Ça paraît bizarre...

Ou alors, peut-être que le module que tu as supprimé était requis par d'autres modules pour fonctionner ? En effaçant un module, tu as déclenché la désactivation des autres modules qui ne pouvaient alors plus fonctionner. Via une réaction en chaîne, ça pourrait avoir désinstallé un nombre important de modules.

Soumis par webmestre le 7 Novembre, 2010 - 21:57

Si j'extrapole, on peut supposer qu'un module "fils" peut être désactivé puis supprimé manuellement par FTP.
En revanche, un module "père", supprimé manuellement, entraîne des pertes pour les "fils".
Cela me semble très logique.

Ce que je décris est la désactivation complète de TOUS les modules autres que CORE et OPTION de base.
Et ça, ça fait peur !
Est-ce une catastrophe déjà répertoriée par les utilisateurs de Drupal ou j'ai des chances de passer à la télé ? ;-)

EDIT : existe-t-il un moyen assez automatique de savoir si un module crée une table, s'il ne fait juste qu'écrire dans une table déjà existante ?
Si pas automatique, où dans le code du module ?

Soumis par drupalfrance le 8 Novembre, 2010 - 10:04

C'est la première fois que j'entends parler de ce pb.

Pour savoir si un module crée une table, un truc rapide serait de regarder si le module en question possède un fichier .install. Plus précisément, il devrait y avoir un hook_schema() dans ce fichier.

Cela dit, ce n'est pas une garantie. Si le module est mal codé (ce qui semble être le cas, puisque tu parles de modules qui ne nettoient pas leurs tables au moment de leur désinstallation), la table pourrait avoir été créée par d'autres moyens.

Quant à savoir si le module écrit dans une table existante, c'est quasi impossible à faire automatiquement (ça peut être fait via une requête SQL maison ou n'importe quelle fonction de l'API Drupal qui touche à la base).