Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Tout a déraillé après l’installation d’un module

« J’ai installé un module d’avis clients et c’est le transporteur qui ne s’affiche plus. » Cette phrase revient régulièrement, et elle n’a rien d’absurde. Un module n’est pas une brique isolée : il ajoute du code, crée des tables, s’accroche à des emplacements qu’il ne possède pas, et charge ses propres scripts sur des pages qui ne le concernent pas.

Décrire mon problème Discuter sur WhatsApp

Ce qu’un module modifie réellement

À l’installation, un module fait bien plus que déposer des fichiers. Il enregistre des accroches : des points du site où son code sera exécuté, souvent une dizaine, parfois sur des pages qu’il ne modifie visuellement pas. Il crée ses tables et ajoute parfois des colonnes à des tables existantes. Il ajoute ses feuilles de style et ses scripts à la file de chargement, où l’ordre compte. Et il peut installer une surcharge, c’est-à-dire un fichier qui remplace un comportement du cœur pour tout le site.

Deux modules qui surchargent le même comportement entrent en conflit : le second écrase le premier, ou le remplace partiellement. C’est la cause la plus fréquente d’un bug qui apparaît loin du module installé, et c’est aussi celle qui survit à la désinstallation, parce qu’un fichier de surcharge n’est pas toujours retiré proprement.

Isoler le module responsable

  1. Confirmer la chronologie

    Le défaut existait-il avant ? Sur un site où plusieurs personnes interviennent, la coïncidence apparente n’est pas toujours la cause réelle. Une mise à jour lancée le même jour est un candidat aussi sérieux.

  2. Désactiver plutôt que désinstaller

    La désactivation est réversible et conserve les réglages. La désinstallation supprime souvent la configuration, les tables et parfois des données saisies. Sur un module de paiement ou de transport, la différence est majeure.

  3. Procéder par moitiés

    Avec beaucoup de modules récents, désactiver la moitié d’un coup divise le champ à chaque essai. C’est nettement plus rapide qu’un par un, et cela reste réversible.

  4. Vérifier le répertoire des surcharges

    Un fichier de surcharge daté du jour de l’installation, portant le nom d’une classe du cœur, désigne le coupable même après désactivation du module.

  5. Regarder la console du navigateur

    Quand le symptôme est un bouton inerte ou un menu figé, l’erreur de script nomme le fichier fautif, et le chemin de ce fichier contient le nom du module.

Les affrontements que je rencontre le plus

  • Deux modules qui surchargent le même comportement du cœur : le dernier installé gagne, et la fonction du premier disparaît sans message.
  • Deux modules qui chargent la même bibliothèque de scripts dans des versions différentes : la page charge les deux, et la seconde écrase la première.
  • Un module de cache ou d’optimisation qui regroupe et compresse les fichiers : il casse les scripts d’un autre module qui supposait un ordre de chargement précis.
  • Un module accroché au tunnel de commande qui échoue silencieusement, laissant un bouton sans effet plutôt qu’un message d’erreur.
  • Un module installé sur une version du CMS différente de celle annoncée comme compatible : il fonctionne en apparence et échoue sur un cas particulier.

Continuer sur la bonne page

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.

De quel type de développement s’agit-il ?
Partez-vous de zéro ou faut-il faire évoluer un existant ?

Reprendre un code existant non maîtrisé demande souvent un audit avant même de commencer à développer.

Une stack technique est-elle imposée ? (facultatif)
Combien de personnes utiliseront l’outil ? (facultatif)
Quelle est votre échéance ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Le module n’a rien à voir avec la fonction cassée, est-ce vraiment lui ?
C’est fréquent et parfaitement logique. Un module s’accroche à des emplacements partagés et charge ses scripts sur l’ensemble du site. Le lien n’est pas fonctionnel, il est technique : même emplacement, même fichier, même comportement surchargé.
Faut-il désinstaller le module ou le corriger ?
Cela dépend de ce qu’il apporte. Si une alternative maintenue existe, le remplacement est plus sain qu’une adaptation. Si le module est indispensable et bien écrit, ajuster l’ordre de chargement ou l’accroche suffit souvent.
Comment tester un module sans risque ?
Sur une copie du site, jamais directement en production. Une préproduction n’a pas besoin d’être une infrastructure complète : une copie des fichiers et de la base, sur une adresse fermée à l’indexation, suffit pour ce type de test.
Un module gratuit est-il plus risqué qu’un module payant ?
Le prix n’est pas l’indicateur. Ce qui compte est la date de la dernière mise à jour, la compatibilité annoncée avec votre version, et le fait que l’éditeur publie encore. Un module payant abandonné est plus risqué qu’un module gratuit suivi.
Peut-on savoir à l’avance si deux modules vont se gêner ?
En partie : comparer les emplacements auxquels ils s’accrochent et les surcharges qu’ils installent donne un premier avis avant même l’installation. Le reste se vérifie sur une copie, pas sur la boutique en production.