La table de configuration globale de PrestaShop permet à la routine de désinstallation d'un module d'effacer facilement des paramètres appartenant à des extensions totalement sans rapport. Un seul appel à Configuration::deleteByName('width') peut supprimer la valeur de largeur personnalisée d'un autre module, laissant le marchand perplexe et le module fautif apparemment inoffensif.

Pourquoi la table de configuration partagée est importante

PrestaShop stocke les paramètres de chaque module dans une seule table qui ne contient qu'une clé et une valeur. La table ne possède aucune colonne enregistrant quel module a créé une ligne, et elle n'impose aucune convention de nommage. Par conséquent, deux modules qui utilisent par hasard la même clé — par exemple « width » ou « API_DATE_FROM » — liront et écriront la même ligne de la base de données. La dernière écriture l'emporte, et toute suppression ultérieure supprime la ligne pour les deux parties.

Quand le code de désinstallation devient un outil d'effacement de données

Une méthode de désinstallation typique ressemble à ceci :

public function uninstall()
{
    return Configuration::deleteByName('width');
}

L'intention est de nettoyer la propre configuration du module, mais comme la clé n'est pas préfixée (namespaced), l'instruction supprime toute ligne nommée « width ». Aucun avertissement n'est consigné, aucune exception n'est levée ; la ligne disparaît tout simplement. L'autre module du marchand perd silencieusement son paramètre et peut commencer à se comporter de manière étrange.

Le problème devient particulièrement tentant lors d'une mise à jour de version. Un développeur passant de la version 1.0 à la 2.0 pourrait commencer à enregistrer des valeurs sous une clé préfixée telle que MY_MODULE_WIDTH. Pour « nettoyer » les anciennes entrées non préfixées, il ajoute un appel de suppression à la routine de désinstallation, pensant ne supprimer que des données héritées. En réalité, il supprime également tout ce que d'autres extensions ont stocké sous la même clé générique.

Ce que l'audit a révélé

Un audit de 57 dépôts de modules publics a révélé un schéma récurrent :

  • De nombreux modules utilisent des clés génériques comme « width », « height » ou « API_DATE_FROM » sans aucun préfixe dérivé du nom du module.
  • Plusieurs méthodes de désinstallation contiennent des appels à Configuration::deleteByName qui ciblent ces clés génériques.
  • Le problème ne se limite pas à un seul développeur ou à un type particulier de module ; la conception de la table partagée en fait un risque systémique.

L'audit n'a trouvé aucun journal ou message d'erreur qui alerterait un propriétaire de boutique du fait que la configuration d'un autre module a été supprimée. Le seul symptôme est une perte soudaine de paramètres que le marchand peut attribuer à un problème de cache ou à un bug dans son propre code.

Pratiques plus sûres pour les développeurs de modules

  1. Préfixez chaque clé (Namespace) – ajoutez le nom technique du module au début de chaque clé de configuration (par exemple, my_module_width). Cela crée un identifiant unique sans dépendre d'une colonne de propriété distincte.
  2. Évitez de supprimer les anciennes clés non préfixées – laisser quelques lignes obsolètes dans la table ne coûte pratiquement rien en stockage et élimine le risque de dommages collatéraux.
  3. Vérifiez la propriété avant la suppression – si une suppression est réellement nécessaire, vérifiez d'abord que la valeur de la clé a été définie par votre propre code (par exemple, stockez une valeur de marquage que seul votre module connaît).
  4. Auditez les méthodes de désinstallation – recherchez les appels à deleteByName dans la base de code. Chaque occurrence doit être examinée pour confirmer que la clé possède un préfixe unique.
  5. Documentez la convention de nommage – incluez une courte directive dans le README du module afin que les futurs contributeurs comprennent l'importance des clés préfixées.

Tester les suppressions accidentelles entre modules

Une manière pratique de détecter le bug avant qu'il n'atteigne une boutique en production :

  • Initialisez la table de configuration avec une clé appartenant à un autre module (par exemple, other_module_setting => test).
  • Exécutez la routine de désinstallation du module dans un environnement contrôlé.
  • Vérifiez (Assert) que la clé initialisée existe toujours après la fin de la désinstallation.

L'automatisation de ce contrôle dans la suite de tests unitaires du module garantit que tout changement futur introduisant un appel deleteByName égaré fera échouer le test, incitant ainsi à une révision.

Ce que les propriétaires de boutiques doivent surveiller

Les propriétaires de boutiques voient rarement les lignes internes de la base de données, mais ils peuvent repérer le symptôme : après avoir désactivé ou désinstallé un module, une autre extension revient soudainement à ses paramètres par défaut. Si cela se produit, demandez au développeur de vérifier que le code de désinstallation du module respecte la table de configuration globale. Demandez une liste de toutes les clés de configuration utilisées par le module ; toute clé sans préfixe clair est un signal d'alarme.

À retenir

La conception de PrestaShop fait de la table de configuration une ressource partagée, et une routine de désinstallation imprudente peut effacer les paramètres d'un autre module sans laisser de trace. En utilisant des espaces de noms pour les clés, en évitant un nettoyage trop agressif et en ajoutant un test simple qui protège les entrées tierces, les développeurs peuvent prévenir la perte silencieuse de données et garantir la stabilité des boutiques des commerçants. L'effort requis est minimal, mais le coût d'un paramètre perdu — plaintes des clients, tickets de support et réputation entachée — peut être bien plus élevé.