Deux modules qui se marchent dessus

Les quatre formes de conflit que je rencontre

Le conflit de surcharge. Sur PrestaShop, un module peut remplacer le comportement d’une classe du cœur en déposant un fichier de surcharge. Deux modules qui veulent remplacer la même méthode de la même classe ne peuvent pas cohabiter : le second refuse de s’installer, ou pire, écrase silencieusement le premier si les fichiers ont été déposés à la main. C’est la cause la plus fréquente d’un module qui « ne fait plus rien » alors qu’il est actif.

Le conflit d’ordre. Deux modules accrochés au même endroit s’exécutent l’un après l’autre, et le second peut annuler ce que le premier a fait : recalculer un total, remplacer un contenu, redéfinir un prix. L’ordre est modifiable, et modifier l’ordre suffit parfois à tout régler.

Le conflit de bibliothèque. Deux modules chargent chacun leur propre version d’une même bibliothèque JavaScript. La page charge les deux, la seconde écrase la première, et tout ce qui dépendait de la version initiale s’arrête. C’est visible dans la console du navigateur, pas dans les journaux du serveur.

Le conflit de nom. Deux extensions déclarent une fonction ou une classe portant le même nom, et PHP s’arrête net avec une erreur fatale de redéclaration. Sur WordPress, c’est un classique des extensions qui embarquent la même bibliothèque tierce sans précaution.

Une fois le coupable identifié, quatre issues possibles

La plus simple : changer l’ordre d’exécution, quand le conflit vient d’un écrasement de résultat. La deuxième : reporter la fonction d’un des deux modules dans un module unique qui fait les deux, ce qui supprime le conflit à la racine. La troisième : remplacer l’un des deux par une solution qui ne surcharge pas la même chose. La quatrième, la moins durable, consiste à corriger le module fautif dans son code — mais cette correction saute à sa prochaine mise à jour si elle n’est pas isolée.

Je signale toujours quand le conflit vient d’une pratique fragile plutôt que d’un accident : un module qui dépose une surcharge de classe du cœur pour ajouter un champ, ou qui embarque sa propre copie d’une bibliothèque commune, produira d’autres conflits plus tard, avec d’autres modules. Le remplacer coûte parfois moins cher que de le rafistoler à chaque fois.