Le gestionnaire de modules dans PrestaShop affiche une erreur XML ? Nous expliquons ci-dessous pourquoi cela se produit et comment le résoudre efficacement, sans avoir besoin de mettre à jour la boutique ou d'intervenir dans la base de données.
Les plus importants d'entre eux sont :
L'erreur apparaît le plus souvent directement dans le panneau d'administration – dans l'onglet Modules après être entré dans Gestionnaire de modules. Les communications peuvent se présenter comme suit :
PrestaShop envoie des requêtes HTTP à l'API PrestaShop Addons pour récupérer les listes de modules actuelles. Un point de terminaison d'exemple ressemble à ceci :
Le magasin attend une réponse au format XML. Le problème survient quand :
Qu'est-ce qui peut cesser de fonctionner dans le panneau :
Avant d'apporter des modifications, il est conseillé de vérifier ce qui se trouve actuellement dans les fichiers. Par SSH nous faisons :
Si le fichier est vide, contient du HTML (par exemple, une page d'erreur 503) ou du JSON au lieu d'XML, c'est la source du problème.
La solution la plus rapide consiste à remplacer le contenu des fichiers problématiques par un XML minimal et correct. Via SSH, nous exécutons :
Vous pouvez également télécharger des fichiers manuellement via FTP. Chacun d'eux devrait ressembler à ceci :
Pour bloquer définitivement les tentatives de téléchargement de XML depuis l'API des modules, nous créons un override de classe Outils. Nous créons un fichier :
Sur le contenu suivant :
Propriété $is_addons_up = faux cela PrestaShop à ne pas essayer de se connecter à l'API Addons – et par conséquent, à ne pas télécharger ni écraser les fichiers XML.
Après avoir créé le fichier de remplacement, nous vidons le cache. Pour PrestaShop 1.7 / 8.x:
Vous pouvez également vider le cache depuis le panneau d'administration : Avancé > Performance > Vider le cache.
Si nous ne voulons pas utiliser de surcharge, il est possible de définir les fichiers XML en lecture seule. PrestaShop ne pourra ainsi pas les écraser :
Il est bon de savoir que dans un environnement de production, la plupart de ces fonctionnalités ne sont de toute façon pas utilisées au quotidien :
Étapes recommandées :
Contactez nous
Quels sont les fichiers XML dans le répertoire config/xml/ ?
PrestaShop stocke localement plusieurs fichiers XML qui sont responsables du fonctionnement de la section Modules > Gestionnaire de modules dans le panneau d'administration. Ils sont téléchargés cycliquement à partir d'une API externe PrestaShop Addons et enregistrées dans le répertoire :config/xml/- liste_modules_indispensables.xml – liste des modules marqués comme „ incontournables ” par PrestaShop
- modules_native_addons.xml – liste des modules natifs disponibles dans les modules complémentaires
- default_country_modules_list.xml – modules suggérés pour un pays spécifique
- liste_modules_fiables.xml – liste des modules de confiance vérifiés par PrestaShop
Une erreur XML se présente comme un message indiquant un problème dans la structure ou la syntaxe d'un fichier XML. Elle peut apparaître à différents endroits : * **Dans le navigateur web :** Si vous essayez d'ouvrir un fichier XML directement dans un navigateur et qu'il contient des erreurs, le navigateur affichera généralement un message d'erreur clair, indiquant la ligne et la colonne où le problème a été détecté. * **Dans un éditeur XML ou un IDE :** Lorsque vous travaillez sur un fichier XML avec un outil dédié (comme Notepad++, VS Code avec un plugin XML, Oxygen XML Editor, etc.), l'éditeur peut surligner les erreurs, ajouter des icônes d'avertissement ou afficher des messages d'erreur dans un panneau dédié. * **Lors du traitement par une application :** Si une application tente de lire, d'analyser ou de traiter un fichier XML qui contient des erreurs, elle échouera et produira généralement une exception ou un message d'erreur décrivant la nature du problème XML. * **Dans les logs d'erreurs :** Les erreurs liées à l'analyse XML sont souvent enregistrées dans les fichiers journaux (logs) d'une application ou d'un serveur web pour être examinées ultérieurement. Les erreurs XML courantes incluent : * **Balises non fermées :** Une balise d'ouverture (ex: ``) n'a pas sa balise de fermeture correspondante (ex: ``). * **Balises imbriquées incorrectement :** Les balises ne sont pas correctement hiérarchisées. Par exemple, `` est incorrect. * **Caractères spéciaux non échappés :** Les caractères comme ``, `&`, `'`, `"` doivent être remplacés par leurs entités XML (`<`, `>`, `&`, `'`, `"`) lorsqu'ils apparaissent dans du contenu texte, sauf s'ils font partie des balises elles-mêmes. * **Attributs mal formés :** Les attributs doivent toujours être entourés de guillemets doubles ou simples (ex: `attribut="valeur"`). * **Problèmes d'encodage :** L'encodage déclaré dans le fichier XML (ex: ``) ne correspond pas à l'encodage réel du fichier. * **Non-respect de la structure définie par un DTD ou un schéma (XSD) :** Si le fichier XML est censé suivre une structure spécifique (schéma), une erreur peut survenir si cette structure n'est pas respectée.
L'erreur apparaît le plus souvent directement dans le panneau d'administration – dans l'onglet Modules après être entré dans Gestionnaire de modules. Les communications peuvent se présenter comme suit :Erreur trouvée : balise de début attendue, '<' non trouvé dans le fichier must_have_modules_list.xml
Erreur trouvée : balise de début attendue, '<' non trouvé dans le fichier modules_native_addons.xml
Erreur trouvée : balise de début attendue, '<' non trouvé dans le fichier default_country_modules_list.xmlNote
Ces erreurs apparaissent dans PrestaShop 1.7 et PrestaShop 8.x. Dans les versions antérieures 1.6, le mécanisme fonctionne de manière similaire, bien que l'emplacement de certains fichiers puisse varier.
D'où vient cette erreur ?
PrestaShop envoie des requêtes HTTP à l'API PrestaShop Addons pour récupérer les listes de modules actuelles. Un point de terminaison d'exemple ressemble à ceci :https://api.addons.prestashop.com/?version=1.7.8.x&method=listing&action=must-have- Les modules complémentaires d'API renvoient une réponse dans un format différent (par exemple, JSON ou une page d'erreur HTML)
- La connexion à l'API est bloquée par un pare-feu ou une configuration du serveur
- le serveur de la boutique n'a pas accès aux ressources externes (pas de trafic sortant HTTP/HTTPS)
- Les modules complémentaires de l'API sont temporairement indisponibles ou renvoient un délai d'attente dépassé
- La version de PrestaShop est trop ancienne et n'est plus prise en charge par l'API.
Est-ce que le bug affecte le fonctionnement de la boutique ?
Succès
Le frontend du magasin, le panier, les commandes, les paiements et tous les processus d'achat fonctionnent normalement. L'erreur ne concerne que le panneau d'administration – spécifiquement la section de gestion des modules.
- liste des modules recommandés
- section „ à avoir ” dans le gestionnaire de modules
- Compléments de marché accessibles depuis l'administrateur
- Suggestion de modules pour le pays
- chargement plus lent de la page Modules (délai de connexion à l'API observé)
Étape 1 – Vérification du contenu des fichiers XML
Avant d'apporter des modifications, il est conseillé de vérifier ce qui se trouve actuellement dans les fichiers. Par SSH nous faisons :cat config/xml/must_have_modules_list.xmlConseil
Pour vérifier le contenu du fichier, vous pouvez également utiliser le gestionnaire de fichiers du panneau d'hébergement (par exemple, Hestia CP, cPanel) ou un client FTP – aucun accès SSH n'est requis.
Étape 2 – Remplacement des fichiers par le XML correct
La solution la plus rapide consiste à remplacer le contenu des fichiers problématiques par un XML minimal et correct. Via SSH, nous exécutons :echo '' > config/xml/must_have_modules_list.xml
echo '' > config/xml/modules_native_addons.xml
echo '' > config/xml/default_country_modules_list.xml
echo '' > config/xml/trusted_modules_list.xmlAvertissement
Seul le remplacement des fichiers résoudra temporairement le problème. PrestaShop, lors du prochain rafraîchissement de la page des modules, essaiera à nouveau de récupérer les données de l'API et pourra écraser les fichiers avec une réponse erronée.
Étape 3 – solution permanente par surcharge de classe
Pour bloquer définitivement les tentatives de téléchargement de XML depuis l'API des modules, nous créons un override de classe Outils. Nous créons un fichier :override/classes/Tools.php<?php
class Tools extends ToolsCore
{
protected static $is_addons_up = false;
}Après avoir créé le fichier de remplacement, nous vidons le cache. Pour PrestaShop 1.7 / 8.x:
rm -rf var/cache/dev/*
rm -rf var/cache/prod/*Info
Après avoir appliqué l'override, la section des modules continue de fonctionner pleinement : il est possible d'installer, désinstaller et mettre à jour des modules depuis un fichier ZIP. Seule l'intégration avec la marketplace Addons dans le panneau d'administration est désactivée.
Alternative – blocage d'écriture dans des fichiers
Si nous ne voulons pas utiliser de surcharge, il est possible de définir les fichiers XML en lecture seule. PrestaShop ne pourra ainsi pas les écraser :chmod 444 config/xml/must_have_modules_list.xml
chmod 444 config/xml/modules_native_addons.xml
chmod 444 config/xml/default_country_modules_list.xml
chmod 444 config/xml/trusted_modules_list.xmlNote
La méthode avec chmod est plus simple, mais elle n'élimine pas les tentatives de connexion à l'API – PrestaShop continuera à les exécuter, ce qui peut ralentir le chargement de la page des modules. Le override de la classe Tools est une solution techniquement plus propre.
Qu'est-ce que nous ne perdons pas après avoir désactivé l'API des modules complémentaires ?
Il est bon de savoir que dans un environnement de production, la plupart de ces fonctionnalités ne sont de toute façon pas utilisées au quotidien :| Fonction | Après la désactivation de l'API |
| Frontend du magasin | Ça fonctionne sans changement |
| Commandes et panier | Ça fonctionne sans changement |
| Installation des modules depuis ZIP | Ça fonctionne sans changement |
| Mises à jour de modules | Ça fonctionne sans changement |
| Modules de marketplace dans l'administration | Indisponible |
| Modules incontournables„ | Indisponible |
| Suggestion de modules pour le pays | Indisponible |
Quand le bug peut-il revenir ?
Si nous appliquons uniquement la substitution de fichiers sans remplacement ou chmod, l'erreur peut réapparaître après :- rafraîchissement de la page du Gestionnaire de modules
- lancement de cron PrestaShop
- Mise à jour de PrestaShop
- nettoyage du cache
Résumé
L'erreur XML dans le back-office de PrestaShop est un problème de communication entre une ancienne version de la boutique et l'API Addons – ce n'est pas une défaillance du serveur, un problème de base de données ou la présence de logiciels malveillants. La boutique fonctionne normalement. La solution est rapide et ne nécessite pas de mise à jour de PrestaShop.Étapes recommandées :
- Vérifier le contenu des fichiers config/xml/
- Remplacement de fichiers par un XML minimal valide
- Ajouter le remplacement de classe Outils z $is_addons_up = faux
- Nettoyer le cache PrestaShop
Contactez nous
