Depannage FAQ

Le problème : vous avez besoin du module, mais pas de ses ressources sur chaque page

Il existe de nombreuses situations où vous souhaitez garder un module PrestaShop installé et actif mais l'empêcher de charger ses fichiers CSS ou JavaScript sur des pages spécifiques, voire sur toutes les pages. Peut-être avez-vous un module dont vous avez besoin des fonctionnalités mais dont le style entre en conflit avec votre thème. Peut-être qu'un module charge une bibliothèque JavaScript lourde que vous avez déjà incluse via votre thème. Peut-être souhaitez-vous remplacer les styles par défaut d'un module par votre propre CSS personnalisé sans que les styles d'origine interfèrent. Ou peut-être avez-vous identifié lors d'un audit de performance qu'un module charge des ressources sur des pages où il n'a aucune sortie visible, et vous souhaitez éliminer ce gaspillage.

Désinstaller le module n'est pas une option car vous avez besoin de ses fonctionnalités de base : ses hooks, ses tables de base de données, sa configuration, ses fonctionnalités de back office. Vous devez simplement supprimer chirurgicalement des fichiers CSS ou JavaScript spécifiques de la sortie du front office. PrestaShop fournit plusieurs mécanismes pour y parvenir, et cet article les couvre tous en détail, du plus simple au plus puissant.

Méthode 1 : Utiliser Theme.yml pour supprimer les ressources des modules

La manière la plus simple et la plus maintenable de supprimer le CSS ou le JavaScript d'un module dans PrestaShop 1.7 et versions ultérieures est via le fichier de configuration du thème, theme.yml. Ce fichier, situé à la racine du répertoire de votre thème, contrôle quelles ressources le thème charge et quelles ressources de modules il supprime.

Ouvrez votre fichier theme.yml et recherchez la section assets. Si elle n'existe pas, vous pouvez la créer. Dans la section assets, vous pouvez spécifier les fichiers CSS et JavaScript à supprimer par leur identifiant de ressource (asset ID). Chaque ressource enregistrée via registerStylesheet ou registerJavascript possède un identifiant, qui est généralement le nom du module suivi d'un suffixe descriptif.

Pour trouver les identifiants de ressources utilisés par un module, inspectez le code source de votre page et recherchez les balises link de feuilles de style et les éléments de ressources. PrestaShop ajoute un attribut id à ces éléments en mode debug, ou vous pouvez trouver les identifiants dans le code source du module là où il appelle registerStylesheet ou registerJavascript.

Dans votre fichier theme.yml, ajoutez une section sous assets, puis css, puis all. Ajoutez une entrée avec l'identifiant de la ressource et réglez-la sur false. Par exemple, si un module enregistre une feuille de style avec l'identifiant modulename-style, vous ajouteriez modulename-style avec la valeur false sous la section css all. Faites de même pour les fichiers JavaScript sous la section js all.

Après avoir modifié theme.yml, vous devez vider le cache PrestaShop depuis Paramètres avancés, Performance. Les modifications de theme.yml prennent effet après la reconstruction du cache. Cette approche persiste à travers les mises à jour des modules car la suppression est définie dans votre thème, pas dans le module lui-même. Cependant, elle supprime les ressources de toutes les pages. Si vous avez besoin des ressources sur certaines pages mais pas d'autres, vous aurez besoin d'une approche plus ciblée.

Méthode 2 : Media::unregisterStylesheet et Media::unregisterJavascript

PrestaShop 1.7 a introduit les méthodes de la classe Media unregisterStylesheet et unregisterJavascript, qui vous permettent de supprimer programmatiquement des ressources spécifiques enregistrées par d'autres modules. Ces méthodes sont puissantes car vous pouvez les appeler conditionnellement, supprimant des ressources uniquement sur des pages spécifiques tout en les conservant sur d'autres.

Pour utiliser cette approche, vous avez besoin d'un module personnalisé ou d'une modification d'un module existant. Dans la méthode hookActionFrontControllerSetMedia de votre module, appelez Media::unregisterStylesheet avec l'identifiant de la ressource du fichier CSS que vous souhaitez supprimer. De même, appelez Media::unregisterJavascript avec l'identifiant du fichier JavaScript. Vous pouvez encadrer ces appels d'une logique conditionnelle pour ne supprimer les ressources que sur des types de pages spécifiques.

Par exemple, si vous souhaitez supprimer les ressources d'un module de diaporama de toutes les pages sauf la page d'accueil, vous vérifieriez si le contrôleur actuel est IndexController. Si ce n'est pas la page d'accueil, vous appelez les méthodes de désenregistrement. Si c'est la page d'accueil, vous ne faites rien et laissez les ressources se charger normalement.

La considération clé avec cette approche est l'ordre d'exécution des hooks. La méthode hookActionFrontControllerSetMedia de votre module doit s'exécuter après le module dont vous voulez supprimer les ressources. PrestaShop exécute les callbacks de hooks dans l'ordre d'enregistrement des modules sur le hook, que vous pouvez contrôler via la page Apparence, Positions dans le back office. Déplacez votre module personnalisé en dessous du module cible sur le hook actionFrontControllerSetMedia pour vous assurer que vos appels de désenregistrement se produisent après que le module cible a enregistré ses ressources.

Si le module fautif utilise les anciennes méthodes addCSS et addJS au lieu de registerStylesheet et registerJavascript, les méthodes de désenregistrement peuvent ne pas fonctionner car les anciennes méthodes n'utilisent pas le même système de gestion des ressources. Dans ce cas, vous avez besoin d'une approche différente.

Méthode 3 : Module personnalisé pour bloquer des ressources spécifiques

Lorsque vous avez besoin d'un contrôle granulaire sur quelles ressources se chargent sur quelles pages, créer un module dédié de gestion des ressources est la solution la plus flexible. Ce module agit comme un point central où vous définissez les règles de blocage ou d'autorisation de ressources spécifiques de modules.

Créez un nouveau module avec une méthode hookActionFrontControllerSetMedia. À l'intérieur de cette méthode, définissez un tableau de règles de ressources. Chaque règle spécifie un nom de module, les identifiants de ressources à bloquer et les conditions dans lesquelles les bloquer. Les conditions peuvent être basées sur le nom du contrôleur, le type de page ou tout autre critère disponible dans le contexte PrestaShop.

Votre module parcourt les règles à chaque chargement de page, vérifie les conditions et appelle Media::unregisterStylesheet ou Media::unregisterJavascript pour chaque ressource qui devrait être bloquée sur la page actuelle. Cette approche centralisée est beaucoup plus facile à maintenir que de disperser la logique de suppression de ressources dans plusieurs modules ou fichiers de thème.

Vous pouvez améliorer ce module avec une page de configuration dans le back office qui vous permet de gérer les règles via l'interface d'administration PrestaShop au lieu de modifier le code. Un formulaire simple avec des champs pour le nom du module, l'identifiant de la ressource et un multi-select pour les types de pages où la ressource doit être bloquée vous donne un moyen convivial de gérer le chargement des ressources sans toucher au code après la configuration initiale.

Cette approche fonctionne avec le nouveau système registerStylesheet comme avec l'ancien système addCSS, bien que vous puissiez avoir besoin d'utiliser des techniques différentes pour chacun. Pour les ressources enregistrées avec le nouveau système, utilisez les méthodes Media::unregister. Pour les ressources ajoutées avec l'ancien système, vous pouvez manipuler directement les tableaux css_files et js_files du contrôleur dans la méthode hookActionFrontControllerSetMedia.

Méthode 4 : L'approche par décrochage de hook

Une approche plus agressive mais parfois nécessaire consiste à décrocher complètement un module des hooks où il enregistre ses ressources. Allez dans Apparence, puis Positions dans votre back office. Trouvez le module sur le hook displayHeader ou actionFrontControllerSetMedia. Cliquez sur le bouton supprimer ou décrocher pour retirer le module de ce hook entièrement.

Cela empêche le module de charger toute ressource, sur n'importe quelle page. Les autres hooks du module, comme displayProductAdditionalInfo ou displayFooter, continuent de fonctionner normalement. Cependant, la sortie du module en front office peut être cassée s'il dépend de son CSS pour le style ou de son JavaScript pour le comportement interactif.

Cette approche est plus utile lorsque vous prévoyez de remplacer entièrement le style du module par votre propre CSS personnalisé. Vous décrochez le module de displayHeader pour empêcher le chargement de son CSS, puis vous écrivez vos propres styles dans le fichier CSS personnalisé de votre thème ciblant les éléments HTML du module. Cela vous donne un contrôle complet sur l'apparence du module sans aucun conflit entre les styles d'origine et vos personnalisations.

Pour le JavaScript, le décrochage est plus risqué. Si le module s'appuie sur son JavaScript pour des fonctionnalités essentielles comme les appels AJAX, la validation de formulaires ou le chargement de contenu dynamique, supprimer le JavaScript cassera ces fonctionnalités. Ne décrochez le JavaScript que si vous êtes certain que la sortie du module en front office n'en dépend pas, ou si vous fournissez une implémentation de remplacement via votre thème.

Une mise en garde importante : si vous mettez à jour le module, le processus de mise à jour peut réenregistrer le module sur les hooks dont vous l'avez retiré. Après chaque mise à jour de module, vérifiez dans Apparence, Positions que votre décrochage est toujours en vigueur. Certains modules enregistrent explicitement leurs hooks pendant le processus de mise à jour, ce qui écrase votre décrochage manuel.

Méthode 5 : Remplacer les ressources des modules via votre thème

Le système de thèmes de PrestaShop vous permet de surcharger les fichiers de templates de modules en les plaçant dans le répertoire modules de votre thème. Bien que cela soit principalement utilisé pour les surcharges de templates, vous pouvez également l'utiliser pour contrôler indirectement le chargement des ressources.

Si un module charge ses ressources via ses fichiers de templates en utilisant des fonctions Smarty comme des balises de ressources directement dans les fichiers TPL plutôt que via des hooks PHP, vous pouvez surcharger ces templates dans votre thème et supprimer les références aux ressources. Copiez le fichier de template du module dans le répertoire modules de votre thème, en conservant la même structure de répertoires, et modifiez la copie pour supprimer les références CSS ou JavaScript indésirables.

Cette approche est spécifique au thème, ce qui signifie qu'elle n'affecte que le thème actuel. Si vous changez de thème, les surcharges ne sont pas transférées. Elle nécessite également de la maintenance : lorsque le module met à jour ses templates, vous devez mettre à jour vos surcharges pour correspondre aux changements structurels tout en conservant vos modifications de suppression de ressources.

Pour les modules qui chargent des ressources via des hooks PHP plutôt que des templates, les surcharges de templates de thème n'aident pas au blocage des ressources. Dans ce cas, utilisez l'une des autres méthodes décrites dans cet article.

PrestaShop 1.7 vs 8.x : différences d'approche

PrestaShop 8.x a affiné le système de gestion des ressources introduit dans la version 1.7, mais les approches fondamentales restent les mêmes. Les principales différences résident dans l'implémentation interne et quelques fonctionnalités supplémentaires.

Dans PrestaShop 1.7, le système de gestion des ressources utilise registerStylesheet et registerJavascript avec un système de priorité. Les méthodes Media::unregisterStylesheet et Media::unregisterJavascript fonctionnent de manière fiable pour les ressources enregistrées via ce système. Cependant, les modules qui utilisent encore les anciennes méthodes addCSS et addJS (qui sont dépréciées mais toujours fonctionnelles) ne passent pas par le nouveau système de gestion des ressources, ce qui les rend plus difficiles à supprimer proprement.

PrestaShop 8.x a amélioré la rétrocompatibilité de sorte que même les ressources ajoutées via les anciennes méthodes sont traitées par le nouveau pipeline de ressources. Cela signifie que les méthodes Media::unregister fonctionnent de manière plus cohérente sur tous les modules, quelle que soit la méthode d'enregistrement utilisée. Si vous utilisez PrestaShop 8.x, l'approche de désenregistrement est la méthode la plus fiable pour tous les modules.

PrestaShop 8.x a également introduit un meilleur cache-busting pour les ressources, ce qui signifie que lorsque vous supprimez ou modifiez des ressources, les changements prennent effet immédiatement après avoir vidé le cache, sans que les clients voient des versions mises en cache obsolètes. Dans PrestaShop 1.7, vous deviez parfois vider à la fois le cache PrestaShop et le cache du navigateur, ou attendre que le système Combiner, Compresser, Mettre en Cache (CCC) régénère les fichiers combinés.

Les deux versions prennent en charge l'approche theme.yml pour la suppression de ressources, et la syntaxe est identique. Si vous écrivez un module personnalisé pour la gestion des ressources, le même code fonctionne sur les versions 1.7 et 8.x avec des différences minimales.

Mesurer les gains de performance après la désactivation des ressources

Après avoir désactivé les ressources des modules, vous devriez mesurer l'amélioration des performances pour confirmer que vos modifications ont eu l'effet attendu. Utilisez une combinaison d'outils pour une mesure complète.

Commencez avec l'onglet Réseau des DevTools de Chrome. Comparez le nombre total de requêtes et la taille totale transférée avant et après vos modifications. Filtrez par CSS et JS pour voir la réduction spécifique du nombre et de la taille des fichiers de feuilles de style et JavaScript. Une optimisation significative devrait montrer une réduction claire à la fois du nombre de requêtes et de la taille totale.

Lancez un audit de performance Lighthouse avant et après. Concentrez-vous sur les métriques les plus affectées par le chargement de CSS et JavaScript : le First Contentful Paint est affecté par le CSS bloquant le rendu, le Largest Contentful Paint est affecté par le chargement global des ressources, et le Total Blocking Time est affecté par l'analyse et l'exécution du JavaScript. Enregistrez ces métriques d'au moins trois exécutions et comparez les moyennes.

Utilisez l'onglet Couverture (Coverage) dans les DevTools de Chrome pour mesurer l'utilisation du CSS et du JavaScript. Ouvrez l'onglet Couverture depuis le menu à trois points sous Plus d'outils, puis rechargez la page. L'onglet Couverture vous montre quelle proportion de chaque fichier CSS et JavaScript est réellement utilisée sur la page actuelle. Les fichiers avec un pourcentage élevé de code inutilisé (affiché en rouge) sont des candidats à la suppression ou au chargement conditionnel. Après avoir désactivé les ressources des modules, les fichiers restants devraient montrer des pourcentages d'utilisation plus élevés, indiquant que vous avez réussi à éliminer le gaspillage.

Considérez également les métriques du monde réel issues de votre plateforme d'analyse. Si vous utilisez Google Analytics ou un outil similaire, comparez les temps de chargement des pages pendant une semaine avant et après votre optimisation. Les données réelles de vrais visiteurs avec différents appareils et conditions réseau vous donnent l'image la plus précise de l'amélioration des performances.

Risques et problèmes de compatibilité

La désactivation des ressources de modules comporte des risques que vous devez comprendre et gérer. Le risque le plus courant est la casse visuelle. Lorsque vous supprimez le CSS d'un module, ses éléments HTML perdent leur style et peuvent s'afficher incorrectement. Cela peut aller de problèmes cosmétiques mineurs comme des couleurs ou des espacements incorrects à des problèmes de mise en page majeurs comme des éléments qui se chevauchent ou du contenu invisible.

La suppression du JavaScript comporte un risque plus élevé. Les modules modernes dépendent souvent de leur JavaScript pour des fonctionnalités essentielles. Supprimer le JavaScript peut provoquer l'arrêt complet de fonctionnalités : des boutons qui ne répondent pas aux clics, des formulaires qui ne se soumettent pas, des popups qui ne s'ouvrent pas, du contenu AJAX qui ne se charge pas. Testez toujours chaque fonctionnalité d'un module après avoir supprimé son JavaScript.

Il y a également un risque de compatibilité avec les mises à jour de modules. Lorsqu'un module est mis à jour, le développeur peut ajouter de nouveaux fichiers CSS ou JavaScript avec des identifiants de ressources différents. Vos règles de suppression, que ce soit dans theme.yml ou un module personnalisé, peuvent ne pas intercepter les nouvelles ressources car elles ciblent les anciens identifiants. Après chaque mise à jour de module, vérifiez que votre blocage de ressources fonctionne toujours correctement et mettez à jour vos règles si nécessaire.

Certains modules effectuent une détection de fonctionnalités dans leur JavaScript et se comportent différemment lorsque leur CSS n'est pas chargé. Un module peut vérifier l'existence de classes CSS spécifiques ou de styles calculés avant d'initialiser ses fonctionnalités JavaScript. Supprimer le CSS dans ce cas ne change pas seulement l'apparence mais casse également le comportement JavaScript qui dépend de ces états définis par le CSS.

Enfin, soyez conscient des dépendances entre modules. Le Module A peut charger une bibliothèque JavaScript comme un plugin de lightbox que le Module B utilise également mais ne charge pas lui-même parce qu'il suppose que le Module A la fournit. Supprimer les fichiers JavaScript du Module A casserait les deux modules dans ce scénario. Vérifiez les dépendances partagées avant de supprimer des ressources.

Un flux de travail pratique pour la suppression sécurisée des ressources

Suivez ce flux de travail pour désactiver en toute sécurité les ressources de modules sans casser votre boutique. Premièrement, documentez votre état actuel. Prenez des captures d'écran de chaque type de page où le module affiche du contenu. Enregistrez les scores Lighthouse et les statistiques de l'onglet Réseau. Cela vous donne une base de comparaison et une référence pour l'apparence et le fonctionnement attendus du module.

Deuxièmement, identifiez les ressources spécifiques que vous souhaitez supprimer. Utilisez les DevTools pour trouver les noms de fichiers exacts et les identifiants de ressources. Déterminez quelles pages ont besoin des ressources et lesquelles n'en ont pas.

Troisièmement, implémentez la suppression en utilisant la méthode la plus appropriée de cet article. Pour une suppression globale simple, utilisez theme.yml. Pour une suppression conditionnelle basée sur le type de page, créez un module personnalisé avec des appels Media::unregister. Pour un remplacement complet des ressources, décrochez le module et fournissez vos propres styles.

Quatrièmement, testez minutieusement. Vérifiez chaque type de page où le module devrait afficher du contenu. Vérifiez que l'apparence visuelle du module est correcte et que toutes les fonctionnalités interactives fonctionnent. Vérifiez les pages où vous avez supprimé les ressources pour confirmer qu'elles ne se chargent plus. Testez sur plusieurs navigateurs et appareils.

Cinquièmement, mesurez l'amélioration des performances. Lancez des audits Lighthouse et comparez avec votre référence. Vérifiez l'onglet Réseau pour la réduction du nombre de requêtes et des tailles. Si l'amélioration est significative, votre optimisation a réussi. Si l'amélioration est minimale, les ressources que vous avez supprimées n'étaient peut-être pas le principal goulot d'étranglement de performance, et vous devriez investiguer d'autres opportunités d'optimisation.

Sixièmement, documentez vos modifications. Enregistrez quelles ressources vous avez supprimées, quelle méthode vous avez utilisée et quelles pages sont affectées. Cette documentation est essentielle pour le dépannage de problèmes futurs, surtout après les mises à jour de modules, et pour le transfert de connaissances si quelqu'un d'autre maintient la boutique.

En suivant cette approche systématique, vous pouvez réduire en toute sécurité le poids de page de votre boutique et améliorer les temps de chargement sans sacrifier les fonctionnalités de module dont votre boutique dépend. La clé est toujours le test et la mesure : ne supposez jamais que la suppression d'une ressource est sûre, et vérifiez toujours les résultats avec des données concrètes.

Lire la réponse complète

Comprendre le memory_limit de PHP

La directive memory_limit dans PHP contrôle la quantité de RAM qu'un seul processus PHP peut consommer avant que le moteur ne le termine avec une erreur fatale. Lorsque vous voyez le message "Allowed memory size of X bytes exhausted" dans PrestaShop, cela signifie qu'une requête PHP spécifique a tenté d'utiliser plus de mémoire que la limite configurée ne l'autorise.

Chaque chargement de page dans PrestaShop exécute du code PHP qui charge le framework, se connecte à la base de données, traite les données, effectue le rendu des templates et envoie le HTML au navigateur. Chacune de ces étapes consomme de la mémoire. Le memory_limit agit comme un filet de sécurité : il empêche un processus incontrôlé de consommer toute la RAM disponible du serveur, ce qui ferait planter les autres processus et pourrait potentiellement faire tomber l'ensemble du serveur.

Le memory_limit par défaut dans PHP est généralement de 128M (128 mégaoctets). PrestaShop recommande officiellement au moins 256M, et de nombreuses boutiques nécessitent 512M ou plus selon la taille du catalogue, les modules installés et le trafic. Comprendre ce qui génère la consommation de mémoire vous aide à déterminer la bonne valeur pour votre boutique plutôt que d'augmenter aveuglément la limite.

Comment vérifier votre limite de mémoire actuelle

Il existe plusieurs façons de vérifier quelle limite de mémoire votre installation PrestaShop utilise actuellement.

Depuis le Back Office PrestaShop

Naviguez vers Paramètres avancés > Informations. Cette page affiche la configuration PHP de votre serveur, y compris la valeur actuelle du memory_limit. PrestaShop affichera également des avertissements si la valeur est inférieure au minimum recommandé.

En utilisant phpinfo()

Créez un fichier temporaire appelé info.php dans le répertoire racine de votre PrestaShop avec ce contenu :

<?php phpinfo(); ?>

Accédez-y via votre navigateur à l'adresse votredomaine.com/info.php. Recherchez « memory_limit » dans la page pour voir à la fois la Valeur locale (celle qui est réellement active) et la Valeur maître (celle qui est définie dans php.ini). La valeur locale peut différer de la valeur maître si un .htaccess, un .user.ini ou l'application elle-même la surcharge.

Important : Supprimez ce fichier immédiatement après vérification. Une page phpinfo() expose des informations détaillées sur la configuration du serveur que les attaquants peuvent exploiter.

Via la ligne de commande

Si vous avez un accès SSH, exécutez :

php -i | grep memory_limit

Notez que la configuration PHP en ligne de commande peut différer de la configuration du serveur web. Pour vérifier la valeur côté web, utilisez la méthode phpinfo() ou le back office PrestaShop.

Causes courantes des erreurs de limite de mémoire

Imports de produits volumineux

L'importation de produits via CSV est l'une des opérations les plus gourmandes en mémoire dans PrestaShop. Chaque ligne du fichier d'importation est chargée en mémoire, traitée, validée et insérée dans la base de données. Un fichier CSV contenant 10 000 produits, chacun avec de multiples déclinaisons, images et descriptions, peut facilement nécessiter 512 Mo ou plus de mémoire.

L'outil d'importation de PrestaShop traite les produits par lots, mais la taille des lots et la quantité de données par produit déterminent l'empreinte mémoire totale. Les champs de texte volumineux (descriptions avec HTML), les nombreuses colonnes et les fichiers encodés en UTF-8 avec des caractères spéciaux augmentent tous l'utilisation de mémoire par ligne.

Pour réduire la consommation de mémoire lors des importations :

Découpez les fichiers CSV volumineux en morceaux plus petits (1 000 à 2 000 lignes chacun)
Importez d'abord les produits sans images, puis importez les images séparément
Désactivez les modules non essentiels pendant l'importation (statistiques, indexation de recherche)
Utilisez l'importation en ligne de commande si disponible, ce qui évite les limites de timeout du serveur web

Produits avec de nombreuses déclinaisons

Les produits avec de nombreux attributs (taille, couleur, matière) génèrent des déclinaisons de manière exponentielle. Un produit avec 5 tailles, 10 couleurs et 3 matières crée 150 déclinaisons. Chaque déclinaison est un enregistrement de base de données séparé avec son propre prix, référence, stock et associations d'images. Lorsque PrestaShop charge une page produit pour l'édition dans le back office, il charge toutes les déclinaisons en mémoire en une seule fois.

Les produits avec plus de 500 déclinaisons sont un point de friction connu. Au-delà de 1 000 déclinaisons, vous atteindrez presque certainement les limites de mémoire avec la configuration par défaut. Les solutions incluent :

Augmenter le memory_limit à 512M ou 1G pour le back office
Restructurer les produits pour réduire le nombre de déclinaisons (produits séparés au lieu de méga-déclinaisons)
Utiliser des modules qui gèrent les déclinaisons plus efficacement grâce à la pagination

Modules surchargés ou mal codés

Les modules tiers sont une source fréquente de problèmes de mémoire. Les problèmes courants incluent :

Chargement de tables de base de données entières dans des tableaux PHP : Un module qui exécute SELECT * FROM ps_orders sans clause LIMIT charge chaque commande jamais passée en mémoire. Pour une boutique avec 100 000 commandes, cela peut consommer des centaines de mégaoctets.
Fuites de mémoire dans les boucles : Des modules qui traitent des éléments dans une boucle mais accumulent des objets sans les libérer. Le ramasse-miettes de PHP gère les cas simples, mais les références circulaires et les références stockées peuvent empêcher le nettoyage.
Journalisation excessive : La journalisation de débogage qui écrit de grands tableaux ou objets dans les fichiers de log, en utilisant var_export() ou print_r() sur des objets PrestaShop complexes, peut consommer des quantités énormes de mémoire.
Traitement d'images non optimisé : Les modules qui redimensionnent ou ajoutent des filigranes aux images en utilisant GD ou ImageMagick chargent l'intégralité de l'image non compressée en mémoire. Une image de 5000x5000 pixels en couleur 24 bits nécessite environ 75 Mo de RAM juste pour les données de pixels.

Pour identifier quel module cause des problèmes de mémoire, vérifiez attentivement le message d'erreur. Il inclut généralement un chemin de fichier qui pointe vers le module responsable. Vous pouvez également activer le mode débogage de PrestaShop pour obtenir des traces de pile plus détaillées.

Catalogues volumineux et requêtes complexes

Les boutiques avec des dizaines de milliers de produits, de nombreuses catégories et des structures d'attributs complexes exercent plus de pression sur la mémoire pendant le fonctionnement normal. Les pages de catégories avec navigation à facettes (recherche par filtres) sont particulièrement exigeantes car le moteur de filtrage doit calculer les valeurs d'attributs disponibles à travers des milliers de produits.

Les pages de listing des produits, commandes et clients du back office chargent toutes des données en mémoire pour l'affichage. Avec de très grands jeux de données, même la vue de liste basique peut atteindre les limites de mémoire, surtout quand des modules ajoutent des colonnes ou des calculs supplémentaires à ces listes.

Compilation des templates Smarty

PrestaShop utilise le moteur de templates Smarty, qui compile les templates en fichiers PHP pour un rendu plus rapide. Le processus de compilation lui-même consomme de la mémoire, et les templates complexes avec de nombreuses inclusions, boucles et blocs conditionnels nécessitent plus de mémoire à compiler. Après la première compilation, les versions en cache sont utilisées, ce problème se pose donc principalement lorsque le cache est vidé ou pendant le développement.

Comment augmenter la limite de mémoire

Méthode 1 : php.ini

La méthode la plus fiable consiste à modifier directement le fichier de configuration PHP. L'emplacement dépend de votre configuration :

Debian/Ubuntu : /etc/php/8.x/fpm/php.ini (PHP-FPM) ou /etc/php/8.x/apache2/php.ini (mod_php)
CentOS/RHEL : /etc/php.ini ou /etc/php.d/
cPanel : Éditeur INI MultiPHP dans WHM ou cPanel

Trouvez la ligne memory_limit et modifiez-la :

memory_limit = 512M

Après la sauvegarde, redémarrez PHP-FPM ou Apache :

# PHP-FPM
sudo systemctl restart php8.2-fpm

# Apache avec mod_php
sudo systemctl restart apache2

Méthode 2 : .htaccess (Apache avec mod_php uniquement)

Ajoutez cette ligne au fichier .htaccess dans le répertoire racine de votre PrestaShop :

php_value memory_limit 512M

Cette méthode ne fonctionne qu'avec Apache utilisant mod_php. Si vous utilisez PHP-FPM (ce qui est plus courant sur les configurations modernes), cette directive est silencieusement ignorée ou peut provoquer une erreur 500. Pour vérifier quel gestionnaire PHP vous utilisez, regardez la ligne Server API dans la sortie de votre phpinfo().

Méthode 3 : .user.ini (PHP-FPM)

Créez ou éditez un fichier appelé .user.ini dans le répertoire racine de votre PrestaShop :

memory_limit = 512M

PHP-FPM lit les fichiers .user.ini depuis la racine du document. Notez que les modifications prennent effet après la période user_ini.cache_ttl (300 secondes / 5 minutes par défaut), vous devrez donc peut-être attendre ou redémarrer PHP-FPM pour que le changement prenne effet immédiatement.

Méthode 4 : Dans le code de PrestaShop

PrestaShop définit sa propre limite de mémoire dans le fichier config/defines.inc.php. Cherchez une ligne comme :

@ini_set('memory_limit', '256M');

Vous pouvez augmenter cette valeur directement dans le code. Cependant, cette approche a une limitation : la fonction ini_set() ne peut augmenter la limite de mémoire que jusqu'à la valeur définie dans php.ini. Si php.ini définit memory_limit = 128M et que votre code essaie de le mettre à 512M, la limite réelle restera 128M (sauf si la valeur maître autorise les surcharges, ce qui dépend de la classification PHP_INI_ALL vs PHP_INI_SYSTEM).

Méthode 5 : Configuration par pool (PHP-FPM)

Si vous gérez votre propre serveur, vous pouvez définir les limites de mémoire par pool PHP-FPM. Éditez le fichier de configuration du pool (par ex., /etc/php/8.2/fpm/pool.d/www.conf) et ajoutez :

php_admin_value[memory_limit] = 512M

Utiliser php_admin_value rend ce paramètre immuable — il ne peut pas être surchargé par .user.ini ou ini_set(). C'est utile pour imposer des limites dans les environnements multi-locataires.

Mémoire par processus vs mémoire partagée

Il est important de comprendre que memory_limit s'applique à chaque processus PHP individuel, pas à PHP dans son ensemble. Si vous définissez memory_limit = 512M et que votre serveur exécute 20 processus PHP simultanés, la consommation de mémoire maximale théorique par PHP est de 10 Go (20 x 512 Mo).

C'est pourquoi augmenter aveuglément la limite de mémoire peut causer des problèmes. Sur un serveur avec 4 Go de RAM, définir memory_limit = 1G avec 10 workers PHP-FPM signifie que PHP seul pourrait essayer d'utiliser 10 Go, provoquant un swap intensif du système ou déclenchant le OOM killer de Linux, qui termine de force les processus pour libérer de la mémoire.

L'approche correcte consiste à équilibrer la limite de mémoire avec le nombre de workers PHP :

RAM disponible pour PHP = RAM totale - overhead OS - mémoire MySQL - mémoire serveur web - autres services
Workers PHP max = RAM disponible pour PHP / memory_limit

Par exemple, sur un VPS de 4 Go : 4 Go total - 0,5 Go OS - 1 Go MySQL - 0,25 Go Nginx = 2,25 Go pour PHP. Avec memory_limit = 256M, vous pouvez exécuter en toute sécurité 8-9 workers PHP-FPM. Avec memory_limit = 512M, vous ne pouvez exécuter que 4 workers, ce qui signifie que moins de requêtes simultanées peuvent être servies.

Configurez le pool PHP-FPM en conséquence :

pm = dynamic
pm.max_children = 8
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5

Diagnostiquer les fuites de mémoire et la consommation excessive

Si augmenter la limite de mémoire ne fait que retarder l'erreur plutôt que la corriger, vous avez probablement une fuite de mémoire ou un processus inefficace. Voici comment diagnostiquer la cause fondamentale.

Activer le mode débogage PrestaShop

Éditez config/defines.inc.php et définissez :

define('_PS_MODE_DEV_', true);

Cela active le rapport d'erreurs détaillé, y compris le fichier exact et le numéro de ligne où la limite de mémoire a été dépassée. La trace de pile montre la chaîne d'appels de fonctions qui a mené à l'erreur, vous aidant à identifier le module ou la fonction du noyau responsable.

Surveiller l'utilisation de la mémoire dans le code

Vous pouvez ajouter un suivi de la mémoire à des sections de code spécifiques pour identifier précisément où les pics de mémoire se produisent :

error_log('Mémoire avant opération : ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
// ... opération ...
error_log('Mémoire après opération : ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
error_log('Pic d\'utilisation mémoire : ' . memory_get_peak_usage(true) / 1024 / 1024 . ' MB');

La fonction memory_get_usage(true) retourne la quantité réelle de mémoire allouée par le système d'exploitation à PHP, tandis que memory_get_peak_usage(true) retourne la quantité maximale allouée à n'importe quel moment pendant la requête.

Utiliser le profilage Xdebug

Le profileur de Xdebug génère des rapports détaillés des appels de fonctions, du temps d'exécution et de la consommation de mémoire. Activez-le temporairement dans votre configuration PHP :

xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug

Ouvrez les fichiers cachegrind générés dans un outil comme KCacheGrind ou Webgrind pour visualiser quelles fonctions consomment le plus de mémoire. C'est l'approche diagnostique la plus approfondie mais elle ne devrait être utilisée que sur les serveurs de développement en raison de l'impact significatif sur les performances.

Vérifier les requêtes lentes et MySQL

Parfois, ce qui semble être un problème de mémoire PHP est en réalité un problème MySQL. Une requête lente qui retourne des millions de lignes obligera PHP à allouer de la mémoire pour l'ensemble du jeu de résultats. Vérifiez le journal des requêtes lentes de MySQL :

sudo tail -100 /var/log/mysql/slow-query.log

Si vous voyez des requêtes avec de grands jeux de résultats, ajoutez des clauses LIMIT appropriées ou implémentez la pagination dans le module responsable.

Mémoire OPcache

OPcache est une extension PHP qui met en cache le bytecode PHP compilé dans la mémoire partagée, éliminant le besoin d'analyser et de compiler les fichiers PHP à chaque requête. OPcache a sa propre allocation mémoire, séparée du memory_limit.

La mémoire OPcache par défaut (opcache.memory_consumption) est de 128 Mo. PrestaShop avec plusieurs modules installés peut facilement dépasser cette limite. Lorsque OPcache manque de mémoire, il commence à évincer les entrées en cache et à recompiler les fichiers à chaque requête, provoquant une dégradation significative des performances.

Vérifiez l'état d'OPcache depuis la ligne de commande :

php -r "print_r(opcache_get_status());"

Ou consultez la section opcache dans la sortie de votre phpinfo(). Valeurs clés à surveiller :

opcache.memory_consumption : Mémoire totale allouée pour OPcache (augmentez à 256M pour PrestaShop)
opcache.max_accelerated_files : Nombre maximum de fichiers qu'OPcache peut mettre en cache (augmentez à 20000 pour PrestaShop)
Mémoire utilisée vs mémoire libre : Si la mémoire libre est proche de zéro, augmentez memory_consumption
Taux de succès du cache : Devrait être au-dessus de 99 %. En dessous de 95 % indique une pression mémoire ou une invalidation fréquente du cache

Configuration OPcache recommandée pour PrestaShop :

opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 0
opcache.interned_strings_buffer = 16

Notez que la mémoire OPcache est partagée entre tous les processus PHP, contrairement au memory_limit qui est par processus. Augmenter la mémoire OPcache ne se multiplie pas par le nombre de workers.

Configuration mémoire MySQL

MySQL a sa propre configuration mémoire qui affecte indirectement les performances de PrestaShop et peut contribuer à la pression mémoire globale du serveur. Les paramètres mémoire clés de MySQL incluent :

innodb_buffer_pool_size : Le principal tampon mémoire pour les tables InnoDB. Réglez-le à 50-70 % de la RAM disponible sur un serveur de base de données dédié, ou 25-50 % sur un serveur partagé exécutant à la fois PHP et MySQL. C'est le paramètre de performance MySQL le plus important.
sort_buffer_size et join_buffer_size : Tampons par connexion pour le tri et les jointures. Gardez-les aux valeurs par défaut sauf si vous avez des requêtes lentes spécifiques qui bénéficient de tampons plus grands. Les régler trop haut gaspille de la mémoire car ils sont alloués par connexion.
query_cache_size : Déprécié dans MySQL 8.0 et supprimé entièrement. Si vous êtes encore sur MySQL 5.7, un petit cache de requêtes (64M) peut aider, mais les grands caches de requêtes provoquent de la contention et réduisent les performances.

Si MySQL consomme trop de mémoire, il en reste moins pour PHP, vous forçant potentiellement à réduire les workers PHP-FPM ou la limite de mémoire. Utilisez mysqladmin status ou SHOW GLOBAL STATUS pour surveiller la consommation mémoire de MySQL.

Quand mettre à niveau votre hébergement

Parfois, augmenter la limite de mémoire et optimiser votre code ne suffit pas. Voici les signes indiquant que vous avez besoin d'un serveur plus puissant :

Vous fonctionnez constamment à la limite de mémoire maximale : Si vos processus utilisent régulièrement plus de 90 % de la mémoire allouée, même après optimisation, vous avez besoin de plus de RAM.
Le serveur swappe fréquemment : Vérifiez avec free -h ou vmstat 1. Si l'utilisation du swap est constamment élevée, vous n'avez pas assez de RAM physique.
Réduire les workers PHP nuit aux performances : Si vous avez dû réduire les workers PHP-FPM à 3-4 pour accommoder la limite de mémoire, votre site ne peut pas gérer efficacement les visiteurs simultanés.
Votre catalogue ne cesse de croître : Une boutique qui fonctionnait bien avec 1 000 produits peut avoir des difficultés avec 10 000. Les besoins en mémoire évoluent avec la taille du catalogue, notamment pour l'indexation de la recherche, les listings de catégories et les opérations du back office.
Vous avez besoin d'un memory_limit supérieur à 1G : Si un seul processus PHP nécessite plus de 1 Go de mémoire pour des opérations normales (pas des importations), quelque chose est fondamentalement défaillant soit dans votre code, soit dans la capacité de votre hébergement. Investiguez la cause fondamentale avant d'augmenter simplement la limite davantage.

Lors de la mise à niveau, privilégiez plus de RAM plutôt que plus de cœurs CPU pour PrestaShop. Un serveur avec 8 Go de RAM et 2 cœurs servira PrestaShop mieux qu'un serveur avec 4 Go de RAM et 4 cœurs. Envisagez également de séparer MySQL sur son propre serveur ou d'utiliser un service de base de données géré, ce qui libère entièrement la RAM du serveur d'application pour PHP.

Référence rapide : Paramètres recommandés par taille de boutique

Les recommandations suivantes servent de points de départ. Surveillez votre utilisation réelle et ajustez en conséquence.

Petite boutique (moins de 1 000 produits, peu de modules) : memory_limit = 256M, 2 Go de RAM, 4-6 workers PHP
Boutique moyenne (1 000 à 10 000 produits, 20+ modules) : memory_limit = 512M, 4 Go de RAM, 6-8 workers PHP
Grande boutique (10 000+ produits, nombreuses déclinaisons) : memory_limit = 512M-1G, 8 Go+ de RAM, 8-16 workers PHP, serveur de base de données séparé
Pendant les importations : Augmentez temporairement à 1G ou 2G, puis restaurez la valeur normale

Rappelez-vous que la limite de mémoire est un plafond de sécurité, pas un objectif. Une boutique PrestaShop bien optimisée devrait rarement utiliser plus de 128-256 Mo par requête pour les chargements de page normaux. Si les opérations normales nécessitent systématiquement 512 Mo ou plus, investiguez et corrigez la cause sous-jacente plutôt que de continuer à augmenter la limite.

Lire la réponse complète

Comprendre max_input_vars dans PrestaShop

Si vous avez déjà essayé de sauvegarder un produit avec des dizaines ou des centaines de déclinaisons dans PrestaShop et obtenu un échec silencieux, une sauvegarde partielle ou une erreur cryptique, le coupable est presque certainement la directive PHP max_input_vars. Ce paramètre contrôle combien de champs de formulaire individuels PHP acceptera dans une seule requête POST. Lorsque PrestaShop soumet un formulaire produit qui dépasse cette limite, chaque champ au-delà du seuil est silencieusement écarté, conduisant à des sauvegardes incomplètes, des déclinaisons manquantes ou des données qui disparaissent tout simplement sans aucun message d'erreur visible.

Par défaut, la plupart des installations PHP sont livrées avec max_input_vars défini à 1000. Pour un simple blog ou un site vitrine, c'est largement suffisant. Pour PrestaShop en revanche, les pages d'édition de produits peuvent générer des milliers de champs de formulaire, surtout lorsque les déclinaisons, les champs multilingues et les caractéristiques personnalisées sont impliqués. Comprendre cette directive, savoir comment calculer la valeur dont votre boutique a réellement besoin et appliquer correctement le correctif vous fera gagner des heures de débogage.

Pourquoi PrestaShop nécessite des valeurs élevées de max_input_vars

Le formulaire d'édition de produit de PrestaShop est l'un des formulaires les plus complexes de toute plateforme e-commerce. Chaque déclinaison d'un produit génère de multiples champs de saisie : un pour l'impact sur le prix, un pour l'impact sur le poids, un pour la quantité, un pour la référence, un pour le code EAN-13, un pour le code UPC, un pour le MPN, un pour la quantité minimale, un pour le seuil de stock bas, un pour la date de disponibilité, et plusieurs autres selon votre configuration. Une seule déclinaison peut facilement produire 15 à 25 champs de formulaire.

Maintenant multipliez cela par le nombre de déclinaisons. Un t-shirt disponible en 5 tailles et 10 couleurs a 50 déclinaisons. À 20 champs par déclinaison, cela représente déjà 1 000 champs rien que pour l'onglet des déclinaisons. Ajoutez les champs de base du produit, les champs SEO pour chaque langue, les valeurs de caractéristiques, les prix spécifiques et les autres onglets, et vous pouvez facilement atteindre 1 500 à 2 000 champs pour un produit modérément complexe.

Pour les boutiques vendant des produits avec des ensembles d'attributs étendus, comme l'électronique avec différentes capacités de stockage, couleurs, options de RAM et variantes régionales, un seul produit peut avoir 200 déclinaisons ou plus, générant plus de 4 000 champs de formulaire. La limite par défaut de 1 000 n'est même pas proche d'être suffisante.

Symptômes d'un max_input_vars trop bas

L'aspect le plus frustrant lorsqu'on atteint la limite max_input_vars est que PHP ne génère pas d'erreur. Il tronque silencieusement les données d'entrée. Cela signifie que vous verrez une variété de symptômes déroutants sans aucune indication claire de ce qui a mal tourné.

Le symptôme le plus courant est que les déclinaisons disparaissent après la sauvegarde. Vous créez 80 déclinaisons, cliquez sur sauvegarder, et lorsque la page se recharge, seules 40 sont présentes. Le formulaire a soumis les 80, mais PHP n'a traité que la première partie des données POST avant d'atteindre la limite, de sorte que les déclinaisons restantes n'ont jamais été reçues par le serveur.

Un autre symptôme courant est que les données du produit se sauvegardent partiellement. L'onglet des informations de base se sauvegarde correctement, mais les données de tarification, SEO ou déclinaisons sont perdues. Cela se produit car les champs de formulaire sont soumis dans un ordre spécifique, et tous les champs situés après le point de coupure sont écartés.

Vous pouvez également constater que la page produit se recharge simplement sans sauvegarder du tout, ou PrestaShop affichant une erreur générique telle que « Une erreur s'est produite lors de la mise à jour du produit. » Dans PrestaShop 1.7 et 8.x, la page produit basée sur Symfony peut afficher des erreurs de validation pour des champs obligatoires qui étaient en fait remplis mais tronqués par PHP.

Un symptôme moins évident affecte les boutiques multilingues. Si votre boutique supporte 5 langues, chaque champ de texte est multiplié par 5. Un produit qui se sauvegarde correctement sur une boutique monolingue échoue sur une boutique multilingue car les champs de langue supplémentaires poussent le total au-delà de la limite.

Comment vérifier votre valeur actuelle de max_input_vars

Avant de faire des modifications, vérifiez votre paramètre actuel. Créez un fichier PHP dans le répertoire racine de votre PrestaShop (n'oubliez pas de le supprimer ensuite pour des raisons de sécurité) :

<?php phpinfo(); ?>

Accédez à ce fichier via votre navigateur et recherchez max_input_vars. Vous verrez à la fois la Valeur locale (celle qui est actuellement active) et la Valeur maître (celle par défaut depuis php.ini). Faites attention à la Valeur locale, car elle peut différer de la Valeur maître si un .htaccess ou une configuration par répertoire la surcharge.

Alternativement, vous pouvez vérifier depuis le back office PrestaShop. Naviguez vers Paramètres avancés, puis Informations. La section de configuration PHP affiche les paramètres PHP clés, y compris max_input_vars. PrestaShop 1.7.7 et les versions ultérieures affichent également un avertissement sur cette page si la valeur est considérée comme trop basse.

Calculer la valeur de max_input_vars dont vous avez besoin

Plutôt que de définir aveuglément un nombre élevé, vous pouvez estimer la valeur dont votre boutique a besoin. Utilisez cette formule comme base :

Valeur requise = (nombre de déclinaisons x champs par déclinaison) + champs de base du produit + (champs de texte x nombre de langues) + marge de sécurité

Pour un exemple pratique, considérons une boutique avec 3 langues et un produit qui a 100 déclinaisons. Le calcul serait le suivant : 100 déclinaisons multipliées par 20 champs chacune donnent 2 000. Les champs de base du produit à travers tous les onglets contribuent à environ 200. Les champs de texte (nom, description, titre meta, description meta, réécriture de lien et autres) multipliés par 3 langues ajoutent 150 supplémentaires. En ajoutant une marge de sécurité de 20 %, le total atteint environ 2 820.

Pour la plupart des boutiques PrestaShop, définir max_input_vars à 10000 offre une marge confortable. Les boutiques avec des produits ayant plus de 300 déclinaisons ou fonctionnant en 5 langues ou plus devraient envisager 20000 voire 50000. Le surcoût mémoire d'une valeur plus élevée est négligeable sur les serveurs modernes.

Comment augmenter max_input_vars

Méthode 1 : php.ini (recommandée)

Si vous avez accès à la configuration PHP de votre serveur, modifier php.ini est l'approche la plus propre. Localisez votre fichier php.ini (la sortie de phpinfo() vous indique exactement quel fichier est chargé) et trouvez ou ajoutez la ligne suivante :

max_input_vars = 10000

Après avoir sauvegardé le fichier, redémarrez votre serveur web ou le service PHP-FPM pour que le changement prenne effet. Avec Apache et mod_php, redémarrez Apache. Avec Nginx et PHP-FPM, redémarrez le service php-fpm. La commande exacte dépend de votre système d'exploitation et de votre version de PHP.

Méthode 2 : .htaccess (Apache avec mod_php ou mod_fcgid)

Si vous n'avez pas accès à php.ini, comme sur un hébergement mutualisé, vous pouvez essayer d'ajouter la directive au fichier .htaccess dans le répertoire racine de votre PrestaShop :

php_value max_input_vars 10000

Cette méthode ne fonctionne que si PHP s'exécute comme module Apache (mod_php). Si votre hébergeur utilise PHP-FPM ou CGI, cette directive causera une erreur 500 Internal Server Error. Dans ce cas, supprimez immédiatement la ligne et essayez la méthode suivante.

Méthode 3 : .user.ini (PHP-FPM / CGI)

Pour les serveurs exécutant PHP-FPM, créez ou modifiez un fichier .user.ini dans le répertoire racine de votre PrestaShop :

max_input_vars = 10000

Notez que les modifications de .user.ini ne sont pas immédiates. PHP met ce fichier en cache pour une durée définie par user_ini.cache_ttl, qui est par défaut de 300 secondes (5 minutes). Attendez au moins 5 minutes après la sauvegarde du fichier avant de tester.

Méthode 4 : Panneau de contrôle de l'hébergement

De nombreux hébergeurs exposent les paramètres PHP via leur panneau de contrôle. Dans cPanel, naviguez vers « Sélectionner la version PHP » ou « Éditeur INI MultiPHP » et cherchez max_input_vars. Dans Plesk, allez dans les Paramètres PHP de votre domaine. DirectAdmin et les autres panneaux ont des options similaires. C'est souvent la méthode la plus simple sur un hébergement mutualisé.

La complication du patch Suhosin

Suhosin est un patch de sécurité PHP qui était courant sur les anciens serveurs, particulièrement ceux exécutant PHP 5.x. Il impose son propre ensemble de limites d'entrée qui surcharge le paramètre standard max_input_vars. Même si vous augmentez max_input_vars à 10000, Suhosin peut toujours appliquer une limite inférieure via ses propres directives.

Les paramètres spécifiques à Suhosin que vous devez ajuster sont :

suhosin.post.max_vars = 10000
suhosin.request.max_vars = 10000

Ceux-ci doivent être définis en plus du max_input_vars standard. Si la sortie de votre phpinfo() affiche une section Suhosin, vous êtes concerné et devez ajuster les trois valeurs. Les paramètres Suhosin ne peuvent généralement être modifiés que dans php.ini, pas dans .htaccess ou .user.ini.

Sur les installations modernes PHP 7.x et 8.x, Suhosin est rarement présent. Si vous utilisez une version récente de PHP, vous n'avez presque certainement pas à vous en préoccuper. Cependant, si vous êtes sur un ancien compte d'hébergement mutualisé qui n'a pas été mis à jour, cela vaut la peine de vérifier.

Approches alternatives pour les produits avec plus de 500 déclinaisons

Bien qu'augmenter max_input_vars résolve le problème immédiat, les boutiques avec un nombre extrêmement élevé de déclinaisons par produit devraient envisager des approches alternatives qui réduisent le nombre de champs de formulaire ou contournent entièrement la limitation.

Importer les déclinaisons via CSV

La fonctionnalité d'importation intégrée de PrestaShop traite les déclinaisons par téléchargement de fichier plutôt que par soumission de formulaire, contournant complètement la limite max_input_vars. Préparez un fichier CSV avec vos données de déclinaisons et importez-le via le back office sous Paramètres avancés, Importer. C'est souvent l'approche la plus pratique pour les produits avec des centaines de déclinaisons.

Utiliser l'API Webservice PrestaShop

L'API webservice de PrestaShop vous permet de créer et mettre à jour des déclinaisons de manière programmatique. Les requêtes API ne sont pas soumises à max_input_vars car elles utilisent des charges utiles XML ou JSON structurées plutôt que des données POST encodées en formulaire. Cette approche nécessite des connaissances techniques mais s'adapte à n'importe quel nombre de déclinaisons.

Diviser les produits volumineux

Dans certains cas, il est plus pertinent d'un point de vue commercial de diviser un produit avec plus de 500 déclinaisons en plusieurs produits. Un produit avec 5 tailles et 100 couleurs pourrait être divisé en 5 produits, un par taille, chacun avec 100 options de couleur. Cela permet non seulement d'éviter la limitation technique mais améliore souvent aussi l'expérience client.

Gérer les déclinaisons par lots

Si vous devez utiliser le formulaire du back office, créez les déclinaisons par lots plus petits. Générez 50 déclinaisons à la fois, sauvegardez, puis générez les 50 suivantes. C'est fastidieux mais permet d'éviter d'atteindre la limite sans nécessiter de modification de la configuration serveur.

Vérifier le correctif

Après avoir augmenté max_input_vars, vérifiez que le changement a pris effet. Consultez à nouveau phpinfo() et confirmez que la Valeur locale correspond à ce que vous avez défini. Puis testez en éditant votre produit le plus complexe, en effectuant une petite modification et en sauvegardant. Toutes les déclinaisons et données devraient être préservées.

Si le problème persiste après avoir augmenté la valeur, vérifiez les possibilités supplémentaires suivantes. Votre hébergeur peut surcharger vos paramètres avec une configuration globale. L'instance PHP servant votre site web peut être différente de celle affichée dans un phpinfo() en ligne de commande. Il peut y avoir une limite du serveur web telle que le LimitRequestBody d'Apache ou le client_max_body_size de Nginx qui tronque également la requête. Certains pare-feu applicatifs web (WAF) ou plugins de sécurité (comme ModSecurity) imposent leurs propres limites sur la taille des données POST et le nombre de paramètres.

Paramètres PHP connexes à vérifier

Pendant que vous ajustez max_input_vars, passez en revue ces paramètres connexes qui peuvent également causer des problèmes avec les formulaires de produits volumineux :

post_max_size : Ce paramètre définit la taille maximale des données POST en octets. Si les données de votre formulaire dépassent cette limite (typiquement quand les produits ont de nombreux champs de texte volumineux à travers plusieurs langues), l'intégralité du POST est rejetée. Définissez cette valeur à au moins 32M pour PrestaShop.

memory_limit : Le traitement de milliers de champs de formulaire nécessite de la mémoire. Si PHP manque de mémoire pendant l'analyse des entrées, la requête échoue. Une valeur de 256M ou 512M est recommandée pour PrestaShop.

max_execution_time : La sauvegarde d'un produit avec de nombreuses déclinaisons implique de nombreuses requêtes de base de données. Si l'opération de sauvegarde prend plus de temps que le temps d'exécution autorisé, elle sera interrompue en cours de processus, entraînant des sauvegardes partielles. Définissez cette valeur à au moins 300 secondes pour les boutiques avec des produits complexes.

max_input_nesting_level : PrestaShop utilise des tableaux imbriqués dans ses données de formulaire (par exemple, les champs multilingues utilisent des tableaux comme name[1], name[2]). Le niveau d'imbrication par défaut de 64 est généralement suffisant, mais si vous rencontrez des problèmes avec des structures de formulaire profondément imbriquées, augmentez-le à 128 ou 256.

Notes spécifiques aux versions de PrestaShop

Dans PrestaShop 1.6, la page produit est entièrement en PHP legacy avec une soumission de formulaire traditionnelle. Le problème de max_input_vars affecte toutes les opérations sur la page produit. Il n'y a pas de solution de contournement autre que l'augmentation de la limite ou l'utilisation des importations.

PrestaShop 1.7 a introduit une page produit partiellement basée sur Symfony. Bien que l'architecture ait changé, la soumission de formulaire sous-jacente utilise toujours des données POST et est toujours soumise aux mêmes limites PHP. Le composant de formulaire Symfony peut afficher des messages d'erreur plus informatifs lorsque des champs sont manquants, mais la cause fondamentale est la même.

PrestaShop 8.x présente une page produit entièrement repensée avec une nouvelle structure de formulaire Symfony. La gestion des déclinaisons a été considérablement retravaillée, les déclinaisons étant désormais gérées via une interface dédiée qui charge et sauvegarde les données par AJAX en lots plus petits. Ce changement architectural réduit naturellement l'impact de max_input_vars pour les données de déclinaisons, bien que le formulaire principal du produit puisse toujours être affecté dans les boutiques multilingues avec de nombreuses caractéristiques.

PrestaShop 9.x poursuit la tendance vers la gestion des données basée sur AJAX, réduisant davantage la dépendance aux soumissions massives de formulaires. Cependant, max_input_vars reste pertinent pour les opérations en masse et les modules legacy qui utilisent encore les soumissions de formulaire traditionnelles.

Prévenir les problèmes futurs

Définissez max_input_vars à une valeur généreuse lors de votre installation initiale de PrestaShop plutôt que d'attendre que les problèmes apparaissent. Une valeur de 20000 est sûre pour pratiquement tous les scénarios et n'a aucun impact mesurable sur les performances. Documentez ce paramètre dans vos notes de configuration serveur afin que les futures migrations de serveur le préservent.

Si vous êtes un hébergeur ou un administrateur système gérant plusieurs installations PrestaShop, envisagez de définir max_input_vars = 20000 comme valeur par défaut dans vos modèles de configuration PHP. Ce seul changement élimine l'une des demandes de support les plus courantes liées à la gestion des produits PrestaShop.

Surveillez vos journaux d'erreurs après avoir effectué les modifications. Bien que la troncature de max_input_vars elle-même ne génère pas d'erreurs PHP, certaines versions de PrestaShop enregistrent des avertissements lorsqu'elles détectent que les données reçues ne correspondent pas aux données attendues. Ces entrées de journal peuvent vous aider à identifier si la limite est toujours atteinte malgré votre augmentation.

Lire la réponse complète

Pourquoi les pages blanches surviennent après les mises à jour PrestaShop

Une page blanche, souvent appelée l'écran blanc de la mort (WSOD pour White Screen of Death), est l'un des problèmes les plus courants et les plus alarmants auxquels les propriétaires de boutiques PrestaShop sont confrontés après la mise à jour du logiciel de base. Vous lancez une mise à jour de la version 1.7.8.7 vers 1.7.8.8, ou de 8.1.0 vers 8.1.5, le processus semble se terminer, puis votre boutique entière, tant le front office que le back office, n'affiche plus rien d'autre qu'un écran blanc. Aucun message d'erreur, aucun contenu partiel, juste le néant.

Comprendre pourquoi cela se produit nécessite de comprendre ce que fait une mise à jour du noyau PrestaShop. Le processus de mise à jour remplace des centaines de fichiers PHP, modifie des tables de base de données, régénère les index de classes, vide les caches et exécute potentiellement des requêtes de migration. Toute défaillance à n'importe quel point de cette chaîne peut laisser la boutique dans un état incohérent où PHP rencontre une erreur fatale mais n'a aucun moyen de l'afficher car le rapport d'erreurs est désactivé en mode production.

Les causes les plus courantes se répartissent en plusieurs catégories : des modules incompatibles qui référencent des classes de base supprimées ou modifiées, des incompatibilités de version PHP entre l'ancienne et la nouvelle version de PrestaShop, des conflits de fichiers de surcharge où les surcharges personnalisées entrent en collision avec des fichiers de base modifiés, des ressources serveur insuffisantes provoquant l'interruption de la mise à jour en cours de processus, et des échecs de migration de base de données qui laissent les tables dans un état incohérent.

Étape 1 : Activer le mode débogage

La toute première action face à une page blanche est de rendre les erreurs visibles. PrestaShop supprime l'affichage des erreurs en mode production pour éviter d'exposer des informations sensibles aux visiteurs. Vous devez temporairement activer le mode débogage pour voir ce qui ne va réellement pas.

La méthode la plus rapide consiste à modifier le fichier /config/defines.inc.php. Cherchez la ligne qui définit _PS_MODE_DEV_ et changez-la :

define('_PS_MODE_DEV_', true);

Si vous ne pouvez pas accéder aux fichiers via FTP ou SSH parce que votre panneau d'hébergement est également inaccessible, certains hébergeurs offrent un gestionnaire de fichiers via leur panneau de contrôle (cPanel, Plesk, DirectAdmin) qui fonctionne indépendamment de votre installation PrestaShop.

Dans PrestaShop 8.x, vous pouvez également activer le mode débogage via le fichier .env dans le répertoire racine. Changez APP_ENV=prod en APP_ENV=dev et définissez APP_DEBUG=1. Cela active la barre d'outils de débogage Symfony et les pages d'erreur détaillées.

Après avoir activé le mode débogage, rechargez la page. Au lieu d'un écran blanc, vous devriez maintenant voir un message d'erreur détaillé avec un chemin de fichier, un numéro de ligne et une trace de pile. Ce message d'erreur est la clé pour diagnostiquer et résoudre le problème.

Étape 2 : Vérifier les journaux d'erreurs

Si l'activation du mode débogage affiche toujours une page blanche (ce qui peut arriver si l'erreur survient avant même que PHP ne charge le framework PrestaShop), vérifiez directement les journaux d'erreurs de votre serveur.

Sur les serveurs Apache, le journal d'erreurs se trouve généralement à /var/log/apache2/error.log ou /var/log/httpd/error_log. Sur Nginx avec PHP-FPM, vérifiez /var/log/nginx/error.log et /var/log/php-fpm/error.log (ou /var/log/php8.1-fpm.log selon votre version de PHP). Sur un hébergement mutualisé, les journaux d'erreurs sont généralement accessibles via le panneau de contrôle de l'hébergement ou dans un répertoire logs au sein de votre compte d'hébergement.

PrestaShop maintient également ses propres fichiers de journalisation dans le répertoire /var/logs/ (PrestaShop 1.7) ou le répertoire /var/log/ (PrestaShop 8.x). Cherchez les fichiers nommés avec la date du jour. Ces journaux basés sur Symfony peuvent contenir des informations détaillées sur ce qui a mal tourné pendant le processus de mise à jour.

De plus, vérifiez le répertoire /log/ à la racine de votre PrestaShop pour tout fichier de journal d'erreurs. Certaines versions de PrestaShop y écrivent les erreurs critiques lorsqu'elles ne peuvent pas les afficher à l'écran.

Cause courante 1 : Modules incompatibles

Les modules sont la cause la plus fréquente des pages blanches après les mises à jour. Un module qui fonctionnait parfaitement sur PrestaShop 1.7.8.7 peut faire planter toute la boutique sur 1.7.8.8 s'il utilise des classes internes du noyau ou des méthodes qui ont changé lors de la mise à jour.

Le message d'erreur ressemble généralement à : Fatal error: Class 'SomeClassName' not found ou Fatal error: Call to undefined method ClassName::methodName() ou Fatal error: Declaration of ModuleClass::hookMethod() must be compatible with CoreClass::hookMethod().

Pour corriger cela, vous devez identifier et désactiver le module problématique. Si vous pouvez accéder au back office (parfois seul le front office plante), allez dans Modules et désactivez les modules récemment installés ou mis à jour un par un jusqu'à ce que le problème se résolve.

Si le back office est également inaccessible, désactivez les modules via la base de données. Connectez-vous à votre base de données en utilisant phpMyAdmin ou un client MySQL et exécutez :

UPDATE ps_module SET active = 0 WHERE name = 'nom_module_problematique';

Si vous ne savez pas quel module cause le problème, vous pouvez désactiver tous les modules tiers d'un coup en mettant leur colonne active à 0. D'abord, identifiez quels modules sont tiers en vérifiant le répertoire /modules/ pour les modules non-PrestaShop. Puis désactivez-les sélectivement.

Une approche plus radicale consiste à renommer le répertoire du module. Par exemple, renommez /modules/somemodule/ en /modules/somemodule_disabled/. PrestaShop ne peut pas charger un module dont le répertoire ne correspond pas à son nom enregistré, le désactivant effectivement sans toucher à la base de données.

Cause courante 2 : Incompatibilité de version PHP

Chaque version de PrestaShop requiert une plage de versions PHP spécifique. PrestaShop 1.7.6 et antérieur nécessitent PHP 7.1 à 7.3. PrestaShop 1.7.7 à 1.7.8 supportent PHP 7.2 à 8.0. PrestaShop 8.0 nécessite PHP 7.2 à 8.1. PrestaShop 8.1 nécessite PHP 8.0 à 8.2. PrestaShop 9.0 nécessite PHP 8.1 ou supérieur.

Si votre environnement d'hébergement a changé de version PHP pendant ou en parallèle de la mise à jour PrestaShop, vous pouvez rencontrer des erreurs de syntaxe ou des appels de fonctions dépréciées. Les erreurs courantes de compatibilité PHP incluent : Deprecated: Function create_function() is deprecated (PHP 7.2+ avec du code écrit pour PHP 5.x), Fatal error: Uncaught Error: Call to undefined function mysql_connect() (PHP 7.0+ a supprimé l'extension mysql), et Fatal error: Array and string offset access syntax with curly braces is no longer supported (PHP 8.0+).

Vérifiez votre version PHP actuelle en regardant la sortie de phpinfo() ou en exécutant php -v en ligne de commande. Si la version est en dehors de la plage supportée pour votre version de PrestaShop, basculez vers une version PHP compatible via le panneau de contrôle de votre hébergement.

Cause courante 3 : Conflits de surcharges

Le système de surcharge de PrestaShop permet aux modules et aux développeurs de modifier le comportement du noyau en plaçant des fichiers de classes modifiés dans le répertoire /override/. Lors d'une mise à jour, les classes du noyau changent, mais les fichiers de surcharge restent. Si une surcharge référence une signature de méthode qui a changé, une propriété qui a été supprimée ou une classe qui a été renommée, la surcharge provoque une erreur fatale.

Le fichier d'index de classes à /var/cache/prod/class_index.php (ou /cache/class_index.php sur les versions plus anciennes) fait correspondre les noms de classes à leurs emplacements de fichiers, y compris les surcharges. Un index de classes périmé ou corrompu peut charger le mauvais fichier pour une classe, causant des plantages immédiats.

Pour tester si les surcharges sont le problème, désactivez temporairement le système de surcharge. Éditez /config/defines.inc.php et ajoutez ou modifiez :

define('_PS_HOST_MODE_', false);

Puis supprimez le fichier d'index de classes pour forcer PrestaShop à le régénérer sans surcharges. Si la boutique se charge après cette modification, le problème se trouve dans l'un de vos fichiers de surcharge.

Pour identifier la surcharge problématique spécifique, regardez dans les répertoires /override/classes/ et /override/controllers/. Supprimez les fichiers de surcharge un par un, en supprimant l'index de classes après chaque suppression, jusqu'à ce que vous trouviez celui qui cause le plantage. Une fois identifié, soit mettez à jour la surcharge pour qu'elle soit compatible avec la nouvelle version du noyau, soit supprimez-la entièrement si elle n'est plus nécessaire.

Cause courante 4 : Cache et fichiers compilés

PrestaShop génère des templates Smarty compilés, des caches de conteneur Symfony, des cartes de classes et divers autres fichiers en cache qui deviennent invalides après une mise à jour. Si le processus de mise à jour n'a pas correctement vidé ces caches, la boutique tente d'utiliser des fichiers en cache qui référencent l'ancienne structure de code.

Videz tous les caches manuellement en supprimant le contenu de ces répertoires (supprimez le contenu, pas les répertoires eux-mêmes) :

/var/cache/prod/ et /var/cache/dev/ pour le cache Symfony. Supprimez tout à l'intérieur de ces répertoires. PrestaShop les régénérera au prochain chargement de page.

/cache/smarty/compile/ et /cache/smarty/cache/ pour les caches de templates Smarty. Les templates compilés périmés sont une cause très courante de pages blanches après les mises à jour.

/var/cache/prod/class_index.php (ou /cache/class_index.php) pour la carte des classes. Ce fichier doit être régénéré après toute mise à jour.

Sur les configurations PHP-FPM, réinitialisez également OPcache. OPcache stocke le bytecode PHP compilé en mémoire, et il peut servir l'ancien code même après que les fichiers ont été remplacés. Redémarrez le service PHP-FPM, ou si vous ne pouvez pas le faire, créez un petit fichier PHP qui appelle opcache_reset() et accédez-y via votre navigateur.

Cause courante 5 : Échecs de migration de base de données

Les mises à jour PrestaShop incluent souvent des modifications de schéma de base de données : nouvelles colonnes, index modifiés, nouvelles tables ou migrations de données. Si le processus de mise à jour a été interrompu (timeout, limite de mémoire, coupure de connexion), la base de données peut se trouver dans un état partiellement migré.

Vérifiez la base de données PrestaShop dans la table ps_configuration et cherchez la valeur PS_VERSION_DB. Si cette valeur ne correspond pas à la version des fichiers sur le disque, la mise à jour ne s'est pas terminée correctement. PrestaShop peut tenter de relancer les migrations au chargement suivant, ou simplement échouer.

Les échecs de migration de base de données sont les plus difficiles à récupérer sans sauvegarde. Si vous disposez d'une sauvegarde de la base de données d'avant la mise à jour, la restaurer et relancer la mise à jour est souvent le chemin le plus sûr. Si vous n'avez pas de sauvegarde, vous devrez peut-être appliquer manuellement les fichiers de migration SQL manquants qui se trouvent dans le répertoire /install/upgrade/sql/.

Procédure de récupération étape par étape

Suivez cette séquence lors de la récupération d'une page blanche après une mise à jour du noyau. L'ordre est important car chaque étape soit résout le problème, soit élimine une cause possible.

Étape 1 : Activez le mode débogage dans /config/defines.inc.php en mettant _PS_MODE_DEV_ à true. Rechargez la page et lisez le message d'erreur.

Étape 2 : Supprimez le contenu de /var/cache/prod/, /var/cache/dev/, /cache/smarty/compile/ et /cache/smarty/cache/. Supprimez class_index.php. Rechargez la page.

Étape 3 : Si l'erreur pointe vers un module spécifique, désactivez ce module en renommant son répertoire ou en mettant active = 0 dans la table de base de données ps_module. Rechargez la page.

Étape 4 : Si l'erreur pointe vers un fichier de surcharge, déplacez le contenu du répertoire /override/ vers un emplacement de sauvegarde temporaire. Supprimez à nouveau class_index.php. Rechargez la page.

Étape 5 : Vérifiez que votre version PHP est compatible avec la version PrestaShop vers laquelle vous avez fait la mise à jour. Vérifiez phpinfo() ou php -v. Changez de version PHP si nécessaire.

Étape 6 : Vérifiez les permissions de fichiers. Le processus de mise à jour peut avoir créé des fichiers avec une propriété incorrecte. Tous les fichiers PrestaShop doivent être lisibles par l'utilisateur du serveur web, et les répertoires /var/, /cache/, /img/, /upload/, /download/, /translations/, /themes/ et /modules/ doivent être accessibles en écriture.

Étape 7 : Si rien de ce qui précède ne résout le problème et que vous disposez d'une sauvegarde de la base de données, restaurez la base de données et les fichiers à partir de la sauvegarde, puis tentez à nouveau la mise à jour après avoir résolu les problèmes identifiés lors du diagnostic.

Procédure de mise à jour sécurisée pour les futures mises à jour

La prévention est bien meilleure que la récupération. Suivez cette procédure pour chaque mise à jour du noyau PrestaShop afin de minimiser le risque de pages blanches et de perte de données.

Avant la mise à jour : Créez une sauvegarde complète à la fois de la base de données et de tous les fichiers. Pas seulement la base de données, pas seulement les fichiers, mais les deux. Stockez ces sauvegardes dans un emplacement en dehors de votre compte d'hébergement si possible. Testez que vous pouvez réellement restaurer à partir de ces sauvegardes avant de procéder.

Désactivez tous les modules tiers. C'est la mesure la plus efficace que vous puissiez prendre pour prévenir les pages blanches. Les modules natifs (ceux livrés avec PrestaShop) sont conçus pour être compatibles avec la mise à jour, mais les modules tiers ne sont pas garantis de l'être. Désactivez-les avant la mise à jour et réactivez-les un par un après, en testant la boutique après chaque réactivation.

Désactivez le système de surcharge. Si vous avez des surcharges personnalisées, désactivez-les avant la mise à jour. Réévaluez chaque surcharge après la mise à jour pour déterminer si elle est toujours compatible et toujours nécessaire.

Lisez les notes de version. Chaque version de PrestaShop inclut des notes sur les exigences de compatibilité, les problèmes connus et les changements avec rupture de compatibilité. Lisez-les avant de mettre à jour, pas après que quelque chose ait cassé.

Mettez la boutique en mode maintenance. Cela empêche les clients de passer des commandes pendant la mise à jour et de rencontrer des erreurs. Naviguez vers Paramètres de la boutique, Général, Maintenance dans le back office et activez le mode maintenance.

Pendant la mise à jour : Surveillez le processus de mise à jour. Ne fermez pas l'onglet du navigateur et ne naviguez pas ailleurs. Si la mise à jour prend plus de temps que prévu, vérifiez les journaux d'erreurs de votre serveur pour les erreurs de timeout ou de mémoire. Si le processus semble bloqué, attendez au moins 10 minutes avant d'entreprendre toute action, car les grandes boutiques peuvent avoir des migrations de base de données significatives à traiter.

Après la mise à jour : Videz tous les caches. Vérifiez que le back office se charge correctement. Vérifiez le front office. Réactivez les modules un par un, en vérifiant la boutique après chacun. Réactivez les surcharges une par une le cas échéant. Désactivez le mode maintenance. Surveillez les journaux d'erreurs pendant les 24 heures suivantes.

Stratégies de retour en arrière

Lorsque la récupération n'est pas possible ou prend trop de temps, revenir à la version précédente peut être la meilleure option. Cependant, PrestaShop ne dispose pas d'un mécanisme de retour en arrière intégré, vous devez donc planifier cette possibilité avant de commencer la mise à jour.

Retour complet depuis une sauvegarde : Restaurez à la fois la base de données et les fichiers à partir de votre sauvegarde d'avant la mise à jour. C'est l'approche la plus propre mais elle nécessite d'avoir fait une sauvegarde complète avant la mise à jour. Après la restauration, vérifiez que la boutique fonctionne correctement et qu'aucune commande ou donnée client créée pendant la période de mise à jour échouée n'est perdue (si la boutique était en mode maintenance, rien n'aurait dû changer).

Retour partiel des fichiers : Si seuls les fichiers sont corrompus mais que la base de données est intacte, vous pouvez remplacer les fichiers PrestaShop par la version précédente tout en conservant la base de données actuelle. Téléchargez la version précédente exacte de PrestaShop depuis l'archive officielle des versions, extrayez-la et écrasez les fichiers sur votre serveur. Conservez vos modules personnalisés, thèmes et fichiers de configuration. Cette approche est risquée car la base de données peut avoir été partiellement migrée, créant une incohérence entre les fichiers et le schéma de la base de données.

Correction directe : Parfois le chemin le plus rapide n'est pas de revenir en arrière mais de corriger l'erreur spécifique. Si l'erreur est causée par un seul module ou surcharge incompatible, corriger ou supprimer ce seul composant peut prendre quelques minutes comparé à des heures pour un retour complet. Cette approche est la meilleure lorsque vous avez clairement identifié la cause à partir du message d'erreur.

L'importance des sauvegardes de base de données

Chaque section de ce guide mentionne les sauvegardes, et pour une bonne raison. Une base de données PrestaShop contient chaque produit, chaque commande, chaque compte client, chaque paramètre de configuration et chaque contenu de votre boutique. La perdre signifie perdre les données de votre entreprise.

Les sauvegardes quotidiennes automatisées ne sont pas optionnelles pour une boutique PrestaShop en production. Configurez le système de sauvegarde de votre hébergeur, utilisez un module de sauvegarde de base de données, ou configurez une tâche cron qui exécute mysqldump à intervalles réguliers. Stockez les sauvegardes à plusieurs emplacements. Testez votre procédure de restauration périodiquement pour vous assurer que les sauvegardes sont réellement utilisables.

Avant toute mise à jour, créez une sauvegarde manuelle en plus de vos sauvegardes automatisées. Nommez-la clairement avec la date et la version PrestaShop, afin de pouvoir l'identifier immédiatement si vous devez la restaurer.

Quand faire appel à un professionnel

Si vous avez suivi toutes les étapes de ce guide et faites toujours face à une page blanche, ou si les messages d'erreur pointent vers des problèmes profonds du noyau nécessitant des corrections au niveau du code, il est peut-être temps de faire appel à un développeur PrestaShop. Fournissez-lui les messages d'erreur que vous avez recueillis, les versions de PrestaShop impliquées (avant et après la mise à jour), votre version PHP et toutes les actions que vous avez déjà entreprises. Ces informations réduiront considérablement le temps nécessaire pour diagnostiquer et résoudre le problème.

Tenter de modifier manuellement les fichiers du noyau PrestaShop sans comprendre l'architecture du framework peut créer des problèmes supplémentaires. Si le message d'erreur fait référence aux conteneurs Symfony, à l'injection de dépendances ou à la configuration du kernel, ce sont des domaines où des modifications incorrectes peuvent provoquer des défaillances en cascade.

Lire la réponse complète

Comment fonctionnent les mises à jour du panier dans PrestaShop

Avant de plonger dans le dépannage, il est utile de comprendre comment PrestaShop gère les opérations du panier. Lorsqu'un client clique sur « Ajouter au panier », le JavaScript côté front-end envoie une requête AJAX au serveur. Le serveur traite la requête, met à jour le panier dans la base de données et dans la session, puis renvoie une réponse JSON contenant le récapitulatif du panier mis à jour. Le JavaScript reçoit cette réponse et met à jour le bloc panier, la page produit et tous les autres éléments dépendants du panier sur la page, sans rechargement complet.

Cette approche pilotée par AJAX, introduite pleinement dans PrestaShop 1.7, a remplacé l'ancienne méthode par rechargement de page utilisée dans PrestaShop 1.6. Bien qu'elle offre une expérience d'achat beaucoup plus fluide, elle introduit également davantage de points de défaillance potentiels. Une mise à jour du panier peut échouer au niveau du JavaScript, de la requête AJAX, du traitement côté serveur ou du rendu de la réponse. Chaque point de défaillance produit des symptômes différents et nécessite des approches de diagnostic différentes.

Dans PrestaShop 1.7 et 8.x, le fichier JavaScript principal responsable des opérations du panier est core.js, qui utilise jQuery pour envoyer des requêtes AJAX au contrôleur du panier. Le contrôleur du panier traite la requête et déclenche des événements auxquels les modules peuvent se connecter via des hooks. La réponse déclenche un événement global sur la page (updateCart) que tous les composants liés au panier écoutent pour rafraîchir les données affichées.

Symptôme : cliquer sur Ajouter au panier ne fait rien

Lorsque le clic sur le bouton Ajouter au panier ne produit absolument aucune réponse — pas d'animation, pas de spinner, pas d'erreur — le problème est presque toujours une erreur JavaScript qui empêche le gestionnaire de clic de s'exécuter. L'événement de clic du bouton n'est jamais capturé, donc aucune requête AJAX n'est envoyée au serveur.

Ouvrez les outils de développement de votre navigateur (F12 ou Ctrl+Maj+I dans Chrome, Firefox et Edge) et basculez vers l'onglet Console. Rechargez la page produit et recherchez les messages d'erreur en rouge. Les erreurs courantes incluent $ is not defined ou jQuery is not defined (jQuery n'a pas réussi à se charger), Uncaught TypeError: Cannot read property of undefined (le JavaScript d'un module fait référence à quelque chose qui n'existe pas), ou Uncaught SyntaxError (un fichier JavaScript contient une erreur de syntaxe, souvent due à un module qui n'a pas été correctement minifié).

Une seule erreur JavaScript sur la page peut interrompre l'exécution de tout le JavaScript suivant, y compris la fonctionnalité principale du panier. Si un module chargé avant le JavaScript central de PrestaShop génère une erreur, l'ensemble du système de panier est cassé, même si le module n'a rien à voir avec le panier.

Pour identifier le module fautif, regardez le nom du fichier dans le message d'erreur. Il fera généralement référence à un chemin du type /modules/somemodule/views/js/somefile.js. Désactivez ce module temporairement pour confirmer qu'il est la cause, puis contactez le développeur du module pour obtenir un correctif.

Symptôme : Ajouter au panier tourne sans fin

Si le clic sur Ajouter au panier déclenche l'animation de chargement mais qu'elle tourne indéfiniment, la requête AJAX a été envoyée mais n'a soit reçu aucune réponse, soit reçu une réponse d'erreur. Basculez vers l'onglet Réseau dans les outils de développement, cliquez sur Ajouter au panier et recherchez la requête AJAX. Il s'agira généralement d'une requête POST vers une URL contenant controller=cart ou cart dans le chemin.

Cliquez sur la requête pour l'inspecter. Vérifiez la colonne Statut : un statut 200 avec un corps de réponse vide ou malformé indique une erreur PHP sur le serveur qui a été interceptée avant la sortie. Un statut 500 indique une erreur serveur non gérée. Un statut 403 peut indiquer qu'un module de sécurité ou un WAF bloque la requête. Un statut 408 ou un timeout indique que le serveur a mis trop de temps à répondre.

Si le statut est 200 mais que le corps de la réponse contient du HTML au lieu du JSON (recherchez des balises HTML dans la réponse), cela signifie que PHP a rencontré un warning ou un notice qui a été envoyé en sortie avant la réponse JSON, cassant ainsi l'analyse JSON. C'est extrêmement courant et cela est causé par des modules ou des overrides qui produisent du texte (même une ligne vide avant la balise PHP d'ouverture) pendant les hooks de traitement du panier.

Symptôme : le panier se met à jour mais affiche des données incorrectes

Parfois, le panier semble fonctionner : l'animation se joue, l'icône du panier se met à jour, mais les quantités, prix ou produits affichés sont incorrects. Il s'agit généralement d'un problème de cache où le client voit des données obsolètes au lieu des données du panier fraîchement calculées.

PrestaShop dispose de plusieurs couches de cache, chacune pouvant servir des informations de panier périmées. Comprendre et vérifier systématiquement chaque couche est essentiel pour diagnostiquer ce type de problème.

Problèmes de cache du navigateur

Le navigateur lui-même peut mettre en cache les réponses AJAX ou les fichiers JavaScript statiques. Bien que les requêtes AJAX POST ne devraient pas être mises en cache par les navigateurs, certaines configurations de cache agressives ou des service workers peuvent interférer.

Testez en ouvrant une fenêtre de navigation privée ou incognito. Si le panier fonctionne correctement en mode incognito, le problème est lié au cache du navigateur. Demandez au client de vider le cache de son navigateur, ou plus précisément, d'essayer un rafraîchissement forcé avec Ctrl+Maj+R (Windows/Linux) ou Cmd+Maj+R (Mac).

Si votre thème PrestaShop utilise un service worker pour les fonctionnalités d'application web progressive (PWA), le service worker peut intercepter et mettre en cache les requêtes AJAX. Vérifiez l'onglet Application dans les outils de développement, puis Service Workers, pour voir si un service worker est enregistré. Désenregistrez-le temporairement pour tester s'il est à l'origine du problème.

Les fichiers JavaScript statiques peuvent également être mis en cache. Si vous avez récemment mis à jour un module qui modifie le comportement du panier, le navigateur du client peut encore utiliser l'ancien fichier JavaScript. PrestaShop ajoute une chaîne de requête de version aux URL JavaScript (comme cart.js?v=1.0.0), mais cela ne fonctionne que si le module incrémente correctement son numéro de version lors de la mise à jour.

Conflits de cache Smarty

PrestaShop utilise le moteur de templates Smarty pour rendre le HTML côté serveur. Smarty possède son propre système de compilation et de mise en cache qui peut servir des sorties de templates obsolètes.

Si des templates liés au panier ont été modifiés (par une mise à jour du thème, l'installation d'un module ou une modification manuelle) mais que le cache Smarty n'a pas été vidé, l'ancien template continue d'être servi. Les templates compilés sont stockés dans /var/cache/prod/smarty/compile/ et les sorties mises en cache dans /var/cache/prod/smarty/cache/. Supprimer le contenu de ces deux répertoires force Smarty à recompiler tous les templates à partir des fichiers sources actuels.

Vous pouvez également vider le cache Smarty depuis le back office. Accédez à Paramètres avancés, puis Performances, et cliquez sur le bouton « Vider le cache ». Dans PrestaShop 8.x, vous pouvez également utiliser le bouton « Vider le cache Symfony » qui vide à la fois le cache du conteneur Symfony et le cache Smarty.

Un problème Smarty plus subtil concerne les paramètres « Forcer la compilation » et « Cache » sous Paramètres avancés, Performances, Smarty. Pendant le développement ou le débogage, réglez la Compilation des templates sur « Forcer la compilation » et le Cache sur « Non ». Cela garantit que chaque chargement de page utilise les derniers fichiers de templates. N'oubliez pas de rétablir ces paramètres à « Recompiler les templates si les fichiers ont été modifiés » et « Oui » après le débogage, car la compilation forcée impacte significativement les performances.

Paramètres CCC et leur impact

La fonctionnalité CCC (Combiner, Compresser, Cacher) de PrestaShop, accessible sous Paramètres avancés, Performances, fusionne et minifie les fichiers CSS et JavaScript pour améliorer les temps de chargement des pages. Bien que bénéfique pour les performances, le CCC peut causer des problèmes de panier de plusieurs manières.

Lorsque le CCC est activé, PrestaShop combine plusieurs fichiers JavaScript en un seul fichier mis en cache. Si le JavaScript d'un module dépend de l'ordre de chargement (il doit s'exécuter après jQuery mais avant le code d'un autre module), le processus de combinaison peut réorganiser les fichiers de manière incorrecte, provoquant l'échec du code dépendant.

Le CCC met également en cache les fichiers combinés de manière agressive. Après l'installation, la mise à jour ou la suppression d'un module, l'ancien fichier combiné peut encore être servi. La solution consiste à vider manuellement le cache CCC en allant dans Paramètres avancés, Performances, et en cliquant sur « Vider le cache » ou en supprimant les fichiers mis en cache dans /themes/your_theme/cache/.

Un problème CCC particulièrement frustrant survient lorsqu'un fichier JavaScript d'un module contient une erreur de syntaxe. Lorsque le CCC le combine avec d'autres fichiers, l'erreur de syntaxe casse l'ensemble du bundle JavaScript combiné, désactivant toutes les fonctionnalités JavaScript de la page, y compris le panier. Sans le CCC, seul le JavaScript de ce module échouerait tandis que le reste continuerait de fonctionner. Désactiver le CCC temporairement peut aider à isoler ce type de problème.

Pour tester si le CCC est à l'origine de votre problème de panier, désactivez les trois options CCC (Cache intelligent pour le CSS, Cache intelligent pour le JavaScript et Optimisation Apache) dans les paramètres de Performances. Videz tous les caches. Si le panier recommence à fonctionner, réactivez les options une par une pour identifier celle qui cause le conflit.

Problèmes de cache CDN

Si votre boutique PrestaShop utilise un CDN (réseau de diffusion de contenu) tel que Cloudflare, KeyCDN ou CloudFront, le CDN peut mettre en cache des réponses qui ne devraient pas l'être. Les CDN sont conçus pour mettre en cache le contenu statique, mais des configurations incorrectes peuvent les amener à mettre en cache des réponses AJAX dynamiques ou des pages dépendantes de la session.

Cloudflare en particulier est connu pour mettre en cache les réponses aux requêtes POST lorsque certaines règles de page ou des règles de type « tout mettre en cache » sont configurées de manière trop large. Le point de terminaison AJAX du panier renvoie des données spécifiques au client qui ne doivent jamais être mises en cache par un CDN.

Pour tester si le CDN est impliqué, contournez-le temporairement. Dans Cloudflare, vous pouvez mettre en pause le CDN ou ajouter une règle de page pour contourner le cache pour l'ensemble de votre domaine temporairement. Si le panier fonctionne correctement sans le CDN, passez en revue vos règles de mise en cache pour vous assurer que les points de terminaison AJAX et les pages dynamiques sont exclus de la mise en cache.

Pour Cloudflare spécifiquement, assurez-vous que la règle de page « Cache Everything » ne couvre pas l'ensemble de votre domaine. Si vous devez l'utiliser, ajoutez une règle de priorité supérieure qui contourne le cache pour les URL contenant controller=cart, ajax=true et le chemin du processus de commande. Vérifiez également que le « Browser Cache TTL » n'est pas réglé trop haut pour les ressources dynamiques.

Problèmes de cookies et de session

PrestaShop utilise des cookies pour maintenir la session d'achat, y compris le panier. Si les cookies ne fonctionnent pas correctement, le panier ne peut pas persister entre les requêtes. Chaque mise à jour AJAX du panier crée une nouvelle session au lieu de mettre à jour la session existante, ce qui donne un panier qui semble vide après chaque chargement de page.

Les problèmes de cookies courants incluent : le domaine du cookie est mal configuré (le cookie est défini pour www.example.com mais la requête AJAX est envoyée à example.com sans le préfixe www, ou vice versa), le chemin du cookie est incorrect, l'attribut SameSite est défini sur Strict ce qui bloque les cookies dans certains scénarios cross-origin, ou le cookie est trop volumineux et est rejeté par le navigateur (les navigateurs limitent généralement la taille des cookies à 4 Ko).

Vérifiez les cookies dans l'onglet Application des outils de développement. Recherchez le cookie de session PrestaShop (nommé PrestaShop-[hash] dans les versions récentes). Vérifiez qu'il possède le bon domaine, le bon chemin et qu'il est envoyé avec les requêtes AJAX (vérifiez l'en-tête Cookie dans l'onglet Réseau pour la requête AJAX du panier).

Sur les configurations multi-domaines ou multi-boutiques, les problèmes de cookies sont particulièrement courants. Si la boutique est accessible via http et https, ou via les versions www et non-www, le cookie peut ne pas être partagé entre ces variantes. Assurez-vous que votre boutique utilise une seule URL canonique et que toutes les autres variantes redirigent vers celle-ci.

Les problèmes de certificat SSL peuvent également empêcher les cookies de fonctionner. Si l'attribut Secure est défini sur le cookie mais que la page est chargée via HTTP (ou avec du contenu mixte), le navigateur n'enverra pas le cookie. Assurez-vous que l'ensemble de votre boutique est servi de manière cohérente en HTTPS.

Conflits de modules : processus de diagnostic

Les conflits de modules sont la cause la plus courante des problèmes de panier dans PrestaShop. Deux modules ou plus peuvent se connecter aux mêmes événements du panier et interférer entre eux, ou un seul module peut avoir un bug qui corrompt la réponse du panier.

L'approche systématique pour diagnostiquer les conflits de modules consiste à désactiver les modules par groupes. Commencez par désactiver tous les modules tiers (gardez les modules natifs de PrestaShop actifs). Si le panier fonctionne, réactivez les modules par groupes de 5. Lorsque le problème réapparaît, vous l'avez réduit à 5 modules. Désactivez ces 5 modules et réactivez-les un par un pour trouver le coupable exact.

Portez une attention particulière aux modules qui se connectent aux hooks PrestaShop suivants, car ils affectent directement le comportement du panier : actionCartSave, actionCartUpdate, displayShoppingCart, displayShoppingCartFooter, actionBeforeCartUpdateQty, actionAfterCartUpdateQty, displayHeader (les modules qui ajoutent du JavaScript ici peuvent entrer en conflit avec le JS du panier), et actionFrontControllerSetMedia.

Pour voir quels modules sont enregistrés sur les hooks liés au panier, interrogez la base de données :

SELECT h.name, m.name FROM ps_hook_module hm JOIN ps_hook h ON h.id_hook = hm.id_hook JOIN ps_module m ON m.id_module = hm.id_module WHERE h.name LIKE '%cart%' ORDER BY h.name, hm.position;

Cette requête liste tous les modules connectés aux hooks liés au panier, ainsi que leur ordre d'exécution. Les conflits surviennent souvent lorsque deux modules tentent tous les deux de modifier le total du panier ou d'appliquer des réductions de manière incompatible.

Déboguer avec les DevTools du navigateur : guide détaillé pas à pas

Les outils de développement du navigateur sont votre arme la plus puissante pour diagnostiquer les problèmes de panier. Voici un guide détaillé étape par étape pour les utiliser efficacement.

Étape 1 : Ouvrez les DevTools et allez dans l'onglet Console. Effacez tous les messages existants. Rechargez la page produit. Notez toutes les erreurs ou avertissements qui apparaissent. Ce sont des problèmes préexistants qui peuvent ou non être liés au problème de panier, mais qui doivent être documentés.

Étape 2 : Basculez vers l'onglet Réseau. Cochez la case « Conserver le journal » pour que les requêtes ne soient pas effacées lors de la navigation. Filtrez par « XHR » ou « Fetch » pour ne voir que les requêtes AJAX. Cliquez sur le bouton Ajouter au panier.

Étape 3 : Examinez la requête AJAX. Cliquez sur la requête du panier qui apparaît. Dans le sous-onglet En-têtes, vérifiez que l'URL de la requête est correcte et que le code de statut est 200. Dans le sous-onglet Données du formulaire ou Charge utile de la requête, vérifiez que l'identifiant du produit, la quantité et la combinaison d'attributs corrects sont envoyés.

Étape 4 : Vérifiez la réponse. Basculez vers le sous-onglet Réponse ou Aperçu. La réponse doit être du JSON valide. Si vous voyez du HTML mélangé, une erreur ou un avertissement PHP est émis en sortie. Si la réponse est vide, le traitement côté serveur s'est interrompu avant de générer la sortie. Si le JSON est valide mais contient des messages d'erreur, lisez-les pour obtenir des indices.

Étape 5 : Vérifiez la Console après la réponse AJAX. Les erreurs JavaScript qui se produisent lors du traitement de la réponse AJAX apparaîtront dans la Console après la fin de la requête réseau. Ces erreurs indiquent que la réponse a été reçue mais n'a pas pu être correctement traitée par le JavaScript côté front-end.

Considérations spécifiques à PrestaShop 8.x

PrestaShop 8.x utilise une architecture front-end significativement mise à jour par rapport à la version 1.7. Le JavaScript du panier a été remanié, et une partie du code précédemment dépendant de jQuery utilise désormais du JavaScript natif ou des méthodes jQuery mises à jour. Les modules écrits pour PrestaShop 1.7 qui manipulent directement le DOM du panier peuvent échouer sur la version 8.x car la structure HTML et les noms de classes CSS ont changé.

L'intégration de Symfony dans PrestaShop 8.x signifie également que le vidage du cache est plus complexe. Le cache du conteneur Symfony, situé dans /var/cache/prod/ et /var/cache/dev/, peut contenir des définitions de services compilées et des mappages de routes qui affectent la manière dont les contrôleurs du panier traitent les requêtes. Vider uniquement le cache Smarty ne suffit pas ; vous devez également vider le cache Symfony.

PrestaShop 8.x a également introduit des en-têtes Content Security Policy (CSP) plus stricts dans certaines configurations. Si votre serveur ou un module de sécurité ajoute des en-têtes CSP qui restreignent le JavaScript en ligne ou les requêtes AJAX vers des domaines spécifiques, les appels AJAX du panier peuvent être bloqués. Vérifiez la Console pour les messages de violation CSP, qui apparaissent sous forme d'erreurs rouges mentionnant « Content Security Policy ».

Problèmes côté serveur : sessions PHP et configuration

La configuration des sessions PHP peut causer des problèmes de panier difficiles à diagnostiquer car ils apparaissent de manière intermittente. Si le répertoire de stockage des sessions est plein, a des permissions incorrectes ou se trouve sur un système de fichiers ne supportant pas le verrouillage de fichiers, les sessions peuvent être perdues ou corrompues entre les requêtes.

Vérifiez la configuration de vos sessions PHP : session.save_path doit pointer vers un répertoire accessible en écriture avec suffisamment d'espace disque. session.gc_maxlifetime contrôle la durée de conservation des sessions ; si cette valeur est trop basse, les clients perdent leur panier lors de longues sessions de navigation. session.cookie_lifetime doit correspondre ou dépasser la valeur de gc_maxlifetime.

Sur les hébergements mutualisés avec de nombreux sites, le répertoire de sessions peut contenir des millions de fichiers provenant de tous les sites hébergés, ralentissant l'accès aux fichiers de session. Si votre hébergeur le prend en charge, configurez un répertoire de sessions dédié à votre site ou utilisez des sessions basées sur la base de données.

Pour les boutiques utilisant plusieurs serveurs web derrière un répartiteur de charge, les sessions doivent être partagées entre les serveurs. Si le stockage des sessions est basé sur des fichiers et local à chaque serveur, une requête suivante du client peut être dirigée vers un serveur différent qui ne possède pas sa session, aboutissant à un panier vide. Utilisez un stockage de sessions partagé tel que Redis, Memcached ou des sessions en base de données dans les environnements à répartition de charge.

Checklist de diagnostic étape par étape

Lorsqu'un client signale que le panier ne se met pas à jour, suivez cette checklist dans l'ordre :

1. Reproduisez le problème. Essayez de reproduire le problème dans une fenêtre de navigation privée en utilisant le même produit et le même navigateur que ceux signalés par le client. Si vous ne pouvez pas le reproduire, demandez au client la version de son navigateur, le type de son appareil et les étapes exactes.

2. Vérifiez la console du navigateur pour les erreurs JavaScript. Tout message d'erreur en rouge est potentiellement la cause, même s'il semble sans rapport avec le panier.

3. Vérifiez la requête réseau. Vérifiez que la requête AJAX est envoyée, renvoie un statut 200 et contient du JSON valide.

4. Videz tous les caches : cache de compilation Smarty, cache Smarty, cache Symfony, cache CCC, OPcache et cache CDN le cas échéant.

5. Désactivez le CCC. Si le panier fonctionne avec le CCC désactivé, une erreur de combinaison JavaScript en est la cause.

6. Testez avec le thème par défaut. Passez temporairement au thème classic par défaut de PrestaShop. Si le panier fonctionne avec le thème par défaut, le problème se trouve dans le JavaScript ou les templates de votre thème personnalisé.

7. Désactivez les modules tiers. Si le panier fonctionne avec tous les modules tiers désactivés, utilisez la méthode de recherche dichotomique pour identifier le module en conflit.

8. Vérifiez les logs d'erreurs PHP. Les erreurs côté serveur qui n'atteignent pas le navigateur sont enregistrées ici.

9. Vérifiez la configuration des cookies et des sessions. Vérifiez le cookie de session dans les DevTools et les paramètres de session PHP sur le serveur.

10. Testez sur un appareil et un réseau différents. Cela élimine les problèmes locaux du navigateur, les proxys réseau et les problèmes de compatibilité JavaScript spécifiques à l'appareil comme causes potentielles.

Lire la réponse complète

Pourquoi les logs d'erreurs PrestaShop sont importants

Chaque boutique PrestaShop génère des erreurs. Certaines sont des notices inoffensives qui n'affectent jamais vos clients. D'autres sont des défaillances critiques qui bloquent complètement votre processus de commande. La différence entre un propriétaire de boutique qui attend des jours l'aide du support et celui qui résout les problèmes en quelques minutes se résume souvent à une seule compétence : la lecture des logs d'erreurs.

Les logs d'erreurs sont la sortie de diagnostic de votre serveur et de votre application PrestaShop. Ils enregistrent chaque erreur PHP, chaque requête de base de données échouée, chaque problème de permission et chaque exception non interceptée. Quand quelque chose ne fonctionne pas, la réponse se trouve presque toujours dans un fichier de log. Le défi consiste à savoir où chercher, quoi chercher et comment interpréter ce que vous trouvez.

Ce guide couvre l'ensemble du paysage de la journalisation des erreurs dans PrestaShop. Vous apprendrez où se trouve chaque type de log, comment activer le rapport d'erreurs détaillé, comment lire les traces de pile (stack traces) et comment utiliser les outils en ligne de commande pour trouver l'aiguille dans la botte de foin. Que vous soyez en train de déboguer un écran blanc de la mort ou de traquer une erreur intermittente au moment du paiement, ce sont les connaissances dont vous avez besoin.

Où se trouvent les logs PrestaShop

PrestaShop génère des logs à plusieurs niveaux, et chaque niveau possède ses propres fichiers de logs. Comprendre quel log vérifier en premier vous fait gagner un temps considérable.

Logs applicatifs PrestaShop (var/logs)

À partir de PrestaShop 1.7, l'application utilise le framework Symfony pour son back office et le routage principal. Symfony écrit ses propres logs dans le répertoire var/logs/ situé à la racine de votre installation PrestaShop. Vous y trouverez des fichiers nommés selon l'environnement en cours :

var/logs/dev.log contient les logs lorsque PrestaShop fonctionne en mode développement. Ce fichier est extrêmement verbeux et enregistre tout, des décisions de routage aux requêtes de base de données. Il peut rapidement atteindre plusieurs centaines de mégaoctets.

var/logs/prod.log contient les logs du mode production. Ce fichier est beaucoup moins verbeux par défaut, n'enregistrant que les avertissements et les erreurs. C'est le fichier que vous devez vérifier en premier lorsque quelque chose ne fonctionne plus sur une boutique en ligne.

Ces fichiers de logs suivent le format Monolog, qui est la bibliothèque de journalisation standard de Symfony. Chaque ligne inclut un horodatage, le canal du log (comme request, security ou doctrine), le niveau de gravité et le message. Une entrée typique ressemble à ceci :

[2024-03-15 14:22:33] request.CRITICAL: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "No route found for GET /admin/nonexistent" at /var/www/html/vendor/symfony/http-kernel/EventListener/RouterListener.php line 136

Les niveaux de gravité, du moins au plus sévère, sont : DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT et EMERGENCY. Lors du dépannage, filtrez d'abord par ERROR et CRITICAL.

Log d'erreurs PHP

PHP lui-même maintient un log d'erreurs distinct des logs applicatifs de PrestaShop. Ce log capture les erreurs qui se produisent avant l'initialisation du framework de journalisation de PrestaShop, ou les erreurs dans du code qui n'utilise pas le logger Symfony. L'emplacement de ce fichier dépend de la configuration de votre serveur.

Sur la plupart des serveurs Linux avec Apache, le log d'erreurs PHP se trouve à /var/log/php_errors.log ou /var/log/php/error.log. Sur les hébergements mutualisés avec cPanel, il se trouve souvent à /home/username/logs/error.log ou dans le répertoire public_html sous le nom error_log.

Vous pouvez trouver l'emplacement exact en vérifiant la configuration PHP. Créez un fichier PHP temporaire avec phpinfo(); et recherchez la directive error_log. Alternativement, exécutez php -i | grep error_log depuis la ligne de commande.

Les logs d'erreurs PHP capturent les erreurs fatales, les erreurs d'analyse, les avertissements et les notices. Une entrée d'erreur fatale ressemble généralement à ceci :

[15-Mar-2024 14:22:33 UTC] PHP Fatal error: Uncaught Error: Class 'SomeModule\SomeClass' not found in /var/www/html/modules/somemodule/somemodule.php:45

Logs du serveur web (Apache et Nginx)

Votre serveur web maintient son propre ensemble de logs, indépendants de PHP et de PrestaShop. Ces logs sont essentiels pour diagnostiquer les erreurs 500, les erreurs 404 et les problèmes de performance.

Les logs Apache se trouvent généralement à :

/var/log/apache2/error.log pour le log d'erreurs sur les systèmes Debian et Ubuntu.
/var/log/httpd/error_log pour le log d'erreurs sur les systèmes CentOS et RHEL.
/var/log/apache2/access.log pour le log d'accès, qui enregistre chaque requête HTTP.

Les logs Nginx se trouvent généralement à :

/var/log/nginx/error.log pour le log d'erreurs.
/var/log/nginx/access.log pour le log d'accès.

Si votre site utilise une configuration de virtual host, les logs peuvent se trouver à un emplacement spécifique au site, défini par la directive ErrorLog (Apache) ou error_log (Nginx) dans le fichier de votre virtual host.

Les logs d'erreurs du serveur web capturent des problèmes tels que les erreurs de permission refusée lorsque PHP tente d'écrire dans un répertoire, les erreurs de syntaxe de configuration après une modification du .htaccess, et les erreurs de timeout de proxy si vous utilisez PHP-FPM derrière Nginx. Ce sont les logs à vérifier lorsque vous voyez une erreur générique 500 Internal Server Error sans détails dans les logs PHP ou PrestaShop.

Logs legacy PrestaShop (Back Office)

PrestaShop maintient également une visionneuse de logs dans le back office sous Paramètres avancés > Logs. Cette interface affiche les entrées de log stockées dans la table ps_log de la base de données. Ces logs capturent les événements que PrestaShop enregistre explicitement, tels que les tentatives de connexion échouées, les erreurs d'installation de modules et les échecs d'envoi d'emails.

Bien que la visionneuse de logs du back office soit pratique, elle présente des limitations significatives. Elle ne capture pas les erreurs PHP, les erreurs du serveur web ni la plupart des erreurs fatales qui empêchent le chargement de la page. Considérez-la comme un complément aux logs basés sur les fichiers, pas comme un remplacement.

Activer le mode debug dans PrestaShop

Par défaut, PrestaShop fonctionne en mode production et masque les messages d'erreur détaillés aux visiteurs. C'est correct pour une boutique en ligne, mais cela rend le débogage pratiquement impossible. Lorsque quelque chose ne fonctionne plus, votre première étape devrait être d'activer le mode debug.

Méthode 1 : le fichier defines.inc.php

Ouvrez le fichier config/defines.inc.php et recherchez la ligne qui définit _PS_MODE_DEV_. Changez la valeur de false à true :

define('_PS_MODE_DEV_', true);

Ce seul changement a plusieurs effets. Le rapport d'erreurs PHP est réglé à son niveau maximum, affichant toutes les erreurs, avertissements et notices. La mise en cache des templates Smarty est désactivée, donc les modifications de templates apparaissent immédiatement. La barre de profilage Symfony apparaît en bas des pages du back office. Et surtout, les détails des erreurs sont affichés à l'écran au lieu d'afficher une page d'erreur générique.

Méthode 2 : le mode profilage de debug

Pour une analyse plus approfondie, vous pouvez également activer le profilage. Dans le même fichier, définissez :

define('_PS_DEBUG_PROFILING_', true);

Cela ajoute des informations détaillées de temps d'exécution et d'utilisation mémoire en bas de chaque page, vous montrant quels hooks prennent le plus de temps, quels modules consomment le plus de mémoire et combien de requêtes de base de données chaque page génère. C'est inestimable pour le débogage de performances mais ne doit jamais être laissé activé en production.

Avertissement de sécurité

Le mode debug expose des informations sensibles, notamment les chemins de fichiers, les identifiants de base de données dans les traces de pile et la structure interne de l'application. Ne laissez jamais le mode debug activé sur une boutique en production accessible au public. Si vous devez déboguer une boutique en ligne, envisagez de restreindre le mode debug à votre adresse IP en enveloppant la définition dans une vérification d'IP, ou utilisez un environnement de staging.

Lire les traces de pile (stack traces)

Lorsque PrestaShop rencontre une erreur fatale ou une exception non interceptée en mode debug, il affiche une trace de pile. Une trace de pile est un instantané de la chaîne d'appels qui a conduit à l'erreur, depuis le point de défaillance jusqu'au point d'entrée initial. Apprendre à lire les traces de pile est la compétence de débogage la plus précieuse que vous puissiez développer.

Anatomie d'une trace de pile

Une trace de pile PrestaShop typique ressemble à ceci :

PHP Fatal error: Uncaught TypeError: Argument 1 passed to Product::getProductProperties() must be of the type int, null given, called in /var/www/html/classes/Product.php on line 4523

Stack trace: #0 /var/www/html/classes/Product.php(4523): Product::getProductProperties(NULL, Array) #1 /var/www/html/modules/somemodule/somemodule.php(127): Product::getProductProperties(1, Array) #2 /var/www/html/classes/Hook.php(523): SomeModule->hookDisplayHome(Array) #3 /var/www/html/classes/Hook.php(460): Hook::coreCallHook(Object(SomeModule), 'hookDisplayHome', Array) #4 /var/www/html/classes/Hook.php(408): Hook::exec('displayHome', Array)

Lisez la trace de pile de haut en bas. La première ligne vous indique ce qui s'est mal passé : une fonction attendait un entier mais a reçu null. La ligne #0 vous indique où l'erreur s'est produite. La ligne #1 vous indique ce qui a appelé le code à la ligne #0. La ligne #2 vous indique ce qui a appelé #1, et ainsi de suite.

Dans cet exemple, la chaîne est claire : PrestaShop a exécuté le hook displayHome, qui a appelé la méthode hookDisplayHome dans SomeModule, laquelle a appelé Product::getProductProperties() avec une valeur null là où un entier était attendu. Le bug se trouve dans le module à la ligne 127, où il transmet une valeur incorrecte.

Trouver le cadre pertinent

Les traces de pile dans PrestaShop peuvent être longues, parfois 20 ou 30 niveaux de profondeur. L'essentiel est de trouver le cadre qui contient votre code ou le module à l'origine du problème. Recherchez les chemins contenant /modules/ ou /themes/ car ce sont les sources les plus probables de bugs. Les cadres qui font référence à /classes/, /src/ ou /vendor/ correspondent au code principal de PrestaShop ou aux bibliothèques tierces, ce qui est moins susceptible d'être la source du problème, à moins que vous n'ayez modifié les fichiers du core.

Schémas d'erreurs courants dans PrestaShop

Après avoir lu des milliers de logs d'erreurs PrestaShop, certains schémas reviennent de manière récurrente. Reconnaître ces schémas vous permet de diagnostiquer les problèmes en quelques secondes au lieu de plusieurs heures.

Erreurs de classe introuvable

PHP Fatal error: Uncaught Error: Class 'ModuleName\ClassName' not found

Cela signifie que l'autoloader ne trouve pas la classe spécifiée. Les causes courantes incluent : un fichier vendor/autoload.php manquant (le module nécessite un composer install), une déclaration de namespace incorrecte, un fichier qui n'a pas été inclus dans le ZIP du module lors de l'installation, ou un problème de sensibilité à la casse sur les serveurs Linux où ClassName.php et classname.php sont des fichiers différents.

Erreurs de permission refusée

Warning: file_put_contents(/var/www/html/var/cache/prod/some_file): failed to open stream: Permission denied

Ces erreurs se produisent lorsque l'utilisateur du serveur web (généralement www-data sur Debian/Ubuntu ou apache sur CentOS) n'a pas les permissions d'écriture sur un fichier ou un répertoire. Corrigez cela en ajustant la propriété : chown -R www-data:www-data var/cache/ et les permissions : chmod -R 775 var/cache/.

Erreurs de limite mémoire

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes)

Le nombre 134217728 octets correspond à 128 Mo, qui est la limite mémoire PHP par défaut. PrestaShop recommande au moins 256 Mo. Augmentez-la dans votre fichier php.ini : memory_limit = 512M. Si l'erreur persiste même avec des limites mémoire élevées, le code comporte probablement une fuite mémoire, souvent causée par le chargement de trop de produits ou catégories dans une seule requête sans pagination.

Erreurs de connexion à la base de données

Link to database cannot be established: SQLSTATE[HY000] [2002] Connection refused

Cela signifie que PrestaShop ne parvient pas à se connecter au serveur MySQL. Vérifiez que le serveur de base de données fonctionne, que les identifiants dans app/config/parameters.php sont corrects et que l'hôte de la base de données est accessible depuis le serveur web.

Erreurs de templates Smarty

SmartyException: Unable to load template file 'module:somemodule/views/templates/hook/display.tpl'

Le fichier de template est manquant, mal orthographié ou dans le mauvais répertoire. Vérifiez que le fichier existe au chemin attendu et que le nom du fichier correspond exactement, y compris la casse.

Erreurs de jeton CSRF

Invalid token. Please try to log in again.

Cette erreur apparaît dans le back office lorsqu'une soumission de formulaire inclut un jeton de sécurité expiré ou manquant. Cela se produit généralement lorsqu'une session expire pendant une longue session d'édition, lorsque plusieurs onglets sont ouverts sur la même page d'administration, ou lorsqu'un module génère ses URL de formulaire de manière incorrecte.

Utiliser grep pour trouver des erreurs

Lorsque les fichiers de logs sont volumineux, les parcourir manuellement est peu pratique. La commande grep est votre meilleure alliée pour trouver rapidement les entrées pertinentes.

Recherche basique d'erreurs

Pour trouver toutes les erreurs fatales dans le log d'erreurs PHP :

grep 'Fatal error' /var/log/php_errors.log

Pour trouver les erreurs provenant d'un module spécifique :

grep 'somemodule' /var/www/html/var/logs/prod.log

Pour trouver uniquement les erreurs du jour (en supposant le format de date dans le log) :

grep '2024-03-15' /var/www/html/var/logs/prod.log | grep 'ERROR\|CRITICAL'

Filtrage avancé

Pour voir les erreurs avec le contexte environnant (3 lignes avant et après chaque correspondance) :

grep -C 3 'Fatal error' /var/log/php_errors.log

Pour compter combien de fois chaque erreur unique se produit :

grep 'Fatal error' /var/log/php_errors.log | sort | uniq -c | sort -rn | head -20

Ce pipeline trie les erreurs, compte les doublons, trie par nombre décroissant et affiche les 20 premières. C'est incroyablement utile pour identifier les erreurs les plus fréquentes nécessitant une attention prioritaire.

Pour rechercher dans plusieurs fichiers de logs simultanément :

grep -r 'Fatal error' /var/log/ --include='*.log'

L'option -r effectue une recherche récursive, et --include limite la recherche aux fichiers avec l'extension .log.

Surveillance en temps réel des logs avec tail -f

Lorsque vous déboguez activement un problème, vous devez voir les erreurs au moment où elles se produisent. La commande tail -f suit un fichier de log en temps réel, affichant les nouvelles entrées au fur et à mesure qu'elles sont écrites.

Surveillance basique en temps réel

Pour surveiller le log de production PrestaShop en temps réel :

tail -f /var/www/html/var/logs/prod.log

Pour surveiller le log d'erreurs PHP :

tail -f /var/log/php_errors.log

Pour surveiller plusieurs fichiers de logs en même temps :

tail -f /var/www/html/var/logs/prod.log /var/log/php_errors.log /var/log/apache2/error.log

Surveillance filtrée en temps réel

Pour ne voir que les entrées de niveau erreur en temps réel, combinez tail avec grep :

tail -f /var/www/html/var/logs/prod.log | grep --line-buffered 'ERROR\|CRITICAL'

L'option --line-buffered est importante ici. Sans elle, grep met sa sortie en tampon et vous risquez de ne pas voir les correspondances immédiatement.

Pour mettre en surbrillance des mots-clés spécifiques tout en affichant l'ensemble de la sortie :

tail -f /var/www/html/var/logs/prod.log | grep --color=always -E 'ERROR|CRITICAL|$'

Cela met en surbrillance ERROR et CRITICAL en couleur tout en continuant à afficher toutes les lignes.

Le workflow de débogage

Le workflow de débogage le plus efficace combine la surveillance en temps réel avec les tests actifs. Ouvrez une fenêtre de terminal avec tail -f en cours d'exécution sur les fichiers de logs pertinents. Dans votre navigateur, reproduisez l'action qui cause l'erreur. Observez le terminal pour voir les nouvelles entrées de log qui apparaissent au moment exact où vous déclenchez le problème. Cette approche élimine les conjectures et vous montre précisément ce qui se passe lorsque l'erreur survient.

Rotation et gestion des logs

Les fichiers de logs grossissent continuellement et peuvent consommer tout l'espace disque disponible s'ils ne sont pas gérés. La plupart des serveurs Linux utilisent logrotate pour gérer cela automatiquement, mais les propres logs de PrestaShop dans var/logs/ peuvent ne pas être inclus dans la configuration par défaut de logrotate.

Comprendre logrotate

L'utilitaire logrotate s'exécute quotidiennement (généralement via cron) et gère la rotation, la compression et la suppression des fichiers de logs. Les fichiers de configuration se trouvent dans /etc/logrotate.d/. La rotation des logs Apache et Nginx est généralement configurée par défaut.

Pour le répertoire var/logs de PrestaShop, vous devrez peut-être créer une configuration logrotate personnalisée :

/var/www/html/var/logs/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data www-data }

Cela effectue une rotation quotidienne des logs, conserve 14 jours d'historique, compresse les anciens logs et crée de nouveaux fichiers de logs avec les permissions correctes.

Nettoyage manuel des logs

Si un fichier de log est devenu extrêmement volumineux et que vous devez le vider sans perdre le descripteur de fichier (important si un processus est en train d'y écrire activement) :

truncate -s 0 /var/www/html/var/logs/prod.log

Ne supprimez pas le fichier pour le recréer, car tout processus ayant le fichier ouvert continuera d'écrire dans l'inode du fichier supprimé jusqu'à ce qu'il soit redémarré. L'approche par truncate vide le contenu tout en préservant l'inode.

Comprendre les contextes d'erreurs spécifiques à PrestaShop

Les erreurs PrestaShop sont souvent accompagnées d'un contexte unique à la plateforme. Comprendre ce contexte vous aide à localiser et corriger les problèmes plus rapidement.

Erreurs liées aux hooks

Lorsqu'une erreur se produit à l'intérieur d'un hook, la trace de pile inclura des références à Hook::exec() et Hook::coreCallHook(). Le nom du hook vous indique exactement à quel moment du processus de rendu de la page l'erreur se produit. Par exemple, les erreurs displayHome se produisent sur la page d'accueil, les erreurs actionValidateOrder se produisent pendant le processus de commande, et les erreurs displayBackOfficeHeader se produisent lors du chargement de n'importe quelle page du back office.

Si une erreur de hook fait planter une page, vous pouvez temporairement désactiver le module fautif depuis la base de données :

UPDATE ps_module SET active = 0 WHERE name = 'somemodule';

Cela vous permet d'accéder au back office pour diagnostiquer et corriger correctement le problème.

Conflits d'overrides

Le système d'overrides de PrestaShop permet aux modules d'étendre les classes du core, mais des conflits surviennent lorsque deux modules surchargent la même classe. L'erreur apparaît généralement sous forme de conflit de signature de méthode ou de changement de comportement inattendu. Vérifiez le répertoire override/ pour voir quels overrides sont actifs, et vérifiez le fichier cache/class_index.php qui mappe les classes vers leurs fichiers d'override. Supprimer ce fichier cache force PrestaShop à régénérer la carte des overrides.

Erreurs liées au cache

De nombreuses erreurs PrestaShop sont causées par des fichiers de cache obsolètes. Si vous voyez des erreurs qui ne correspondent pas au code actuel (par exemple, une erreur faisant référence à un numéro de ligne qui n'existe pas dans le fichier), le cache est probablement périmé. Videz-le en supprimant le contenu de var/cache/prod/ et var/cache/dev/. Sur PrestaShop 1.6, videz plutôt cache/smarty/compile/ et cache/smarty/cache/.

Erreurs d'installation et de mise à jour de modules

Les installations de modules peuvent échouer silencieusement, laissant le module dans un état partiellement installé. Vérifiez var/logs/prod.log pour les entrées correspondant à l'horodatage de l'installation. Les problèmes courants incluent les tables de base de données manquantes (le SQL de la méthode install() du module a échoué), les hooks manquants (l'appel registerHook() a échoué) et les erreurs d'entrée en double dans la table ps_authorization_role lors de la réinstallation d'un module qui n'a pas été complètement désinstallé.

Construire une checklist de débogage

Lorsque vous rencontrez une erreur PrestaShop, suivez cette checklist systématique pour trouver la cause efficacement :

Premièrement, identifiez le type d'erreur. S'agit-il d'un écran blanc (erreur 500), d'un message d'erreur spécifique, d'une mise en page cassée ou d'un comportement inattendu ? Chaque type pointe vers des fichiers de logs différents.

Deuxièmement, vérifiez d'abord le log le plus spécifique. Pour les erreurs PHP, vérifiez le log d'erreurs PHP. Pour les erreurs HTTP, vérifiez le log d'erreurs du serveur web. Pour les erreurs applicatives, vérifiez var/logs/prod.log.

Troisièmement, activez le mode debug si les logs ne révèlent pas suffisamment d'informations. Changez _PS_MODE_DEV_ à true et reproduisez l'erreur.

Quatrièmement, utilisez tail -f sur les logs pertinents et reproduisez l'erreur dans votre navigateur. Cela vous donne une vue en temps réel de ce qui se passe exactement.

Cinquièmement, lisez la trace de pile de haut en bas. Trouvez le cadre qui fait référence à votre module ou au code de votre thème. C'est là que le correctif doit être appliqué.

Sixièmement, recherchez le message d'erreur dans les issues GitHub de PrestaShop et sur les forums. Il y a de fortes chances que quelqu'un ait déjà rencontré et résolu le même problème auparavant.

Septièmement, après avoir appliqué un correctif, videz tous les caches et surveillez les logs pour confirmer que l'erreur a disparu. Un correctif qui ne produit pas un log propre n'est pas un correctif complet.

Résumé

Lire les logs d'erreurs PrestaShop n'est pas un art mystérieux réservé aux développeurs seniors. C'est une compétence pratique fondée sur le fait de savoir où vivent les logs, comment les filtrer et comment interpréter leur contenu. Les logs dans var/logs/, le log d'erreurs PHP et le log du serveur web remplissent chacun un rôle différent et, ensemble, vous donnent une image complète de tout problème. Activer le mode debug vous donne des messages d'erreur détaillés. Les traces de pile vous montrent la chaîne exacte des appels de fonctions qui a conduit à la défaillance. Des outils comme grep et tail -f permettent de trouver et surveiller les erreurs efficacement, même dans des fichiers de logs volumineux et très sollicités. Maîtrisez ces techniques et vous résoudrez les problèmes plus rapidement, avec moins de frustration et beaucoup moins de dépendance au support externe.

Lire la réponse complète

Comprendre les codes d'erreur HTTP dans PrestaShop

Les codes d'erreur HTTP sont des réponses standardisées de votre serveur web qui indiquent qu'un problème s'est produit lorsqu'un navigateur ou un bot de moteur de recherche a tenté d'accéder à une page. Pour les propriétaires de boutiques PrestaShop, ces erreurs peuvent signifier des ventes perdues, des clients frustrés et des classements SEO endommagés.

Erreur 403 - Interdit

Une erreur 403 signifie que le serveur a compris votre requête mais refuse de l'autoriser. C'est typiquement un problème de permissions ou de contrôle d'accès.

1. Permissions de fichiers et répertoires incorrectes

Les répertoires doivent être à 755 et les fichiers à 644.

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/prestashop

2. Règles .htaccess bloquant l'accès

Un fichier .htaccess trop restrictif peut bloquer des requêtes légitimes.

3. ModSecurity ou WAF bloquant des requêtes

Les pare-feu d'applications web peuvent produire des faux positifs.

Corriger les erreurs 403

Vérifier et corriger les permissions des fichiers
Examiner le .htaccess pour les règles trop restrictives
Vérifier les journaux de sécurité de l'hébergement
Vérifier que votre IP n'est pas bloquée

Erreur 404 - Non trouvé

Une erreur 404 signifie que le serveur ne peut pas trouver la page demandée.

1. URLs amicales désactivées ou mal configurées

Allez dans Paramètres de la boutique > Trafic & SEO, assurez-vous que les URLs amicales sont activées et cliquez sur Enregistrer. Vérifiez que mod_rewrite est activé sur votre serveur.

2. Produits ou catégories supprimés sans redirections

Configurez toujours des redirections 301 lors de la suppression de contenu.

3. .htaccess manquant ou corrompu

Régénérez le .htaccess depuis Paramètres de la boutique > Trafic & SEO.

Corriger les erreurs 404

Vérifier que le .htaccess existe et est correctement configuré
Vérifier que mod_rewrite est activé
Régénérer le .htaccess
Configurer des redirections 301
Vérifier Google Search Console pour les erreurs de crawl

Erreur 500 - Erreur interne du serveur

Une erreur 500 signifie que quelque chose a mal tourné côté serveur.

1. Limite de mémoire PHP dépassée

memory_limit = 512M

2. Erreurs de syntaxe PHP ou erreurs fatales

define('_PS_MODE_DEV_', true);

3. Incompatibilité de version PHP

PrestaShop	PHP Minimum	PHP Recommandé
1.7.x	7.1	7.4
8.x	7.2	8.1
9.x	8.1	8.2+

4. Problèmes de connexion à la base de données

Vérifiez les identifiants dans app/config/parameters.php.

5. Conflits de modules

mv modules/problematic_module modules/problematic_module_disabled

Corriger les erreurs 500

Activer le mode débogage
Vérifier le journal d'erreurs PHP
Augmenter la limite de mémoire PHP
Vérifier la compatibilité de version PHP
Désactiver les modules récemment installés

Erreur 503 - Service indisponible

Une erreur 503 signifie que le serveur est temporairement incapable de traiter la requête.

1. Mode maintenance encore actif

UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SHOP_ENABLE';

2. Surcharge du serveur

Mettre à niveau l'hébergement
Activer la mise en cache PrestaShop
Utiliser un CDN comme Cloudflare
Activer OPcache pour PHP

3. Épuisement des workers PHP-FPM

pm = dynamic
pm.max_children = 50
pm.start_servers = 10

Corriger les erreurs 503

Vérifier et désactiver le mode maintenance
Surveiller les ressources du serveur
Vérifier les journaux PHP-FPM
Revoir la planification des tâches cron
Envisager un hébergement plus performant

Conseils de débogage généraux

Vérifier les journaux du serveur

Apache - /var/log/apache2/error.log
Nginx - /var/log/nginx/error.log
PHP-FPM - /var/log/php-fpm/error.log
PrestaShop - /var/logs/

Vider tous les caches

Après chaque correction, vider tous les caches pour s'assurer que PrestaShop charge les données correctes.

Lire la réponse complète

Comment PrestaShop utilise les cookies

Chaque boutique PrestaShop dépend des cookies pour fonctionner. Ils maintiennent les sessions clients, mémorisent le contenu du panier, stockent les préférences de langue et de devise, suivent l'état de connexion et permettent au back-office d'authentifier les administrateurs. Sans cookies, une boutique PrestaShop ne peut pas maintenir l'état entre les chargements de pages, ce qui signifie pas de panier, pas de connexion client et pas d'accès administrateur.

PrestaShop utilise deux cookies principaux. Le cookie du front-office, généralement nommé d'après votre boutique (comme PrestaShop-abc123), gère tout ce dont le côté client a besoin. Le cookie du back-office, avec un modèle de nommage similaire mais une portée différente, gère l'authentification des administrateurs. Les deux cookies stockent des données sérialisées directement dans la valeur du cookie, ce qui est une décision de conception ayant des implications significatives pour les performances, la sécurité et la conformité RGPD.

Structure et contenu du cookie PrestaShop

Contrairement à de nombreuses applications web qui ne stockent qu'un identifiant de session dans le cookie et conservent toutes les données de session sur le serveur, PrestaShop stocke des données substantielles directement dans le cookie lui-même. Le cookie du front-office contient des champs incluant l'identifiant client, le nom et l'email du client, si le client est connecté, l'identifiant du panier, la langue sélectionnée, la devise sélectionnée, la dernière catégorie visitée, le dernier produit visité, l'étape du processus de commande et diverses autres informations d'état.

Ces données sont sérialisées en utilisant la classe cookie propre à PrestaShop (Cookie.php dans le répertoire classes). La valeur du cookie est chiffrée à l'aide d'une clé dérivée de votre constante _COOKIE_KEY_ dans config/settings.inc.php (PrestaShop 1.6/1.7) ou app/config/parameters.php (PrestaShop 8.x). Ce chiffrement empêche la falsification et protège les données sensibles comme l'identifiant client et l'email d'être lisibles dans le navigateur.

Pourquoi PrestaShop stocke les données dans le cookie

La raison historique de cette conception est la performance. En stockant les données de session dans le cookie, PrestaShop évite une recherche de session côté serveur à chaque requête. Il n'est pas nécessaire de lire un fichier de session, d'interroger une base de données ou de se connecter à un serveur de sessions. Les données arrivent avec la requête, déjà disponibles.

Cependant, cette approche présente des inconvénients qui deviennent plus pertinents à mesure que les boutiques grandissent. La taille du cookie augmente avec la quantité de données stockées, et chaque requête HTTP (y compris les requêtes pour les images, CSS et fichiers JavaScript) envoie le cookie complet au serveur. Un cookie de 4 Ko envoyé avec 30 requêtes de ressources par page signifie 120 Ko de bande passante de téléchargement inutile par chargement de page. Cette surcharge est mesurable sur les connexions mobiles et à grande échelle.

Taille des cookies et impact sur les performances

Les cookies de navigateur ont une limite de taille pratique d'environ 4 096 octets par cookie. Le cookie du front-office de PrestaShop peut approcher ou dépasser cette limite, surtout lorsque des modules ajoutent leurs propres données au cookie via le hookActionBeforeSubmitAccount ou en modifiant directement l'objet cookie.

Mesurer l'impact de la taille des cookies

Pour voir comment les cookies affectent les performances de votre boutique, ouvrez les outils de développement de votre navigateur et allez à l'onglet Réseau. Regardez les en-têtes de requête pour n'importe quelle requête vers votre domaine. L'en-tête Cookie montre tous les cookies envoyés. Notez sa taille. Regardez maintenant les en-têtes de requête pour une ressource statique (une image ou un fichier CSS) sur le même domaine. Les mêmes cookies sont envoyés avec cette requête aussi, ajoutant une surcharge sans raison.

Réduire la surcharge des cookies pour les ressources statiques

Le moyen le plus efficace d'éliminer la surcharge des cookies pour les fichiers statiques est de les servir depuis un domaine différent (un domaine sans cookies). Dans PrestaShop, vous pouvez configurer des serveurs de médias dans le back-office sous Paramètres avancés > Performances. Lorsque vous configurez un serveur de médias comme static.votredomaine.fr, PrestaShop sert les images, CSS et JavaScript depuis ce domaine. Comme les cookies sont spécifiques au domaine, aucun cookie n'est envoyé avec les requêtes vers le domaine média.

Alternativement, un CDN comme Cloudflare, Fastly ou CloudFront peut servir vos ressources statiques. Les serveurs edge CDN suppriment généralement les cookies des réponses mises en cache, de sorte que même si des cookies sont envoyés dans la requête, la réponse provient du cache sans la surcharge d'un aller-retour vers votre serveur d'origine.

Gonflement des cookies par les modules

Les modules tiers ajoutent parfois des données au cookie PrestaShop sans considérer les implications de taille. Chaque module qui stocke une valeur dans le cookie augmente sa taille et la surcharge sur chaque requête. Si votre cookie est anormalement volumineux, vérifiez quelles données les modules ont ajoutées en examinant le contenu déchiffré du cookie ou en examinant le code du module pour les appels à $this->context->cookie->mymodule_value = ....

Les modules bien conçus utilisent un stockage côté serveur (base de données ou cache) et ne stockent au plus qu'un petit identifiant dans le cookie. Les modules mal conçus déversent des structures de données complètes dans le cookie, gonflant sa taille. Si vous identifiez un module problématique, contactez le développeur ou remplacez le stockage par cookie par un stockage en base de données utilisant un identifiant de session.

Gestion des sessions : fichiers, base de données et Redis

Bien que PrestaShop stocke certaines données directement dans les cookies, PHP maintient également son propre système de sessions. Le back-office de PrestaShop repose plus lourdement sur les sessions PHP que le front-office. Le gestionnaire de sessions détermine où les données de session sont stockées côté serveur.

Sessions basées sur les fichiers (par défaut)

Par défaut, PHP stocke les sessions sous forme de fichiers dans le répertoire session.save_path (typiquement /tmp ou /var/lib/php/sessions). Chaque session crée un fichier. Pour une boutique avec des milliers de sessions actives, cela signifie des milliers de petits fichiers. Les sessions basées sur les fichiers fonctionnent bien pour les petites et moyennes boutiques mais peuvent causer des problèmes à grande échelle.

Les problèmes courants avec les sessions basées sur les fichiers comprennent un ramassage de sessions lent lorsque le répertoire de sessions contient trop de fichiers, le verrouillage de fichiers pouvant causer une sérialisation des requêtes (deux requêtes de la même session ne peuvent pas être traitées simultanément), et les environnements d'hébergement mutualisé où le répertoire de sessions se remplit ou a des permissions restrictives.

Sessions en base de données

PrestaShop prend en charge le stockage des sessions dans la base de données. Cela se configure dans les paramètres PHP ou via le gestionnaire de sessions de PrestaShop. Les sessions en base de données éliminent les problèmes de système de fichiers mais ajoutent une requête de base de données à chaque requête. Pour les boutiques avec une charge de base de données déjà élevée, cela peut aggraver les performances. Cependant, les sessions en base de données ont l'avantage d'être partagées entre plusieurs serveurs web dans une configuration à répartition de charge.

Sessions Redis ou Memcached

Pour les boutiques PrestaShop à fort trafic, Redis est le backend de stockage de sessions optimal. Redis stocke les données de session en mémoire, offrant des temps d'accès inférieurs à la milliseconde. Il prend en charge l'expiration automatique (délai d'expiration de session), et les données de session sont partagées entre toutes les instances de serveur web.

Pour configurer PHP afin d'utiliser Redis pour les sessions, définissez session.save_handler = redis et session.save_path = "tcp://127.0.0.1:6379" dans votre php.ini ou configuration du pool PHP-FPM. Si votre instance Redis nécessite une authentification, ajoutez le mot de passe au chemin de sauvegarde : "tcp://127.0.0.1:6379?auth=votremotdepasse".

PrestaShop prend déjà en charge Redis pour le cache d'objets (configuré dans le back-office sous Paramètres avancés > Performances). Utiliser la même instance Redis pour les sessions et le cache d'objets simplifie votre infrastructure tout en offrant d'excellentes performances pour les deux.

Attributs SameSite, Secure et HttpOnly

Les navigateurs modernes appliquent des attributs de sécurité des cookies qui affectent directement le comportement des cookies PrestaShop. Des attributs de cookies mal configurés provoquent des échecs de connexion, des paniers perdus et des erreurs de traitement de paiement.

Attribut SameSite

L'attribut SameSite contrôle si un cookie est envoyé avec les requêtes inter-sites. Il a trois valeurs possibles :

SameSite=Strict signifie que le cookie n'est jamais envoyé avec les requêtes inter-sites. C'est trop restrictif pour PrestaShop car les clients qui cliquent sur un lien vers votre boutique depuis un email ou un post sur les réseaux sociaux n'auraient pas leur cookie de session envoyé, les déconnectant effectivement.

SameSite=Lax est la valeur par défaut dans les navigateurs modernes. Le cookie est envoyé avec les navigations de niveau supérieur (clic sur un lien) mais pas avec les sous-requêtes inter-sites (images, iframes, AJAX). Cela fonctionne bien pour le cookie du front-office de PrestaShop dans la plupart des cas.

SameSite=None signifie que le cookie est toujours envoyé, y compris avec les requêtes inter-sites. Cela doit être associé à l'attribut Secure. C'est nécessaire lorsque votre boutique est intégrée dans un iframe sur un autre site ou lorsque des passerelles de paiement tierces doivent rediriger vers votre boutique avec la session intacte.

Problèmes de passerelle de paiement

De nombreux problèmes de paiement PrestaShop sont causés par des problèmes de cookies SameSite. Le scénario typique est : un client passe à la caisse, est redirigé vers le site de la passerelle de paiement, termine le paiement et est redirigé vers votre boutique. Si le cookie de session a SameSite=Lax, il peut ne pas être envoyé lors de la redirection depuis la passerelle de paiement, selon la façon dont la redirection est implémentée. Si la passerelle utilise une redirection POST (courante avec 3D Secure), la politique Lax bloque le cookie et PrestaShop perd la session. Le client voit un panier vide ou une page d'erreur générique au lieu de la confirmation de commande.

La solution est de définir le cookie PrestaShop sur SameSite=None; Secure. Dans PrestaShop 1.7.7+ et 8.x, cela peut être configuré dans les paramètres de cookies. Pour les versions plus anciennes, vous devrez peut-être modifier la classe Cookie ou ajouter des en-têtes via la configuration de votre serveur web. Testez toujours les flux de paiement après avoir modifié les paramètres SameSite.

Attribut Secure

L'attribut Secure garantit que le cookie n'est envoyé que sur des connexions HTTPS. Si votre boutique fonctionne en HTTPS (ce qui devrait être le cas), cet attribut empêche le cookie d'être transmis sur une connexion non chiffrée, le protégeant de l'interception. PrestaShop définit cet attribut lorsque la boutique détecte une connexion HTTPS.

Un problème courant survient avec les configurations HTTP/HTTPS mixtes. Si votre back-office est en HTTPS mais que certaines pages du front-office sont en HTTP, les cookies marqués comme Secure ne seront pas envoyés sur les pages HTTP, cassant la session. La solution est d'imposer HTTPS partout, ce que vous devriez faire de toute façon pour des raisons de sécurité et de SEO.

Attribut HttpOnly

L'attribut HttpOnly empêche JavaScript d'accéder au cookie via document.cookie. C'est une mesure de sécurité critique contre les attaques de type cross-site scripting (XSS). Si un attaquant injecte du JavaScript malveillant dans votre boutique (via un module vulnérable, par exemple), l'attribut HttpOnly empêche ce code de voler les cookies de session.

PrestaShop définit le flag HttpOnly sur ses cookies par défaut. Ne le désactivez pas sauf si vous avez une raison très spécifique et que vous comprenez les implications de sécurité.

Débogage des problèmes de session et de cookies

Les problèmes de cookies et de sessions se manifestent par des symptômes mystérieux : clients déconnectés aléatoirement, paniers qui se vident tout seuls, sessions admin qui expirent immédiatement, processus de commande qui échouent silencieusement. Un débogage systématique nécessite de vérifier plusieurs couches.

Outils de développement du navigateur

Ouvrez l'onglet Application (Chrome) ou Stockage (Firefox) et naviguez vers Cookies. Trouvez le domaine de votre boutique et examinez tous les cookies. Vérifiez les colonnes Nom, Valeur, Domaine, Chemin, Expiration, Taille, HttpOnly, Secure et SameSite. Recherchez les cookies anormalement volumineux, ceux ayant des paramètres de domaine incorrects (un cookie pour www.exemple.fr ne sera pas envoyé à exemple.fr), ou ceux auxquels manquent des attributs de sécurité.

Vérification des sessions côté serveur

Si les sessions sont stockées dans des fichiers, vérifiez le répertoire de sessions pour la présence et l'âge des fichiers de session. Si un client signale avoir été déconnecté, trouvez son fichier de session (le nom de fichier est l'identifiant de session du cookie PHPSESSID) et vérifiez quand il a été modifié pour la dernière fois. Si le fichier est manquant, la session a été soit nettoyée par le ramassage, soit jamais créée correctement.

Pour les sessions Redis, utilisez redis-cli pour vérifier si la clé de session existe : EXISTS PHPREDIS_SESSION:session_id. Vérifiez le TTL pour voir s'il est sur le point d'expirer : TTL PHPREDIS_SESSION:session_id.

Causes courantes de déconnexions aléatoires

Le _COOKIE_KEY_ a changé. Si cette clé change (lors d'un déploiement mal configuré, d'un écrasement du fichier de paramètres ou d'une mise à jour), tous les cookies existants deviennent illisibles car ils ont été chiffrés avec l'ancienne clé. Chaque client est effectivement déconnecté. La solution est de restaurer la clé originale depuis une sauvegarde.

Le ramassage des sessions est trop agressif. La valeur session.gc_maxlifetime de PHP détermine combien de temps (en secondes) un fichier de session est considéré comme valide. Si cette valeur est trop basse (la valeur par défaut est 1440 secondes, soit 24 minutes), les sessions des clients qui naviguent lentement sont supprimées. Pour une boutique, définissez cette valeur à au moins 3600 (1 heure) ou plus.

Répartiteur de charge sans affinité de session. Si votre boutique fonctionne sur plusieurs serveurs web derrière un répartiteur de charge et que les sessions sont stockées dans des fichiers, chaque serveur a son propre répertoire de sessions. Un client dont les requêtes alternent entre les serveurs perdra sa session à chaque changement. La solution est soit l'affinité de session (sessions persistantes) sur le répartiteur de charge, soit un stockage de session partagé via Redis ou une base de données.

Incompatibilité de domaine de cookie. Si votre boutique est accessible à la fois sur www.exemple.fr et exemple.fr, mais que le domaine du cookie est défini sur www.exemple.fr, les clients qui accèdent au site sans le préfixe www n'auront pas le cookie. Assurez une utilisation cohérente du domaine avec une redirection et vérifiez le domaine du cookie dans les paramètres de PrestaShop.

Conformité cookies et RGPD

Le Règlement Général sur la Protection des Données (RGPD) et la directive ePrivacy exigent un consentement éclairé avant de placer des cookies non essentiels sur le navigateur d'un utilisateur. Les boutiques PrestaShop doivent se conformer à ces réglementations, et le non-respect peut entraîner des amendes significatives.

Cookies essentiels vs non essentiels

Le RGPD distingue les cookies strictement nécessaires au fonctionnement du site web et les cookies servant d'autres objectifs comme l'analyse, le marketing ou la personnalisation. Le cookie de session de PrestaShop est essentiel car la boutique ne peut pas fonctionner sans. Un client ne peut pas ajouter de produits au panier ni effectuer un achat sans cookie de session. Les cookies essentiels ne nécessitent pas de consentement en vertu du RGPD.

Cependant, de nombreux autres cookies couramment trouvés sur les boutiques PrestaShop sont non essentiels et nécessitent un consentement explicite avant d'être placés. Ceux-ci incluent les cookies de suivi Google Analytics (_ga, _gid), les cookies du pixel Facebook, les cookies publicitaires des plateformes de remarketing, les cookies de widgets de chat en direct, les cookies de boutons de partage sur les réseaux sociaux et tous les cookies placés par des modules tiers à des fins de suivi ou de personnalisation.

Implémentation du consentement aux cookies

PrestaShop n'inclut pas de mécanisme de consentement aux cookies intégré répondant aux exigences du RGPD. Vous avez besoin soit d'un module PrestaShop conçu pour le consentement aux cookies, soit d'une intégration avec une plateforme de gestion du consentement (CMP) comme Cookiebot, Osano ou Usercentrics.

Une implémentation correcte du consentement aux cookies doit présenter un choix clair à l'utilisateur avant que tout cookie non essentiel ne soit placé. Elle doit permettre à l'utilisateur d'accepter ou de refuser des catégories individuelles de cookies (analyse, marketing, etc.), et pas seulement offrir un choix tout ou rien. Elle doit mémoriser le choix de l'utilisateur et ne pas redemander jusqu'à l'expiration du consentement. Et elle doit effectivement empêcher les cookies bloqués d'être placés, pas simplement enregistrer la préférence tout en continuant à charger les codes de suivi.

Ce dernier point est critique et souvent mal géré. Une bannière de consentement qui s'affiche mais charge Google Analytics de toute façon, quelle que soit la décision de l'utilisateur, n'offre aucune protection juridique. L'implémentation doit charger conditionnellement les ressources de suivi et de marketing en fonction du consentement de l'utilisateur.

Implémentation technique du consentement

L'approche technique de la gestion des cookies basée sur le consentement consiste à envelopper le code non essentiel dans des vérifications de consentement. Pour le JavaScript en ligne qui place des cookies ou charge des pixels de suivi, l'exécution directe est remplacée par un chargeur conditionné au consentement. Le code de suivi est stocké mais pas exécuté tant que l'utilisateur ne donne pas son consentement.

Pour les modules tiers qui placent des cookies, l'implémentation est plus complexe. Certains modules fournissent des hooks ou des options de configuration pour l'intégration du consentement. D'autres chargent leurs cookies sans condition et doivent être modifiés ou remplacés. Auditez chaque module de votre boutique pour l'utilisation de cookies et déterminez lesquels placent des cookies non essentiels.

Consentement aux cookies et mise en cache

La mise en cache de pages complètes crée un conflit avec le consentement aux cookies. Si une page est mise en cache avec Google Analytics chargé et servie à un utilisateur qui n'a pas donné son consentement, vous violez le RGPD. Il existe deux approches pour gérer cela.

La première approche consiste à mettre en cache la page sans aucune ressource non essentielle et à les injecter dynamiquement via JavaScript après vérification du consentement. Cela fonctionne bien avec le système CCC (Combine, Compress, Cache) de PrestaShop et avec Varnish ou d'autres caches reverse proxy.

La deuxième approche consiste à ne pas mettre en cache les pages pour les utilisateurs qui n'ont pas encore fait de choix de consentement (premiers visiteurs). Cela nuit aux performances pour les nouveaux visiteurs mais assure la conformité. La plupart des plateformes de gestion du consentement utilisent la première approche car elle préserve les avantages de la mise en cache.

Préoccupations de sécurité liées aux cookies

Au-delà des attributs HttpOnly et Secure déjà abordés, il existe des considérations de sécurité supplémentaires pour les cookies PrestaShop.

Vol de cookies et détournement de session

Si un attaquant obtient un cookie de session PrestaShop valide, il peut usurper l'identité du client ou de l'administrateur. La protection principale est HTTPS partout (empêche l'interception), les cookies HttpOnly (empêchent le vol par XSS) et l'attribut Secure (empêche la transmission via HTTP). PrestaShop lie également les sessions aux adresses IP dans certaines configurations, ce qui fournit une couche de protection supplémentaire mais peut causer des problèmes pour les utilisateurs dont l'adresse IP change (utilisateurs mobiles, utilisateurs VPN).

Sécurité de la clé de cookie

Le _COOKIE_KEY_ dans votre configuration PrestaShop est la clé maîtresse pour le chiffrement des cookies. Si cette clé est compromise, un attaquant peut déchiffrer tout cookie PrestaShop et forger des cookies de session valides. Protégez cette clé en restreignant l'accès à vos fichiers de configuration, en ne la committant jamais dans des dépôts publics et en ne la partageant jamais dans des demandes de support.

Prévention de la fixation de cookie

Les attaques par fixation de session impliquent qu'un attaquant définisse un identifiant de session connu dans le navigateur de la victime avant que celle-ci ne se connecte. Lorsque la victime se connecte, l'identifiant de session prédéfini par l'attaquant devient authentifié. PrestaShop atténue ce risque en régénérant l'identifiant de session lors de la connexion. Assurez-vous que la régénération de l'identifiant de session fonctionne correctement et n'a pas été désactivée par un module ou une modification de configuration.

Résolution des problèmes courants de cookies

Boucle de connexion du panneau d'administration

Le symptôme est de saisir des identifiants valides dans le back-office PrestaShop, de voir brièvement le tableau de bord et d'être redirigé vers la page de connexion. C'est presque toujours un problème de cookie. Vérifiez que le domaine du cookie est correct, que le nom du répertoire admin n'a pas changé, que HTTPS est correctement configuré (le contenu mixte peut empêcher l'envoi du cookie Secure), et que le répertoire de stockage des sessions est accessible en écriture par le serveur web.

Panier qui se vide lors de la navigation

Si le panier se vide lorsque le client navigue vers une autre page, le cookie de session n'est pas maintenu. Les causes courantes incluent un paramètre de domaine de cookie manquant ou incorrect, un session.cookie_lifetime mal configuré dans PHP (la valeur 0 signifie que le cookie expire à la fermeture du navigateur, ce qui est correct, mais certaines configurations le définissent à un temps très court), ou un CDN ou une couche de mise en cache qui supprime l'en-tête Set-Cookie des réponses.

Échec du paiement après la commande

Lorsque les clients terminent le paiement mais voient une erreur ou un panier vide au retour vers votre boutique, la politique de cookies SameSite est généralement la cause, comme décrit dans la section sur les passerelles de paiement ci-dessus. Testez le flux complet de commande avec les outils de développement du navigateur ouverts, en surveillant les cookies à chaque étape pour identifier où la session est perdue.

Plusieurs boutiques sur le même domaine

Si vous exécutez plusieurs installations PrestaShop sur le même domaine (par exemple, dans des sous-répertoires), leurs cookies peuvent entrer en conflit. Chaque installation utilise un nom de cookie similaire, et si le chemin du cookie est défini sur /, le cookie d'une boutique écrase celui de l'autre. Définissez des noms de cookies uniques pour chaque installation via le _COOKIE_KEY_ (qui affecte le nom du cookie) ou configurez le chemin du cookie pour correspondre au sous-répertoire de chaque installation.

Optimisation de la configuration des cookies pour les performances

Une configuration de cookies PrestaShop bien optimisée minimise la surcharge tout en maintenant la fonctionnalité. Utilisez un domaine sans cookies ou un CDN pour les ressources statiques afin d'éviter d'envoyer des cookies avec les requêtes d'images, CSS et JavaScript. Gardez la taille des cookies petite en empêchant les modules de stocker des données inutiles. Définissez des délais d'expiration de session appropriés qui équilibrent la sécurité (plus court est plus sûr) avec l'expérience utilisateur (plus long signifie moins de reconnexions). Utilisez Redis pour le stockage des sessions pour combiner un accès rapide avec un état partagé entre les instances de serveur. Activez les attributs Secure et HttpOnly pour protéger l'intégrité des cookies sans affecter les performances. Implémentez un consentement aux cookies approprié pour éviter de charger des cookies de suivi inutiles qui ajoutent de la surcharge et du risque juridique.

Chacune de ces optimisations est petite individuellement, mais ensemble elles créent une amélioration significative tant des performances que de la conformité. La gestion des cookies n'est pas un travail glamour, mais elle sous-tend chaque interaction entre votre boutique et vos clients, ce qui mérite qu'on s'en occupe correctement.

Lire la réponse complète

Pourquoi les performances de la base de données sont importantes dans PrestaShop

PrestaShop est une application gourmande en base de données. Chaque page produit, liste de catégorie, résultat de recherche, mise à jour du panier et étape de commande implique de multiples requêtes de base de données. Une page produit typique peut générer de 50 à 200 requêtes SQL ou plus, selon le nombre de modules installés, la complexité du produit (combinaisons, caractéristiques, pièces jointes) et le thème. Lorsque l'une de ces requêtes s'exécute lentement, la page entière ralentit, et l'effet se multiplie sous charge.

Le défi est d'identifier quelles requêtes sont réellement lentes. Avec des centaines de requêtes par chargement de page, vous ne pouvez pas simplement deviner. Vous avez besoin de données. Le journal des requêtes lentes MySQL est l'outil le plus direct et le plus fiable pour collecter ces données. Il enregistre chaque requête dépassant un seuil de temps que vous définissez, vous donnant une image claire de l'endroit où votre base de données passe le plus de temps.

Ce guide couvre comment activer et configurer le journal des requêtes lentes, comment analyser les résultats, comment interpréter les plans d'exécution de requêtes et comment appliquer les optimisations les plus courantes pour les bases de données PrestaShop.

Activer le journal des requêtes lentes

Le journal des requêtes lentes est une fonctionnalité MySQL qui écrit dans un fichier journal les requêtes dépassant un temps d'exécution spécifié. Il est désactivé par défaut sur la plupart des installations car il ajoute une petite surcharge d'E/S, mais le coût en performances est négligeable comparé à la valeur diagnostique qu'il fournit.

Configuration via my.cnf

Pour activer le journal des requêtes lentes de façon permanente, ajoutez les lignes suivantes à votre fichier de configuration MySQL. Sur la plupart des systèmes Linux, ce fichier se trouve à /etc/mysql/my.cnf, /etc/my.cnf ou dans un répertoire comme /etc/mysql/conf.d/ :

slow_query_log = 1 active la fonctionnalité.

slow_query_log_file = /var/log/mysql/slow-query.log spécifie où le journal est écrit. Assurez-vous que le processus MySQL a les permissions d'écriture sur ce répertoire.

long_query_time = 1 définit le seuil en secondes. Toute requête prenant plus de temps que cette valeur est journalisée. Commencez à 1 seconde pour attraper les pires contrevenants, puis descendez à 0,5 ou même 0,1 seconde à mesure que vous optimisez les pires requêtes et voulez trouver des goulots d'étranglement plus subtils.

log_queries_not_using_indexes = 1 journalise les requêtes n'utilisant aucun index, quelle que soit leur durée. C'est extrêmement utile pour PrestaShop car de nombreux problèmes de performance sont causés par des scans complets de tables sur de grandes tables. Cependant, cela peut générer beaucoup d'entrées de journal sur une boutique active, donc vous voudrez peut-être l'activer temporairement pendant l'analyse et le désactiver après.

Après avoir édité le fichier de configuration, redémarrez MySQL pour que les changements prennent effet.

Activation en cours d'exécution

Vous pouvez également activer le journal des requêtes lentes sans redémarrer MySQL en exécutant des commandes SQL. Connectez-vous à MySQL en tant que root et exécutez :

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

SET GLOBAL log_queries_not_using_indexes = 1;

Les changements en cours d'exécution prennent effet immédiatement mais ne persistent pas après un redémarrage de MySQL. Cette approche est utile pour des sessions d'analyse temporaires où vous voulez collecter des données pendant une période spécifique puis désactiver la journalisation.

Choisir le bon seuil

La valeur de long_query_time détermine ce qui est journalisé. Un seuil trop élevé signifie que vous manquez des requêtes modérément lentes qui impactent collectivement les performances. Un seuil trop bas inonde le journal d'entrées qui ne sont pas individuellement problématiques.

Pour une analyse initiale, commencez à 1 seconde. Cela capture les requêtes clairement trop lentes. Après les avoir optimisées, abaissez le seuil à 0,5 seconde, puis 0,2 seconde. Sur une base de données PrestaShop bien optimisée, l'objectif est qu'aucune requête ne prenne plus de 0,1 seconde, mais atteindre ce niveau nécessite un travail d'optimisation significatif.

Gardez à l'esprit que le temps d'exécution des requêtes varie avec la charge du serveur. Une requête qui prend 0,3 seconde sous charge normale peut prendre 2 secondes pendant un pic de trafic en raison de la contention CPU, des goulots d'étranglement d'E/S disque ou de la contention de verrouillage. Le journal des requêtes lentes capture les temps d'exécution réels, donc l'analyse des journaux des périodes de trafic de pointe vous donne l'image la plus réaliste.

Analyser le journal des requêtes lentes

Le journal brut des requêtes lentes est un fichier texte avec des entrées qui ressemblent à ceci :

# Time: 2024-03-15T14:22:33.456789Z
# User@Host: prestashop[prestashop] @ localhost []
# Query_time: 3.456123 Lock_time: 0.000234 Rows_sent: 1 Rows_examined: 847293
SET timestamp=1710511353;
SELECT * FROM ps_product WHERE active = 1 AND id_product NOT IN (SELECT id_product FROM ps_category_product WHERE id_category = 2);

Les champs clés sont Query_time (combien de temps la requête a pris), Lock_time (combien de temps elle a attendu un verrou), Rows_sent (combien de lignes ont été retournées) et Rows_examined (combien de lignes MySQL a dû examiner pour trouver le résultat). Une requête qui examine 847 293 lignes pour retourner 1 ligne est un signe clair d'index manquant ou de structure de requête inefficace.

Utiliser mysqldumpslow

Lire le fichier journal brut est impraticable pour les boutiques actives qui génèrent des milliers d'entrées de requêtes lentes. L'outil mysqldumpslow, inclus avec MySQL, agrège et résume les entrées du journal des requêtes lentes. Il regroupe les requêtes identiques (en abstrayant les valeurs spécifiques) et les trie selon divers critères.

Pour trouver les 10 requêtes les plus lentes par temps moyen : mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log

Pour trouver les requêtes avec le plus de temps d'exécution total : mysqldumpslow -s t -t 10 /var/log/mysql/slow-query.log

Pour trouver les requêtes ayant examiné le plus de lignes : mysqldumpslow -s r -t 10 /var/log/mysql/slow-query.log

Le flag -s spécifie l'ordre de tri : at pour temps moyen, t pour temps total, c pour nombre (combien de fois la requête est apparue), r pour lignes examinées. Le flag -t limite la sortie aux N premières requêtes.

Le tri le plus utile pour l'analyse initiale est par temps total (-s t), qui montre quelles requêtes consomment le plus de temps de base de données globalement. Une requête qui prend 0,5 seconde mais s'exécute 1000 fois par heure consomme plus de temps total qu'une requête qui prend 5 secondes mais ne s'exécute qu'une fois par heure.

Utiliser pt-query-digest

Pour une analyse plus détaillée, pt-query-digest de Percona Toolkit est l'outil standard de l'industrie. Il fournit des statistiques beaucoup plus détaillées que mysqldumpslow, incluant les distributions en percentiles des temps de requête, l'analyse de variance et les statistiques au niveau des tables.

Utilisation basique : pt-query-digest /var/log/mysql/slow-query.log

La sortie commence par une section de profil classant les requêtes par temps total, similaire à mysqldumpslow mais avec plus de détails. Chaque requête reçoit ensuite une section détaillée montrant les temps d'exécution minimum, maximum, moyen, médian et au 95e percentile, plus la distribution des lignes examinées et envoyées.

Le 95e percentile est particulièrement important pour les performances PrestaShop. Il vous indique le temps d'exécution sous lequel tombent 95 % des exécutions. Si la moyenne est de 0,3 seconde mais le 95e percentile est de 2,5 secondes, vous avez un problème de cohérence : la plupart du temps la requête est acceptable, mais 5 % des utilisateurs connaissent une réponse beaucoup plus lente.

Vous pouvez installer Percona Toolkit sur Debian et Ubuntu avec apt install percona-toolkit ou le télécharger depuis le site web de Percona. L'installation en vaut la peine sur tout serveur où vous exécutez PrestaShop.

Requêtes lentes courantes dans PrestaShop

Certains motifs de requêtes apparaissent de façon répétée dans les journaux de requêtes lentes PrestaShop. Connaître ces motifs vous aide à diagnostiquer les problèmes plus rapidement.

Scans complets de table sur ps_product

Les requêtes contre la table ps_product sans utilisation correcte d'index sont parmi les requêtes lentes les plus courantes. Lorsque votre catalogue dépasse quelques milliers de produits, toute requête qui scanne la table produit entière devient problématique. Cherchez les requêtes avec des clauses WHERE sur des colonnes non indexées, ou des requêtes qui joignent ps_product avec ps_product_lang et ps_product_shop sans utiliser efficacement les clés primaires.

Listes de produits par catégorie avec de nombreux filtres

Lorsque les clients utilisent la navigation à facettes (recherche facettée) pour filtrer les produits par attributs, caractéristiques ou fourchettes de prix, PrestaShop génère des requêtes complexes joignant plusieurs tables. Les tables ps_layered_* utilisées par le module de recherche facettée peuvent devenir des goulots d'étranglement si des index sont manquants ou si le processus d'indexation n'a pas été exécuté récemment.

Requêtes de recherche

La recherche intégrée de PrestaShop utilise les tables ps_search_word et ps_search_index. Sur les boutiques avec de gros catalogues et de nombreux termes de recherche, ces tables deviennent volumineuses et les requêtes contre elles ralentissent. La requête de recherche implique typiquement une opération de texte intégral ou de multiples conditions LIKE, qui sont toutes deux intrinsèquement plus lentes que les recherches par index.

Requêtes de panier et de commandes

Les requêtes qui agrègent les données de panier ou de commandes peuvent être lentes sur les boutiques avec un long historique. Si votre table ps_cart a des millions de lignes (ce qui est courant car PrestaShop crée un nouveau panier pour presque chaque visiteur), les requêtes qui scannent cette table deviennent lentes. Il en va de même pour ps_orders et ps_order_detail sur les boutiques à fort volume.

Requêtes de statistiques et de rapports

Les modules de statistiques du back-office exécutent souvent des requêtes d'agrégation (SUM, COUNT, GROUP BY) sur de grandes tables comme ps_orders, ps_connections et ps_page_viewed. Ces requêtes peuvent être extrêmement lentes car elles scannent de grands ensembles de données. Sur les boutiques fonctionnant depuis des années, ces tables peuvent contenir des millions de lignes, et les requêtes de statistiques qui fonctionnaient parfaitement sur un petit jeu de données prennent maintenant des minutes.

Requêtes générées par les modules

Les modules tiers génèrent fréquemment des requêtes inefficaces car les développeurs de modules testent souvent contre de petits jeux de données. Un module qui fonctionne parfaitement avec 100 produits peut générer des requêtes catastrophiquement lentes avec 10 000 produits. Le journal des requêtes lentes vous aide à identifier quels modules sont responsables car le texte de la requête contient souvent des noms de tables ou des motifs qui pointent vers des modules spécifiques.

Utiliser EXPLAIN pour analyser les requêtes

Une fois que vous avez identifié des requêtes lentes dans le journal, l'étape suivante est de comprendre pourquoi elles sont lentes. L'instruction EXPLAIN vous montre comment MySQL prévoit d'exécuter une requête, incluant quels index il utilise, combien de lignes il prévoit d'examiner et quelles stratégies de jointure il emploie.

Lire la sortie d'EXPLAIN

Exécutez EXPLAIN suivi de la requête lente. La sortie montre une ligne par table dans la requête, avec ces colonnes importantes :

type : Comment MySQL accède à la table. Valeurs du meilleur au pire : system/const (une seule ligne, essentiellement gratuit), eq_ref (une ligne par jointure, utilisant un index unique), ref (plusieurs lignes, utilisant un index non unique), range (scan de plage d'index), index (scan complet d'index), ALL (scan complet de table). Si vous voyez ALL sur une table avec plus de quelques milliers de lignes, c'est presque certainement votre goulot d'étranglement.

key : Quel index MySQL a effectivement choisi pour cette table. Si c'est NULL, aucun index n'est utilisé et MySQL scanne la table entière.

rows : Le nombre estimé de lignes que MySQL doit examiner. C'est une estimation, pas exact, mais cela vous donne un sens de l'échelle. Si la valeur estimée des lignes est proche du nombre total de lignes dans la table, vous avez un scan complet de table.

Extra : Informations supplémentaires sur le plan d'exécution. Surveillez Using filesort (MySQL doit trier les résultats sans index, ce qui est lent pour les grands jeux de données), Using temporary (MySQL crée une table temporaire, souvent pour les opérations GROUP BY ou DISTINCT), et Using where (MySQL filtre les lignes après les avoir lues, ce qui signifie que l'index ne couvre pas entièrement la clause WHERE).

Exemple EXPLAIN

Considérez une requête lente : SELECT p.id_product, pl.name FROM ps_product p LEFT JOIN ps_product_lang pl ON p.id_product = pl.id_product WHERE pl.id_lang = 1 AND p.active = 1 AND p.price > 100 ORDER BY p.date_add DESC LIMIT 20

Exécuter EXPLAIN sur cette requête pourrait montrer que la table ps_product est accédée avec le type ALL (scan complet de table), aucune clé n'est utilisée, et la colonne Extra montre Using where; Using filesort. Cela vous dit que MySQL lit chaque ligne de la table produit, filtre par statut actif et prix, puis trie les résultats par date. Sur une table de 50 000 produits, cela implique la lecture et le tri de milliers de lignes pour n'en retourner que 20.

La correction serait de créer un index composite sur (active, price, date_add) ou de restructurer la requête pour mieux tirer parti des index existants.

Optimisation des index pour PrestaShop

Ajouter les bons index est le moyen le plus efficace d'accélérer les requêtes lentes. Un index permet à MySQL de trouver des lignes sans scanner la table entière, similaire à la façon dont l'index d'un livre vous permet de trouver un sujet sans lire chaque page.

Quand ajouter un index

Ajoutez un index quand EXPLAIN montre un scan complet de table (type ALL) sur une table avec beaucoup de lignes, quand une requête s'exécute fréquemment et apparaît régulièrement dans le journal des requêtes lentes, et quand la clause WHERE, la condition JOIN ou la clause ORDER BY de la requête référence des colonnes qui ne sont actuellement pas indexées.

N'ajoutez pas d'index aveuglément. Chaque index accélère les lectures mais ralentit les écritures (INSERT, UPDATE, DELETE) car MySQL doit mettre à jour l'index à chaque modification de données. PrestaShop effectue de nombreuses écritures (mises à jour du panier, création de commandes, suivi des statistiques), donc une indexation excessive crée ses propres problèmes de performance.

Index composites

Pour les requêtes PrestaShop, les index composites (multi-colonnes) sont souvent plus efficaces que les index à colonne unique. Un index composite sur (id_shop, id_lang, active) permet à MySQL de gérer efficacement les requêtes filtrant sur les trois colonnes. L'ordre des colonnes dans l'index est important : MySQL utilise l'index de gauche à droite, donc la colonne la plus sélective (celle qui filtre le plus de lignes) devrait généralement venir en premier.

L'architecture multiboutique et multilingue de PrestaShop signifie que de nombreuses requêtes incluent des conditions id_shop et id_lang. Ces colonnes apparaissent dans pratiquement chaque requête contre les tables de produits, catégories et CMS. Si vous ajoutez des index personnalisés, inclure ces colonnes est souvent nécessaire pour que l'index soit utile.

Index couvrants

Un index couvrant contient toutes les colonnes dont une requête a besoin, de sorte que MySQL peut satisfaire la requête entière depuis l'index sans lire les données réelles de la table. Cela est indiqué dans EXPLAIN par Using index dans la colonne Extra. Les index couvrants offrent les meilleures performances possibles car lire depuis un index est plus rapide que lire depuis la table elle-même (les index sont plus petits et plus susceptibles de tenir en mémoire).

Ajouts d'index courants pour PrestaShop

Plusieurs index non présents dans une installation PrestaShop par défaut peuvent améliorer significativement les performances sur les grandes boutiques. Ceux-ci incluent des index sur la colonne date_add dans ps_cart et ps_orders pour les requêtes qui filtrent ou trient par date, des index composites sur ps_product_attribute pour les requêtes avec beaucoup de combinaisons, et des index sur les colonnes personnalisées ajoutées par les modules qui exécutent des requêtes fréquentes contre elles.

Avant d'ajouter un index, vérifiez l'amélioration en exécutant la requête lente avec et sans l'index. Utilisez EXPLAIN pour confirmer que MySQL utilise effectivement le nouvel index. Un index inutilisé gaspille de l'espace disque et ralentit les écritures sans fournir aucun bénéfice.

Gestion des connexions et optimisation des requêtes

Pooling de connexions

PrestaShop utilise par défaut une seule connexion de base de données par requête. Chaque processus PHP ouvre une connexion à MySQL, exécute ses requêtes et ferme la connexion à la fin de la requête. Sur les boutiques actives avec de nombreux visiteurs simultanés, cela crée un taux élevé de création et destruction de connexions, ce qui a un coût.

Le paramètre max_connections de MySQL limite le nombre de connexions simultanées autorisées. Si votre boutique manque de connexions, les visiteurs voient des erreurs "Too many connections". La valeur par défaut est souvent 151, ce qui peut être insuffisant pour les boutiques à fort trafic avec de nombreux workers PHP-FPM.

Pour déterminer la bonne valeur, vérifiez la variable de statut Max_used_connections, qui vous indique le nombre maximal de connexions simultanées depuis le démarrage de MySQL. Définissez max_connections à au moins 20 % au-dessus de ce pic pour fournir une marge lors des pics de trafic.

Techniques d'optimisation de requêtes

Au-delà de l'indexation, plusieurs optimisations au niveau des requêtes peuvent améliorer les performances de la base de données PrestaShop :

Éviter SELECT * : Les requêtes sélectionnant toutes les colonnes transfèrent plus de données que nécessaire entre MySQL et PHP. Le cœur de PrestaShop utilise parfois SELECT * par commodité, mais les requêtes personnalisées devraient spécifier uniquement les colonnes nécessaires.

Limiter les sous-requêtes : L'optimiseur de MySQL gère les sous-requêtes moins efficacement que les JOINs dans de nombreux cas. Si vous voyez des requêtes lentes avec des motifs IN (SELECT ...), les réécrire en JOINs améliore souvent les performances. Cela s'applique particulièrement aux requêtes générées par les modules.

Utiliser LIMIT judicieusement : Pour les listes paginées, PrestaShop utilise typiquement LIMIT offset, count. Pour les grands offsets (comme la page 500 d'une liste de produits), cela devient lent car MySQL doit lire et ignorer toutes les lignes jusqu'à l'offset. Une approche plus efficace est la pagination par keyset, où vous filtrez par le dernier identifiant vu au lieu d'utiliser un offset.

Opérations par lots : Les modules qui traitent les produits en boucle exécutent souvent une requête par produit. Réécrire celles-ci en requêtes par lots (utilisant des clauses IN ou des instructions CASE pour les mises à jour) réduit dramatiquement le nombre d'allers-retours vers la base de données.

Surveillance et optimisation continue

L'optimisation de base de données n'est pas une tâche ponctuelle. À mesure que votre catalogue grandit, que les modèles de trafic changent et que vous installez de nouveaux modules, de nouvelles requêtes lentes apparaissent. Établissez une routine pour surveiller les performances de la base de données.

Activez le journal des requêtes lentes de façon permanente avec un seuil raisonnable (0,5 à 1 seconde). Examinez le journal hebdomadairement ou mensuellement en utilisant pt-query-digest. Faites attention aux nouvelles requêtes qui apparaissent dans le journal et aux requêtes existantes dont le temps d'exécution augmente au fil du temps.

Surveillez les métriques de performance clés de MySQL : le taux de succès du buffer pool (devrait être au-dessus de 99 %), le nombre de requêtes lentes par heure, le temps moyen de requête et l'utilisation des connexions. Ces métriques vous donnent un avertissement précoce de dégradation des performances avant qu'elles n'impactent les utilisateurs.

Lorsque vous ajoutez ou mettez à jour des modules, vérifiez s'ils introduisent de nouvelles requêtes lentes. Exécutez la fonctionnalité du module tout en surveillant le journal des requêtes lentes pour détecter les problèmes avant qu'ils n'affectent le trafic de production. Un module qui génère des requêtes efficaces sur une boutique de test avec 50 produits peut créer des goulots d'étranglement sévères sur une boutique de production avec 50 000 produits. Tester avec des données à l'échelle de la production est le seul moyen fiable de vérifier les performances d'un module.

Résumé

Le journal des requêtes lentes MySQL est votre outil le plus précieux pour trouver et corriger les goulots d'étranglement de base de données dans PrestaShop. Activez-le, définissez un seuil approprié et utilisez des outils d'analyse comme mysqldumpslow ou pt-query-digest pour identifier les pires contrevenants. Utilisez EXPLAIN pour comprendre pourquoi des requêtes spécifiques sont lentes, et appliquez des index ciblés pour éliminer les scans complets de table. Surveillez vos performances de base de données en continu, car l'optimisation est un processus continu à mesure que votre boutique grandit. La combinaison d'analyse du journal des requêtes lentes, d'optimisation guidée par EXPLAIN et d'indexation appropriée peut transformer une boutique PrestaShop lente en une boutique qui gère de gros catalogues et un fort trafic avec des chargements de page réactifs.

Lire la réponse complète

Quand les combinaisons PrestaShop tuent la performance : limites et solutions

Le systeme de combinaisons de PrestaShop permet de creer des variantes de produits. Il fonctionne parfaitement pour les produits avec quelques variantes. Mais quand les produits ont des centaines ou milliers de combinaisons, la performance se degrade dramatiquement.

Pourquoi les combinaisons causent des problemes de performance

Architecture de la base de donnees

PrestaShop stocke les donnees de combinaisons dans plusieurs tables : ps_product_attribute, ps_product_attribute_combination, ps_stock_available, ps_specific_price. Un produit avec 5 tailles et 10 couleurs cree 50 combinaisons avec plus de 350 lignes en base.

Le probleme de croissance exponentielle

Attributs	Valeurs	Combinaisons	Lignes BD
2	5 x 5	25	~175
3	10 x 15 x 8	1 200	~8 400
4	10 x 15 x 8 x 5	6 000	~42 000

Limites pratiques

Nombre	Front Office	Back Office	Verdict
1-50	Rapide	Rapide	Aucun probleme
50-200	Acceptable	Acceptable	Gerable
200-500	Lent (3-8s)	Lent	Optimisation necessaire
500-1000	Tres lent	Tres lent	Restructuration a envisager
1000+	Inutilisable	Plantages	Restructuration obligatoire

Solution 1 - Restructurer le catalogue

Au lieu d'un produit avec 50 combinaisons (10 couleurs x 5 tailles), creez des produits separes par couleur avec 5 combinaisons chacun. Plus rapide et meilleur pour le SEO.

Solution 2 - Optimisation base de donnees et serveur

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

Solution 3 - Chargement progressif des combinaisons

Au lieu de charger toutes les combinaisons au chargement de la page, charger les donnees par AJAX quand le client selectionne un attribut.

Solution 4 - Strategies de cache

Cache de page complet (Varnish, LiteSpeed) pour les pages produits. Redis ou Memcached pour le cache objet.

Quand eviter completement les combinaisons

Produits configurables avec 4+ attributs - Module configurateur de produit
Produits dimensionnels - Module de dimensions personnalisees
Produits print-on-demand - Module de design produit

Recommandations par nombre de combinaisons

Nombre	Action recommandee
Moins de 100	Aucune action necessaire
100-300	Index BD, OPcache, Redis
300-1000	Diviser les produits, index, lazy loading
Plus de 1000	Restructurer le catalogue, module configurateur

Lire la réponse complète

Performance admin PrestaShop : pourquoi le back office est lent

Un back office PrestaShop lent est l'un des problemes les plus frustrants. Ce guide identifie les causes les plus courantes et fournit des solutions concretes.

Les causes les plus courantes

1. Connexion API PrestaShop Addons

Cause numero un. Le back office fait des requetes HTTP vers addons.prestashop.com. Quand cette API est lente, tout votre back office attend.

Solution - Deconnectez-vous de votre compte Addons ou desactivez les appels API.

2. Mode debug active

Desactive tous les caches et recompile les templates a chaque requete.

define('_PS_MODE_DEV_', false);

3. Trop de modules installes

Chaque module ajoute du surcharge. Desinstallez les modules inutilises, surtout les modules de statistiques et de gamification.

4. Base de donnees non optimisee

DELETE FROM ps_cart WHERE id_cart NOT IN (
    SELECT id_cart FROM ps_orders
) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

OPTIMIZE TABLE ps_cart, ps_connections, ps_guest;

5. Limitations de l'hebergement mutualise

Recommandation : VPS avec 2+ CPU, 4 GB RAM, SSD et PHP 8.1+.

6. OPcache non active

opcache.enable = 1
opcache.memory_consumption = 256

7. Widgets du tableau de bord lents

Simplifier le tableau de bord. Supprimer les widgets inutiles.

8. Grand catalogue produits

Reduire les produits par page a 20-50. Utiliser la recherche plutot que la navigation.

Checklist d'optimisation

Desactiver le mode debug
Compilation des templates : "Ne jamais recompiler"
Activer le cache (Redis prefere)
Activer OPcache
Se deconnecter de l'API Addons
Desinstaller les modules inutilises
Nettoyer la base de donnees
Simplifier le tableau de bord
Passer au VPS/dedie
Utiliser PHP 8.1+

Lire la réponse complète

Cookie	Fournisseur	Finalité	Durée
PrestaShop-*	PrestaShop	Gestion de session et fonctionnalité du panier	Session
PHPSESSID	PHP	Identifiant de session PHP	Session
mprcr_consent	MPR Cookies Revolution	Enregistre les préférences de consentement des cookies	365 jour(s)
mprcr_version	MPR Cookies Revolution	Suit la version de la configuration du consentement	365 jour(s)

Cookie	Fournisseur	Finalité	Durée
TawkConnectionTime	Tawk.to	Sleduje dobu pripojenia chatovej relacie	Session
__tawkuuid	Tawk.to	Identifikuje vracajucich sa navstevnikov chatu	6 mois

Dépannage

Le problème : vous avez besoin du module, mais pas de ses ressources sur chaque page

Méthode 1 : Utiliser Theme.yml pour supprimer les ressources des modules

Méthode 2 : Media::unregisterStylesheet et Media::unregisterJavascript

Méthode 3 : Module personnalisé pour bloquer des ressources spécifiques

Méthode 4 : L'approche par décrochage de hook

Méthode 5 : Remplacer les ressources des modules via votre thème

PrestaShop 1.7 vs 8.x : différences d'approche

Mesurer les gains de performance après la désactivation des ressources

Risques et problèmes de compatibilité

Un flux de travail pratique pour la suppression sécurisée des ressources

Comprendre le memory_limit de PHP

Comment vérifier votre limite de mémoire actuelle

Depuis le Back Office PrestaShop

En utilisant phpinfo()

Via la ligne de commande

Causes courantes des erreurs de limite de mémoire

Imports de produits volumineux

Produits avec de nombreuses déclinaisons

Modules surchargés ou mal codés

Catalogues volumineux et requêtes complexes

Compilation des templates Smarty

Comment augmenter la limite de mémoire

Méthode 1 : php.ini

Méthode 2 : .htaccess (Apache avec mod_php uniquement)

Méthode 3 : .user.ini (PHP-FPM)

Méthode 4 : Dans le code de PrestaShop

Méthode 5 : Configuration par pool (PHP-FPM)

Mémoire par processus vs mémoire partagée

Diagnostiquer les fuites de mémoire et la consommation excessive

Activer le mode débogage PrestaShop

Surveiller l'utilisation de la mémoire dans le code

Utiliser le profilage Xdebug

Vérifier les requêtes lentes et MySQL

Mémoire OPcache

Configuration mémoire MySQL

Quand mettre à niveau votre hébergement

Référence rapide : Paramètres recommandés par taille de boutique

Comprendre max_input_vars dans PrestaShop

Pourquoi PrestaShop nécessite des valeurs élevées de max_input_vars

Symptômes d'un max_input_vars trop bas

Comment vérifier votre valeur actuelle de max_input_vars

Calculer la valeur de max_input_vars dont vous avez besoin

Comment augmenter max_input_vars

Méthode 1 : php.ini (recommandée)

Méthode 2 : .htaccess (Apache avec mod_php ou mod_fcgid)

Méthode 3 : .user.ini (PHP-FPM / CGI)

Méthode 4 : Panneau de contrôle de l'hébergement

La complication du patch Suhosin

Approches alternatives pour les produits avec plus de 500 déclinaisons

Importer les déclinaisons via CSV

Utiliser l'API Webservice PrestaShop

Diviser les produits volumineux

Gérer les déclinaisons par lots

Vérifier le correctif

Paramètres PHP connexes à vérifier

Notes spécifiques aux versions de PrestaShop

Prévenir les problèmes futurs

Pourquoi les pages blanches surviennent après les mises à jour PrestaShop

Étape 1 : Activer le mode débogage

Étape 2 : Vérifier les journaux d'erreurs

Cause courante 1 : Modules incompatibles

Cause courante 2 : Incompatibilité de version PHP

Cause courante 3 : Conflits de surcharges

Cause courante 4 : Cache et fichiers compilés

Cause courante 5 : Échecs de migration de base de données

Procédure de récupération étape par étape

Procédure de mise à jour sécurisée pour les futures mises à jour

Stratégies de retour en arrière

L'importance des sauvegardes de base de données

Quand faire appel à un professionnel

Comment fonctionnent les mises à jour du panier dans PrestaShop

Symptôme : cliquer sur Ajouter au panier ne fait rien

Symptôme : Ajouter au panier tourne sans fin

Symptôme : le panier se met à jour mais affiche des données incorrectes

Problèmes de cache du navigateur

Conflits de cache Smarty

Paramètres CCC et leur impact

Problèmes de cache CDN

Problèmes de cookies et de session