Un écran blanc PrestaShop (la fameuse « page blanche ») après l'installation d'un module signale presque toujours une erreur PHP fatale que PrestaShop masque. Voici comment la voir et récupérer, dans l'ordre.

• Activez le mode debug pour lire l'erreur. Éditez config/defines.inc.php et mettez define('_PS_MODE_DEV_', true);, puis rechargez la page. Au lieu d'une page blanche, vous verrez l'erreur PHP réelle ainsi que le fichier et la ligne concernés.
• Plus d'accès au back-office ? Désactivez le module par FTP. Renommez le dossier du module, par exemple /modules/modulename/ en /modules/modulename_disabled/. PrestaShop cesse de le charger et votre back-office revient, sans connexion admin.
• Envoyez-nous l'erreur. Dès que vous pouvez lire le message, partagez-le et nous vous dirons d'où vient le problème et comment le corriger.

Pensez à désactiver le mode debug une fois terminé, car il expose des chemins internes. Pour la liste plus complète des causes et solutions, consultez notre guide de dépannage PrestaShop.

Le mode debug PrestaShop affiche les erreurs PHP et les détails d’exception, ce qui est utile pour diagnostiquer un problème mais dangereux à laisser activé sur une boutique live. Il peut exposer des chemins, détails de configuration, erreurs SQL et stack traces visibles par les clients.

Depuis le back-office, le chemin normal est Advanced Parameters > Performance > Debug mode. Sur le système de fichiers, le même réglage est contrôlé par _PS_MODE_DEV_ dans config/defines.inc.php :

// config/defines.inc.php
define('_PS_MODE_DEV_', true);

// switch back after debugging
define('_PS_MODE_DEV_', false);

Si vous devez déboguer brièvement la production, activez-le le moins longtemps possible, reproduisez le problème, sauvegardez les détails d’erreur, puis désactivez-le à nouveau. Un modèle plus sûr réservé développeur consiste à conditionner le debug à une condition privée, par exemple un contrôle temporaire de cookie :

define('_PS_MODE_DEV_', isset($_COOKIE['debug']) && $_COOKIE['debug'] === 'secret');

Après modification du mode debug, videz le cache PrestaShop si le comportement ne change pas immédiatement. Vérifiez aussi les logs serveur, car les erreurs fatales peuvent y être enregistrées même si le navigateur n’affiche qu’une page 500 générique.

Si vous utilisez MPR Performance Revolution, il existe un modèle de production plus sûr que modifier directement le define du cœur : Employee Debug Mode écrit un petit fichier bootstrap et définit un cookie MPRPSDEV de courte durée pour les employés connectés au back-office, afin que les visiteurs normaux restent en mode production. Le cookie est HTTP-only, secure lorsque HTTPS est utilisé, same-site Lax, et expire après quatre heures d’inactivité. Cela reste du debug sur une boutique live, donc utilisez-le de manière étroite, mais c’est moins risqué que montrer les stack traces à chaque visiteur.

Ne laissez jamais _PS_MODE_DEV_ activé après reproduction de l’incident. Capturez le message d’exception, la stack trace et l’URL de requête, puis désactivez le mode debug et travaillez depuis les logs. Si l’erreur apparaît seulement pendant le checkout ou les callbacks de paiement, privilégiez les logs serveur et logs module plutôt que d’exposer la sortie debug sur des URL publiques de retour paiement.

C'est presque toujours une différence d'environnement entre les deux serveurs, pas le module lui-même. Vérifiez d'abord :

• Version de PHP, assurez-vous que le test et la production utilisent la même version.
• OPcache, la production met souvent en cache l'ancien code ; videz OPcache après le déploiement (le piège le plus courant).
• Permissions de fichiers. Le module a besoin d'un accès en écriture à ses propres répertoires.
• Conflit de module. Un autre module en production peut entrer en conflit ; désactivez les suspects un par un.
• Configuration différente, comparez les réglages PrestaShop et serveur clés des deux côtés.

Comparer la sortie phpinfo() de chaque environnement est le moyen le plus rapide de repérer l'écart. Pour un guide complet, voir notre guide de dépannage PrestaShop.

Une erreur 500 Internal Server Error sur PrestaShop signifie que quelque chose a planté côté serveur : la résolution commence par trouver le vrai message d'erreur. Vérifiez dans cet ordre :

• Le journal d'erreurs PHP de votre serveur, le plus important ; il contient l'erreur fatale réelle. En cas de doute, demandez à votre hébergeur où il se trouve.
• Les journaux PrestaShop dans var/logs/.
• Le journal d'erreurs Apache ou Nginx.
• Le mode debug, activez-le temporairement pour voir l'erreur dans le navigateur, puis désactivez-le.

Si vous voyez une 500 mais aucun détail nulle part, c'est souvent un problème de .htaccess ou une règle mod_security qui bloque la requête. Le pas à pas complet est dans notre guide de dépannage PrestaShop.

Suivez ces vérifications dans l'ordre. Les problèmes d'enregistrement de configuration sont généralement causés par une requête POST bloquée, un token admin périmé, des permissions manquantes, des limites serveur ou un problème de table/configuration du module.

• Erreurs JavaScript. Ouvrez les Developer Tools du navigateur et vérifiez les onglets Console et Network. Une erreur JavaScript peut arrêter le gestionnaire de soumission, et une réponse 403/500 indique que la requête a atteint le serveur mais y a échoué.
• Token de sécurité expiré. Les contrôleurs admin PrestaShop utilisent des tokens dans les URL et les formulaires. Ouvrez la page de configuration du module depuis Modules > Module Manager, ne soumettez pas depuis un ancien onglet de navigateur, puis réessayez. Si vous utilisez un proxy ou un cache devant le back-office, assurez-vous que les pages admin ne sont jamais mises en cache.
• Permissions employé. Vérifiez que le profil employé peut voir et configurer les modules. Un profil sans la bonne permission de module peut voir la page mais échouer à l'enregistrement ou être redirigé sans changement.
• Trop de champs de formulaire. Les gros formulaires multilingues ou multiboutiques peuvent dépasser max_input_vars, ce qui fait disparaître silencieusement les champs de fin du POST. Augmentez-le à 3000 ou 5000 pour les grands formulaires.
• Limites POST/corps. Si le formulaire contient des uploads d'images, de longs champs HTML ou de nombreuses options sérialisées, vérifiez aussi post_max_size, upload_max_filesize, max_execution_time et memory_limit.
• Règles de sécurité serveur. ModSecurity, un WAF d'hébergeur ou une règle CDN peut bloquer du HTML, des extraits JavaScript, du code iframe ou du texte ressemblant à du SQL dans les réglages du module. Vérifiez le statut HTTP et demandez à l'hébergeur l'ID de règle correspondant.
• Table de base de données manquante ou mise à niveau échouée. Certains modules stockent leurs réglages dans leurs propres tables. Si l'installation ou la mise à niveau n'a pas créé ces tables, l'enregistrement peut échouer même si le formulaire s'affiche.
• Permissions fichiers. La plupart des réglages de module sont stockés en base de données, mais certains modules écrivent aussi des fichiers générés, des fichiers de cache ou des exports de configuration. Assurez-vous que l'utilisateur du serveur web peut écrire dans les chemins inscriptibles documentés du module.

; Useful PHP starting points for large module forms
max_input_vars = 5000
post_max_size = 32M
upload_max_filesize = 32M
max_execution_time = 300
memory_limit = 256M

Si l'enregistrement ne fonctionne toujours pas, contactez notre équipe support avec le nom du module, la version de PrestaShop, la version de PHP, la réponse Network complète de la requête d'enregistrement et une capture de la Console. Cela nous donne assez d'éléments pour distinguer un problème de navigateur, de token PrestaShop, de limite serveur ou de schéma du module.

Gardez le cache activé sur une boutique en production. Le cache est l'une des principales raisons pour lesquelles PrestaShop reste rapide : le couper durablement ralentit chaque page pour chaque visiteur, sans corriger la cause du problème.

Désactiver une couche de cache reste en revanche un geste de diagnostic légitime. Coupez une couche temporairement quand vous devez vérifier si un symptôme vient bien du cache, cas typiques :

• des modifications de template ou de design qui n'apparaissent pas en boutique ;
• des prix, stocks ou blocs périmés qui survivent à un rechargement normal ;
• un réglage de module qui semble sans effet après enregistrement.

Procédez de façon contrôlée : une seule couche à la fois, de préférence sur une copie de préproduction ou à un moment calme ; notez ce que vous avez coupé et réactivez-le dès le test terminé. Si le symptôme disparaît, vous savez où vivent les données périmées. La solution est de vider ou de réparer cette couche, ou de corriger le module ou le template fautif, pas de laisser le cache éteint.

Dans la plupart des cas, il s'agit simplement d'un cache périmé, et un vidage correct suffit. Suivez les étapes de Comment vider correctement le cache PrestaShop ? avant d'envisager une mesure plus radicale.

Un fichier .htaccess cassé peut interrompre les friendly URLs, redirections, gestion d’assets statiques ou même l’accès back-office. PrestaShop peut régénérer ses propres règles de réécriture, mais les règles serveur personnalisées doivent être sauvegardées d’abord.

PrestaShop écrit ses règles générées à l’intérieur de ses marqueurs gérés et préserve le code personnalisé en dehors de ce bloc. Si le fichier est très cassé, renommez le fichier actuel, créez un nouveau .htaccess vide, puis régénérez les règles de friendly URL depuis le back-office en enregistrant les paramètres SEO & URLs / friendly URL. Videz ensuite le cache.

# Temporary minimal Apache rewrite block - not a full PrestaShop .htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
</IfModule>

Ce snippet est seulement une aide de récupération. Un vrai .htaccess PrestaShop inclut les règles dispatcher, image, asset et redirection générées pour le base URI de la boutique. Si la boutique est dans un sous-répertoire, le RewriteBase régénéré doit correspondre à ce chemin. Si le fichier casse à nouveau immédiatement après régénération, cherchez des règles personnalisées venant d’un thème, module, CDN, plugin de sécurité ou panneau d’hébergement.

Avant de régénérer, sauvegardez le fichier cassé avec une date afin de récupérer les redirections personnalisées, règles CDN ou en-têtes de sécurité qui étaient hors du bloc géré par PrestaShop. Après régénération, comparez la sauvegarde et restaurez uniquement les règles personnalisées que vous comprenez. Placez les redirections personnalisées au-dessus ou au-dessous du bloc généré selon leur objectif, mais évitez de modifier l’intérieur des marqueurs PrestaShop, car le back-office peut réécrire cette section.

Si la régénération échoue, vérifiez qu’Apache a mod_rewrite activé et que l’utilisateur du serveur web peut écrire à la racine de la boutique. Sur Nginx, .htaccess est entièrement ignoré, donc la correction appartient au bloc serveur Nginx plutôt qu’à ce fichier. Testez toujours une URL produit, une URL catégorie, une URL image, un asset CSS/JS et la connexion back-office après réparation, car un fichier de réécriture peut sembler correct alors qu’une classe d’URL reste cassée.

Si les changements CSS n'apparaissent pas dans PrestaShop, parcourez les couches de cache dans l'ordre au lieu de modifier des fichiers au hasard.

• Cache navigateur : faites un rechargement forcé, testez en navigation privée ou désactivez le cache dans le panneau réseau du navigateur.
• Cache PrestaShop : videz le cache depuis Advanced Parameters > Performance, surtout après avoir modifié des templates, des assets de thème ou des vues de module.
• CCC et optimisation des assets : désactivez temporairement la combinaison/minification/mise en cache CSS et JavaScript pendant le test. Si le changement apparaît avec CCC désactivé, régénérez les assets optimisés avant de le réactiver.
• Bon chemin de thème : confirmez que vous avez modifié le thème actif ou le thème enfant actif, pas un ancien répertoire de thème. Dans le panneau réseau, ouvrez le fichier CSS chargé et vérifiez que votre règle est bien présente.
• CDN ou proxy inverse : purgez Cloudflare, Varnish, le cache hébergeur ou tout CDN externe qui sert les assets statiques.
• Cache serveur : si le CSS est généré par PHP ou par un module, OPcache/PHP-FPM et le cache du module peuvent retarder les changements jusqu'à leur purge ou redémarrage.

La preuve la plus rapide se trouve dans le panneau réseau du navigateur : trouvez l'URL CSS, confirmez qu'elle retourne 200, vérifiez le contenu de la réponse et comparez l'horodatage ou la query string. Si la réponse ne contient pas votre règle, PrestaShop ne sert pas le fichier que vous avez modifié. Si elle contient la règle mais que le style n'est pas visible, le problème vient de la spécificité du sélecteur, de l'ordre, des media queries ou d'une autre règle qui l'écrase.

Confirmez le thème actif dans Design > Theme & Logo. Pour un thème normal, le fichier se trouve souvent sous themes/active_theme/assets/css/ ; pour un thème enfant, modifiez le chemin du thème enfant, par exemple themes/child_theme/assets/css/custom.css, et non le thème parent sauf si l'enfant l'importe.

Pendant les tests, allez dans Advanced Parameters > Performance et désactivez Smart cache for CSS, Smart cache for JavaScript, Minify HTML, Compress inline JavaScript in HTML et Move JavaScript to the end s'ils affectent l'asset que vous vérifiez. Utilisez aussi Force compilation et désactivez temporairement le cache Smarty jusqu'à ce que le bon fichier soit confirmé.

css='https://example.com/themes/classic/assets/css/theme.css'
rule='.my-test-rule'

curl -sI "$css?v=$(date +%s)" | sed -n '1,12p'
curl -fsSL "$css?v=$(date +%s)" | grep -nF "$rule" || echo 'rule not in served CSS'
rm -rf var/cache/dev/* var/cache/prod/*

Si Performance Revolution ou un autre module d'optimisation est actif, videz aussi sa couche asset/cache ou désactivez temporairement son optimisation des assets pendant la confirmation du changement.

Quand une traduction de module PrestaShop reste en anglais, les chaînes n’ont généralement pas encore été traduites, ou l’ancienne version est encore en cache. Travaillez dans cet ordre :

• Traduisez les chaînes. Allez dans International → Translations → Translate modules, choisissez le module et votre langue, puis remplissez les traductions.
• Videz le cache. Smarty peut encore servir l’ancien template, videz le cache depuis Advanced Parameters → Performance.
• Vérifiez quel système le module utilise. Certains modules livrent leurs propres fichiers de traduction plutôt que ceux de PrestaShop ; la documentation le précise.
• Faites correspondre le bon fichier. Si les templates utilisent {l s='...' mod='modulename'}, la traduction doit se trouver dans le fichier de traduction du module, pas dans les traductions globales PrestaShop.

Plus de corrections : guide de dépannage PrestaShop.

Après modification des traductions, videz à la fois le cache PrestaShop et tout cache serveur/CDN susceptible de conserver des templates compilés. Assurez-vous aussi de traduire dans le bon contexte boutique et langue en multiboutique, car une chaîne peut être traduite pour une boutique ou locale tandis qu’une autre retombe encore en anglais.

Côté module, les templates Smarty appellent normalement le traducteur PrestaShop avec un nom de module, par exemple {l s='Related Products' mod='mprblogrevolution'}. Cette valeur mod doit correspondre au répertoire du module, et les anciens modules peuvent encore dépendre de fichiers sous leur propre dossier translations/. Si une phrase précise n’apparaît jamais dans l’écran de traduction back-office, elle peut être construite dynamiquement en PHP ou JavaScript ; cherchez donc le texte anglais exact dans la source du module et confirmez qu’il est entouré par la fonction de traduction.

Sur les modules plus anciens ou de style legacy, les traductions proviennent généralement de modules/modulename/translations/xx.php et d'appels Smarty comme {l s='Text' mod='modulename'}. Sur du code PrestaShop 1.7/8/9 plus récent, des domaines de traduction Symfony peuvent être utilisés à la place, souvent avec des fichiers de catalogue comme translations/fr-FR/Modules.Modulename.Admin.xlf ou Modules.Modulename.Shop.xlf. Traduire le fichier legacy ne corrigera pas une chaîne rendue via un domaine Symfony.

JavaScript est un cas à part : les chaînes imprimées dans des variables JS peuvent être traduites côté serveur, mais les chaînes codées en dur dans les fichiers .js nécessitent le mécanisme de traduction JavaScript du module ou doivent d'abord être exposées depuis PHP/les templates. Si seuls les boutons ou alertes dans le navigateur restent en anglais, recherchez aussi dans les fichiers views/js/ du module, en plus des templates PHP et Smarty.

{l s='Table Optimization' mod='mprcleanuprevolution'}

$_MODULE['<{mprcleanuprevolution}prestashop>db_optimize_e48edafb7a762aa641253a1475eb1933'] = 'Optimisation des tables';
$_MODULE['<{mprcleanuprevolution}mypresta-rocks>db_optimize_e48edafb7a762aa641253a1475eb1933'] = 'Optimisation des tables';

Pour déplacer un module affiché au mauvais endroit, ouvrez Design > Positions dans le back office. Cette page est la liste des hooks de PrestaShop en direct, chaque hook exposé par votre thème, avec les modules qui y sont accrochés, dans l'ordre d'affichage. Repérez votre module : vous avez deux leviers, le réordonner dans son hook actuel en le glissant vers le haut ou le bas, ou le décrocher et le greffer sur un autre hook.

Le piège habituel : un module n'apparaît que là où son hook est réellement affiché. Si vous le greffez sur un hook que votre thème n'affiche pas, rien ne s'affiche, la position n'est pas cassée, le hook n'est tout simplement pas sur la page. Le bouton « Greffer un module » montre les hooks disponibles ; consultez la doc de votre thème pour ceux qu'il prend en charge. Le réordonnancement est immédiat ; inutile de vider le cache pour un changement de position.

Pour comprendre comment les hooks se déclenchent et où chacun s'affiche, notre guide des hooks PrestaShop parcourt la liste complète des hooks et le système d'overrides.

Après avoir migré PrestaShop vers un nouveau serveur, les images de produits cassées tiennent presque toujours à l'une de trois causes : les miniatures n'ont pas été régénérées, le dossier /img/ n'est pas accessible en écriture, ou le domaine de la boutique pointe encore vers l'ancien serveur.

Traitez-les dans cet ordre :

1. Régénérez les miniatures. Allez dans Design → Paramètres des images et lancez Régénérer les miniatures. Une base copiée conserve les enregistrements d'images, mais les fichiers redimensionnés doivent être reconstruits sur le nouveau disque.
2. Vérifiez les permissions. Le répertoire /img/ (et ses sous-dossiers) doit être accessible en écriture par le serveur web, sinon PrestaShop ne peut pas écrire les fichiers régénérés. Le propriétaire des fichiers change souvent lors d'une copie entre serveurs.
3. Corrigez le domaine. Si les images renvoient un 404 avec l'ancien nom d'hôte, mettez à jour le domaine dans Paramètres de la boutique → Trafic & SEO et régénérez le .htaccess depuis SEO & URL. Si vous utilisez un CDN, repointez-le aussi vers le nouveau serveur.

Ce n'est qu'une partie d'une migration plus large. Pour la checklist serveur/domaine complète, URLs, redirections, SSL et base de données, voyez notre guide de migration PrestaShop ; pour d'autres symptômes après migration, le guide de dépannage couvre les écrans blancs et erreurs 500.

Utilisez le panneau réseau du navigateur pour séparer les problèmes d'URL des problèmes de fichier. Si l'URL de l'image contient encore l'ancien domaine, corrigez Shop Parameters > Traffic & SEO > Set shop URL, y compris le domaine SSL et l'URI de base, puis régénérez .htaccess. Si le nom d'hôte est correct mais que la réponse est 404, vérifiez si le fichier original existe sous img/p/ et si les règles de réécriture des images sont actives.

Si l'image fonctionne directement depuis le nouveau serveur mais pas via l'URL publique, purgez le CDN/proxy inverse et vérifiez qu'il pointe vers la nouvelle origine. Des URL d'images mixtes http/https après migration indiquent généralement des réglages SSL ou d'URL de base incohérents, et non des enregistrements d'images produit cassés.

find img -maxdepth 2 -type d ! -writable -print | head
find img/p -type f -name '*.jpg' | head

image_url='https://example.com/1-home_default/product.jpg'
curl -sI "$image_url" | sed -n '1,12p'

Non. Database Cleanup est un outil manuel du back-office. Vous ouvrez l'écran de nettoyage, voyez un compteur à jour pour chaque tâche, vieux paniers abandonnés, anciennes statistiques de recherche, prix spécifiques expirés, vieux logs, données de connexion et d'invités, logs d'e-mails, et lancez une tâche ou toutes à la demande. Il n'y a pas d'endpoint cron : rien ne s'exécute seul selon un calendrier.

C'est voulu : vous vérifiez exactement ce qui sera supprimé et en quelle quantité avant de valider, idéal pour un nettoyage ponctuel et après de gros imports. L'erreur fréquente est d'attendre qu'il garde la base propre tout seul, il ne le fera pas ; vous devez revenir le lancer.

Si vous voulez que les nettoyages s'exécutent automatiquement selon un calendrier, c'est Cleanup Revolution qu'il faut, avec automatisation cron (par exemple un nettoyage quotidien de la base et une optimisation hebdomadaire des tables) et journal d'audit. Donc : Database Cleanup pour les lancements manuels, Cleanup Revolution quand vous le voulez planifié et sans intervention.

Dans le code, Cleanup Revolution enregistre trois tâches cron : db_cleanup tous les jours à 03:00, file_cleanup tous les jours à 03:30 et table_optimize chaque semaine à 04:00. Database Cleanup n'enregistre pas ces tâches et n'expose pas d'URL cron ; copier une commande cron de Cleanup Revolution dans Database Cleanup ne rendra donc pas le module manuel planifié.

Pour les détails de configuration, utilisez la documentation de configuration cron de Cleanup Revolution depuis la page produit/support de Cleanup Revolution : Cleanup Revolution.

Quand le mail PrestaShop ne fonctionne pas, commencez dans Paramètres avancés → E-mail : si vous utilisez SMTP, vérifiez le serveur, le port, le nom d'utilisateur et le mot de passe, puis cliquez sur Envoyer un email de test pour reproduire le problème.

Les causes habituelles :

• Votre hébergeur bloque les connexions SMTP sortantes (fréquent en mutualisé).
• Les enregistrements SPF/DKIM ne sont pas configurés : le mail part mais arrive en spam.
• La fonction PHP mail() est désactivée sur le serveur.

Pour une livraison fiable, passez par un service SMTP externe (Mailgun, SendGrid, ou même Gmail SMTP) plutôt que par la fonction mail locale. C'est cette même configuration de messagerie qui alimente les notifications de tickets de MPR Support Revolution, un module de support, pas un correctif d'envoi : remettez d'abord la livraison du cœur en état et ses notifications suivront.

La lenteur du back office PrestaShop se ramène presque toujours à une poignée de causes habituelles. Passez-les en revue dans l'ordre : (1) Trop de modules accrochés aux pages d'administration, chacun qui se charge sur displayBackOfficeHeader alourdit chaque écran. (2) Le mode debug laissé activé en production, ce qui ajoute une lourde surcharge. (3) Des requêtes MySQL lentes, ouvrez le profiler Symfony pour repérer les coupables. (4) Un grand catalogue avec de nombreuses déclinaisons qui ralentit les listings. (5) Le serveur qui manque tout simplement de RAM.

Gains rapides : désactivez le mode debug, vérifiez qu'OPcache est activé, et passez en revue les modules chargés sur chaque page d'admin via Design → Positions → displayBackOfficeHeader, en désactivant ceux dont vous n'avez pas besoin. Si le front office est lent aussi, la cause est généralement commune (cache, ressources serveur, charge des requêtes).

Pour la liste complète, consultez notre guide des performances PrestaShop.

Cela signifie presque toujours que PrestaShop ou Composer ne peut pas charger une classe PHP attendue par le module. Lisez d'abord la classe manquante exacte dans l'erreur fatale ; le namespace indique généralement si le fichier manquant appartient au module lui-même, à une dépendance vendor/ fournie, à un package partagé ou à une entrée de cache périmée.

• Fichiers du module incomplets. Réuploadez le ZIP original. Ne copiez pas seulement le fichier PHP principal du module, et ne fusionnez pas une nouvelle version par-dessus un ancien dossier à moitié supprimé.
• Autoload Composer manquant. Si le module a vendor/autoload.php, ce fichier et tout l'arbre vendor/ doivent être présents. PrestaShop charge les autoloaders des modules actifs pendant le boot Symfony/container sur les branches modernes, donc un dossier vendor manquant peut casser des pages au-delà de l'écran de configuration du module.
• Mauvaise casse sous Linux. MyClass.php et myclass.php sont deux fichiers différents sous Linux. Un module qui fonctionnait sur une machine locale insensible à la casse peut échouer après upload.
• Cache de classes périmé. Videz var/cache/prod et var/cache/dev. Sur les installations plus anciennes, supprimez aussi l'index de classes legacy généré dans le répertoire de cache actif s'il existe.
• OPcache sert encore l'ancien code. Rechargez PHP-FPM ou Apache après avoir remplacé les fichiers du module. Vider le cache PrestaShop ne réinitialise pas l'OPcache web.
• Mauvaise version de PHP. Les dépendances Composer peuvent exiger une version PHP plus récente que celle du serveur, ou un module peut utiliser une syntaxe non prise en charge par votre branche PHP.
• Fichiers illisibles. Assurez-vous que le répertoire du module et les fichiers vendor sont lisibles par l'utilisateur du serveur web.

# From the PrestaShop root
test -f modules/examplemodule/vendor/autoload.php && echo 'module autoload exists'
find var/cache/prod -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +
find var/cache/dev -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +
sudo systemctl reload php8.2-fpm

La réinitialisation fiable est la suivante : sauvegardez le dossier actuel, supprimez le dossier du module cassé, extrayez proprement le ZIP original, restaurez uniquement les uploads ou exports documentés, videz le cache PrestaShop, réinitialisez OPcache et rechargez la page. Si l'erreur fatale nomme une classe de bibliothèque partagée, incluez le nom exact de la classe et la stack trace lorsque vous contactez le support.

Pour les vérifications liées aux pages blanches et erreurs 500, consultez notre guide de dépannage PrestaShop.

Essayez dans cet ordre : (1) Supprimez les cookies du navigateur pour le domaine. (2) Essayez un autre navigateur ou une fenêtre de navigation privée. (3) Videz le contenu de var/cache/. (4) Vérifiez que PS_SHOP_DOMAIN correspond exactement au domaine que vous visitez. (5) Si vous utilisez SSL, confirmez que PS_SSL_ENABLED est correctement défini. (6) Inspectez le .htaccess à la recherche de règles de redirection erronées. En dernier recours, désactivez temporairement les overrides en ajoutant define('_PS_DISABLE_OVERRIDES_', true); dans config/defines.inc.php pour écarter un override défectueux.

Plus de pistes dans notre guide de dépannage PrestaShop.

Cela arrive lorsqu'une mise à jour change quelque chose auquel votre thème n'était pas préparé. Procédez dans l'ordre :

• Confirmez qu'il s'agit du thème. Basculez temporairement sur un thème par défaut (Classic ou Hummingbird). Si la boutique s'affiche correctement, le problème vient de votre thème.
• Cherchez une mise à jour du thème. Vérifiez si le développeur de votre thème a publié une version compatible avec la version de PrestaShop que vous venez d'installer.
• Examinez vos surcharges. Sur un thème enfant, regardez quels fichiers de template référencent des blocs ou du markup qui ont changé ; si vous aviez modifié le thème parent directement, ces modifications ont pu être écrasées ou entrent désormais en conflit.
• Si le thème est abandonné, migrer vers un thème maintenu est souvent la seule option durable.

La cause récurrente, c'est de modifier le thème parent directement : chaque mise à jour écrase alors votre travail. En déplaçant votre CSS, votre JS et vos retouches de template dans un thème enfant, ils restent isolés et à l'abri des mises à jour. Vous pouvez en générer un en quelques secondes avec notre générateur de thème enfant gratuit, puis placer vos surcharges dans son assets/css/custom.css. Vérifiez toujours la compatibilité du thème sur une copie de préproduction avant de mettre à jour en production. Plus de détails : notre guide des thèmes enfants PrestaShop.

L'approche systématique : (1) désactivez tous les modules tiers (pas ceux intégrés à PrestaShop) ; (2) vérifiez si le problème disparaît ; (3) réactivez les modules un par un, en testant après chacun ; (4) quand le problème réapparaît, vous avez trouvé le coupable. C'est fastidieux mais fiable. Pour les problèmes purement de performance, le profiler Symfony (disponible en mode debug) montre quels hooks et modules prennent le plus de temps à s'exécuter.

En savoir plus : notre guide de dépannage.

Si un override de template PrestaShop est ignoré, videz le cache et vérifiez que l’override se trouve dans le chemin du thème actif avec la structure exacte module/template. Pour les templates de module, le chemin habituel est themes/your_theme/modules/module_name/.... Désactivez aussi le cache Smarty/forcez la compilation pendant les tests, car PrestaShop peut continuer à rendre l’ancien template compilé.

modules/mprolark/views/templates/hook/displayBeforeBodyClosingTag.tpl
# override in:
themes/your_theme/modules/mprolark/views/templates/hook/displayBeforeBodyClosingTag.tpl

modules/mprfacebookpixel/views/templates/hook/order-confirmation.tpl
# override in:
themes/your_theme/modules/mprfacebookpixel/views/templates/hook/order-confirmation.tpl

Vérifiez le chemin exact du template source dans le module avant de choisir le chemin d’override. Un template venant de views/templates/hook, views/templates/front ou views/templates/admin peut nécessiter que ce sous-chemin soit reproduit, selon la manière dont le module le rend. Si la boutique utilise un thème enfant, le multishop ou un thème différent pour le contexte boutique courant, l’override doit être placé dans le thème réellement actif pour cette boutique.

• Templates de hook : modules/modulename/views/templates/hook/file.tpl devient themes/your_theme/modules/modulename/views/templates/hook/file.tpl.
• Templates front : modules/modulename/views/templates/front/file.tpl devient themes/your_theme/modules/modulename/views/templates/front/file.tpl.
• Templates admin : les overrides de thème ne s'appliquent normalement pas aux templates de module du back-office ; ceux-ci sont rendus depuis le contexte module/admin, donc modifier le chemin du thème front-office ne les affectera pas.

Avec un thème enfant, placez l'override dans le thème enfant actif pour la boutique actuelle, pas dans le thème parent. Si l'enfant ne surcharge pas le fichier, PrestaShop peut toujours revenir au template parent/module, ce qui donne l'impression que votre fichier modifié est ignoré.

Si le fichier est au bon endroit et que le cache est vidé, confirmez que la page utilise vraiment le template que vous avez modifié. Certains modules rendent un template différent pour AJAX, layouts mobiles, étapes checkout, hooks ou contrôleurs Symfony modernes. Ajoutez temporairement un commentaire HTML inoffensif à l’override, rechargez avec la compilation forcée activée, puis inspectez la source de la page. Si le commentaire est absent, le problème vient du chemin, du contexte thème ou de la sélection du template plutôt que du contenu de l’override.

Les imports produits échouent généralement pour l'une de quatre raisons : le CSV est trop volumineux pour la requête web, les limites d'upload PHP sont trop basses, le serveur expire pendant le traitement des lignes ou des images, ou une ligne précise contient des données invalides.

Commencez par réduire la taille de l'import. Divisez les gros fichiers CSV en lots plus petits, importez les images séparément si possible et testez avec 10 à 50 lignes avant de relancer des milliers de lignes. Si le petit fichier fonctionne, le mapping est probablement correct et le problème vient de la capacité ou du timeout.

Vérifiez les limites PHP et serveur pertinentes :

upload_max_filesize
post_max_size
memory_limit
max_execution_time
max_input_time
max_file_uploads
PHP-FPM request_terminate_timeout
Nginx or Apache proxy/read timeout
CDN timeout, for example Cloudflare request limits

PrestaShop signale les erreurs de taille d'upload lorsque le fichier dépasse upload_max_filesize ou la limite du formulaire, mais les timeouts peuvent apparaître comme une page blanche, une erreur 500 ou un catalogue partiellement importé. Pour les très gros catalogues, utilisez un importateur CLI, un importateur basé sur cron ou un module d'import dédié plutôt que de dépendre d'une longue requête navigateur.

L'importateur natif se trouve sous Advanced Parameters > Import dans PrestaShop 1.7/8/9. Après une page blanche ou une erreur 500, vérifiez var/logs/prod.log, var/logs/dev.log, le log PHP-FPM et le journal d'erreurs du serveur web avant de réessayer, car la page d'import visible perd souvent l'exception réelle lorsque la requête meurt.

Pour un import partiel, ne relancez pas immédiatement le fichier complet avec des options destructrices comme la suppression des produits existants, sauf si c'était prévu. Identifiez la dernière référence ou le dernier ID importé avec succès, découpez le CSV restant à partir de la ligne suivante, corrigez les produits laissés désactivés ou sans images, puis reconstruisez les index de recherche et à facettes après le dernier lot.

Si l'import s'arrête toujours sur la même ligne, inspectez cette ligne pour repérer de mauvais séparateurs, des guillemets non échappés, un encodage invalide, des URL d'image cassées, des références de catégories impossibles, des références en double ou des valeurs qui ne correspondent pas au mapping d'import sélectionné. Utilisez UTF-8, gardez un séparateur cohérent et reconstruisez les index de recherche/filtres à facettes après un gros import réussi si la visibilité produit ou les filtres semblent incorrects.

C'est un problème de permissions fichiers, pas une boutique corrompue. Après une migration serveur, le nouveau serveur exécute souvent PHP sous un autre utilisateur, alors que les fichiers copiés appartiennent encore à l'ancien compte ou à root. PrestaShop ne peut alors pas écrire les templates Smarty compilés ou les fichiers de cache Symfony.

Supprimez d'abord les anciens fichiers de cache, puis corrigez la propriété et les permissions des chemins cache/logs inscriptibles. Remplacez www-data:www-data par l'utilisateur et le groupe réellement utilisés par votre PHP-FPM ou serveur web, comme nginx:nginx ou l'utilisateur de votre compte d'hébergement.

Avant d'exécuter chown, identifiez l'utilisateur sous lequel PHP s'exécute réellement. Sur un shell contenant les fichiers de la boutique, les vérifications utiles sont ps -eo user,group,comm | grep -E 'php-fpm|apache|nginx', grep -R '^user\|^group' /etc/php*/fpm/pool.d 2>/dev/null, ou une page temporaire phpinfo() consultée via le navigateur. Utilisez cet utilisateur/groupe au lieu de deviner www-data.

cd /path/to/prestashop

# Remove generated cache contents, not the parent directories
find var/cache/prod -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +
find var/cache/dev -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +

# Fix common PS 1.7/8/9 writable paths
sudo chown -R www-data:www-data var 2>/dev/null || true
find var -type d -exec chmod 775 {} +
find var -type f -exec chmod 664 {} +

# Older PS 1.6-style Smarty paths, if they exist
sudo chown -R www-data:www-data cache/smarty 2>/dev/null || true
find cache/smarty -type d -exec chmod 775 {} + 2>/dev/null
find cache/smarty -type f -exec chmod 664 {} + 2>/dev/null

Évitez chmod -R 777. Cela peut masquer temporairement l'erreur, mais rend la boutique inscriptible par tout le monde sur le serveur. Si les permissions semblent correctes et que l'erreur persiste, vérifiez l'espace disque, l'épuisement des inodes, les politiques SELinux/AppArmor et si PHP-FPM est chrooté dans un autre chemin.

Notre guide de migration PrestaShop couvre le déplacement complet, et le guide de dépannage couvre les pages blanches et erreurs 500 associées.

Les e-mails de confirmation de commande en double sont généralement causés par des chemins d'envoi en double, pas par le template order_conf lui-même. La confirmation de commande native de PrestaShop est envoyée pendant PaymentModule::validateOrder(), et les hooks autour de la validation de commande peuvent aussi déclencher des modules d'e-mail.

• Module de paiement : vérifiez si le module de paiement appelle la validation de commande deux fois, par exemple une fois depuis l'URL de retour client et une fois depuis un callback webhook/IPN. Les logs du module de paiement et les logs PrestaShop le montrent généralement clairement.
• Mail Alerts ou modules d'e-mail : désactivez temporairement les modules de notification supplémentaires pour voir si le deuxième e-mail est en réalité une alerte séparée qui ressemble à une confirmation de commande.
• Enregistrements de hook en double : vérifiez si un module personnalisé est accroché deux fois à actionValidateOrder, actionValidateOrderAfter ou aux hooks de confirmation de commande et envoie son propre e-mail client.
• Overrides/code personnalisé : inspectez les overrides de PaymentModule, OrderHistory ou Mail, ainsi que tout module personnalisé qui appelle Mail::Send() après la création de commande.
• Relances SMTP/fournisseur : comparez les IDs de message et les horodatages dans le log SMTP. Deux envois PrestaShop différents sont un problème de code/configuration ; un seul envoi livré deux fois est un problème de transport mail.

Commencez par comparer les deux e-mails. Si le sujet, le template et les horodatages sont identiques, examinez d'abord une validation de commande en double ou des hooks en double. Si le contenu diffère, identifiez quel module possède le second template.

Déterminez d'abord si vous avez une commande avec deux e-mails ou deux commandes séparées. Comparez la référence de commande et id_order dans l'e-mail/le back-office : la même référence indique un double envoi d'e-mail, tandis que deux références différentes ou deux lignes de commande indiquent une double validation de paiement ou une relance client/navigateur qui a créé une autre commande.

Si deux commandes existent pour le même panier ou la même transaction de paiement, examinez le chemin de callback/webhook de paiement avant les templates d'e-mail. Si une seule commande existe, concentrez-vous sur les hooks dupliqués, les modules d'e-mail, les overrides et les relances SMTP/fournisseur.

SELECT h.name AS hook_name, m.name AS module_name, hm.position
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 IN (
  'actionValidateOrder',
  'actionValidateOrderAfter',
  'displayOrderConfirmation',
  'displayPaymentReturn'
)
ORDER BY h.name, hm.position;

Le texte des modules est traduit langue par langue : il s'agit donc d'une traduction manquante, pas d'un bug. Si un module s'affiche en anglais alors que votre langue d'admin est le français, les chaînes françaises de ce module ne sont tout simplement pas encore renseignées.

Corrigez-le dans International → Traductions → Traduire les modules : choisissez le module et votre langue, puis complétez les chaînes manquantes. Certains modules fournissent aussi un fichier de traduction à importer, consultez la documentation du module.

Autres solutions : notre guide de dépannage PrestaShop.

Vous pouvez empêcher un module de charger son CSS ou son JavaScript sans le retirer, vous gardez ses hooks, ses tables, ses réglages et ses fonctions back office, et vous ne supprimez que les ressources front office indésirables. Voici les méthodes pratiques, de la plus simple à la plus poussée.

1. Retirer les ressources dans theme.yml

La méthode la plus propre et compatible avec les mises à jour. Dans le theme.yml de votre thème, sous assets, passez l'ID de la ressource à false sous css: all ou js: all. Cet ID est celui que le module transmet à registerStylesheet / registerJavascript (visible dans le code source). Videz ensuite le cache via Paramètres avancés → Performance. Cela retire la ressource sur toutes les pages et survit aux mises à jour du module.

2. Media::unregister dans un hook

Pour un contrôle page par page, utilisez un petit module sur mesure qui appelle Media::unregisterStylesheet() / Media::unregisterJavascript() dans hookActionFrontControllerSetMedia, avec vos propres conditions. Votre module doit s'exécuter après le module cible sur ce hook, réglez l'ordre dans Apparence → Positions.

3. Déhooker le module de displayHeader

Dans Apparence → Positions, vous pouvez retirer un module du hook où il enregistre ses ressources. Cela supprime son CSS/JS partout tandis que ses autres hooks continuent, utile quand vous comptez le restyler entièrement avec votre propre CSS. Plus risqué pour le JavaScript, et une mise à jour peut réajouter le hook : revérifiez après.

Testez avant de vous y fier

Retirer le CSS peut casser la mise en page d'un module ; retirer le JavaScript peut casser les clics, les formulaires ou l'AJAX. Faites d'abord des captures des pages concernées, appliquez le changement, puis vérifiez chaque type de page et chaque fonction. Pour ajouter vos propres styles et scripts sans risque à la mise à jour, voir notre guide CSS et JavaScript personnalisés.

L'erreur Allowed memory size of X bytes exhausted signifie qu'une seule requête PHP a tenté d'utiliser plus de mémoire que memory_limit ne l'autorise, et que PHP l'a arrêtée. La correction consiste en partie à augmenter la limite, et en partie à trouver ce qui a consommé la mémoire.

Vérifier la limite active

Dans le back-office, Advanced Parameters > Information affiche la valeur PHP web. En SSH, php -i | grep memory_limit affiche la valeur CLI, qui peut être différente de PHP-FPM. Lorsque vous déboguez une erreur fatale front-office ou back-office, fiez-vous à la valeur web et au log d'erreurs PHP-FPM/Apache.

Causes courantes

• Gros imports CSV : divisez les fichiers en lots, importez les images séparément et désactivez les modules non essentiels pendant l'import.
• Produits avec des centaines de déclinaisons : la page produit et la logique stock/déclinaisons peuvent charger beaucoup de données en une seule fois.
• Modules mal codés : cherchez le fichier et la ligne dans l'erreur fatale. Les lectures de tables entières, les logs d'objets volumineux et les exports non bornés sont des causes fréquentes.
• Gros catalogues avec navigation à facettes : les pages catégories filtrées peuvent garder de nombreux produits, facettes et déclinaisons en mémoire.
• Génération d'images : régénérer les miniatures de gros catalogues peut épuiser la mémoire si les dimensions d'image sont énormes.

Augmenter la limite proprement

; php.ini or PHP-FPM pool
memory_limit = 512M

; .user.ini in the PrestaShop root, if your host supports it
memory_limit = 512M

# Apache + mod_php only
php_value memory_limit 512M

# PrestaShop fallback in config/defines.inc.php, limited by the server ceiling
@ini_set('memory_limit', '512M');

Où trouver l'erreur fatale

# PHP-FPM / web server logs vary by distribution
tail -f /var/log/php8.2-fpm.log
tail -f /var/log/apache2/error.log
tail -f /var/log/nginx/error.log

# PrestaShop logs
tail -f var/logs/prod.log
tail -f var/logs/dev.log

Ne continuez pas à augmenter la mémoire à l'aveugle. memory_limit s'applique par processus PHP. Une limite de 512 MB sur de nombreux workers PHP-FPM peut épuiser un petit serveur en charge. Si les vues de page normales ont besoin de 512 MB ou plus, utilisez la ligne fatale, les slow logs et le profiling de modules pour trouver la cause racine.

Pour le dimensionnement serveur, consultez notre guide d'hébergement PrestaShop ; pour OPcache, Redis et les outils de cache qui réduisent le travail répété, consultez Performance Revolution.

Si un produit à nombreuses combinaisons ne s'enregistre que partiellement, perd des combinaisons ou échoue en silence, la cause est presque toujours la limite PHP max_input_vars. Elle plafonne le nombre de champs de formulaire acceptés en une requête POST, et au-delà, chaque champ est supprimé silencieusement, sans erreur.

Pourquoi cela arrive

Chaque combinaison ajoute de nombreux champs (impact prix et poids, quantité, référence, EAN-13, MPN, quantité minimale, etc.), et chaque champ texte est multiplié par le nombre de langues. Un produit avec des dizaines de combinaisons sur plusieurs langues dépasse vite le défaut courant de 1000 champs.

Vérifier la valeur actuelle

Dans le back-office, ouvrez Paramètres avancés → Informations et lisez la section de configuration PHP, qui affiche max_input_vars. (Vous pouvez aussi charger un fichier phpinfo() temporaire, puis le supprimer.)

Augmenter la limite

• php.ini (le plus propre, si vous y avez accès) : mettez max_input_vars = 10000 et redémarrez PHP-FPM ou le serveur web. 10000 suffit à la plupart des boutiques ; les très gros catalogues peuvent aller plus haut.
• .user.ini (PHP-FPM/CGI) : la même ligne à la racine ; effectif après quelques minutes.
• .htaccess (seulement Apache mod_php) : php_value max_input_vars 10000, à retirer en cas d'erreur 500, qui signifie que le serveur l'ignore.
• Panneau d'hébergement : l'éditeur MultiPHP INI de cPanel ou les réglages PHP de Plesk exposent la valeur.

À ajuster en même temps

Augmentez aussi post_max_size (au moins 32M), memory_limit (256M+) et max_execution_time (300s) pour que les gros enregistrements n'échouent pas pour une autre raison.

Si ça ne s'enregistre toujours pas

Pour les produits à des centaines de combinaisons, contournez le formulaire : importez les combinaisons en CSV (Paramètres avancés → Importer) ou via l'API webservice, ni l'un ni l'autre n'est soumis à max_input_vars. Vérifiez aussi qu'un réglage de l'hébergeur, une limite du serveur web ou un pare-feu ne tronque pas la requête.

Voir notre guide de dépannage PrestaShop.

Une page d'administration PrestaShop blanche après une mise à jour du noyau, l'écran blanc de la mort, signifie presque toujours que PHP a rencontré une erreur fatale que le mode production masque. La marche à suivre : rendre l'erreur visible, puis nettoyer ce que la mise à jour a laissé obsolète.

1. Activer le mode débogage pour voir la vraie erreur

Modifiez /config/defines.inc.php et mettez define('_PS_MODE_DEV_', true);. Sur les versions basées sur Symfony, vous pouvez plutôt définir APP_DEBUG=1 (et l'environnement dev) dans le .env à la racine. Rechargez, au lieu de la page blanche, vous obtenez un chemin de fichier, un numéro de ligne et une trace d'appel.

2. Vider les caches et l'index de classes

Supprimez le contenu du cache Symfony (var/cache/prod et var/cache/dev) et des caches Smarty (cache/smarty/compile, cache/smarty/cache), et retirez le fichier d'index de classes pour que PrestaShop le régénère. En PHP-FPM, réinitialisez aussi OPcache (redémarrez PHP-FPM ou appelez opcache_reset()). Le bytecode obsolète est une cause très fréquente.

3. Écarter modules et overrides

Les modules tiers incompatibles et les fichiers obsolètes dans /override/ sont les coupables habituels. Si l'erreur nomme un module, désactivez-le : renommez son dossier sous /modules/, ou passez active = 0 dans ps_module. Pour tester les overrides, déplacez /override/ de côté, supprimez à nouveau l'index de classes et rechargez.

4. Vérifier PHP et les logs

Vérifiez que la version PHP de votre serveur correspond à la plage exigée par votre version de PrestaShop (voir les notes de version), un changement de PHP pendant la mise à jour déclenche souvent des erreurs fatales. Si le mode débogage n'affiche toujours rien, lisez les logs d'erreurs du serveur web et de PHP-FPM, ainsi que le répertoire de logs de PrestaShop.

Travaillez toujours à partir d'une sauvegarde : avant toute mise à jour du noyau, sauvegardez fichiers et base de données, désactivez les modules tiers et réactivez-les un par un ensuite. Pour un diagnostic plus poussé, consultez notre guide de dépannage PrestaShop.

Si le panier PrestaShop ne se met pas à jour, le bouton ne réagit pas, tourne sans fin ou affiche un mauvais total. La cause est presque toujours l'une de trois : une erreur JavaScript, un cache obsolète ou un conflit de modules. Traitez-les dans cet ordre.

Commencer dans le navigateur

« Ajouter au panier » est une requête AJAX, ouvrez donc les outils de développement (F12). Sur l'onglet Console, rechargez la fiche produit et repérez les erreurs rouges comme $ is not defined ou un SyntaxError, un seul script cassé (souvent d'un module) arrête tout le JavaScript de la page, panier compris. Le chemin du fichier dans l'erreur désigne le module fautif ; désactivez-le pour confirmer.

Si le bouton tourne sans finir, passez à l'onglet Network, filtrez sur XHR et cliquez. La requête du panier doit renvoyer un statut 200 avec du JSON valide. 500 = erreur serveur ; du HTML mêlé au JSON signifie qu'un module a affiché un avertissement avant le JSON ; 403 pointe vers un module de sécurité ou un WAF.

rm -rf var/cache/dev/* var/cache/prod/*

base='https://example.com/index.php'
curl -sS "$base?controller=cart&add=1&ajax=true&id_product=1&qty=1&token=STATIC_TOKEN" \
  -H 'X-Requested-With: XMLHttpRequest' | jq .

Vider chaque couche de cache

Si le panier se met à jour mais affiche d'anciennes quantités ou d'anciens prix, un cache sert des données périmées. Testez d'abord en navigation privée pour écarter le navigateur. Videz ensuite les dossiers de compilation et de cache Smarty sous var/cache (ou Paramètres avancés > Performances > Vider le cache). Avec le CCC actif, l'erreur de syntaxe JS d'un module peut casser tout le paquet combiné, désactivez le CCC pour tester. Si un CDN comme Cloudflare est devant, vérifiez qu'aucune règle « Cache Everything » ne couvre l'endpoint du panier ; ses réponses sont propres au client et ne doivent pas être mises en cache.

Cookies, sessions et conflits de modules

Un panier qui se vide à chaque page est souvent un problème de cookie, domaine incohérent (www ou non), mauvais attribut SameSite ou Secure, ou sessions non partagées entre serveurs. Pour trouver un module en conflit, désactivez les modules tiers par groupes et réactivez-les par lots de cinq ; surveillez tout ce qui est branché sur actionCartSave, actionCartUpdate ou actionFrontControllerSetMedia.

Pour un diagnostic plus complet, voir notre guide de dépannage PrestaShop.

Quand quelque chose casse, la réponse est presque toujours dans vos logs PrestaShop. Il suffit de savoir quel fichier ouvrir. Voici la version rapide qui résout la plupart des problèmes.

Où se trouvent les logs :

• Log applicatif, var/logs/prod.log (production) et var/logs/dev.log (mode debug). À vérifier en premier pour les erreurs PrestaShop et modules. Filtrez sur ERROR et CRITICAL.
• Log d'erreurs PHP, capture les erreurs fatales avant le démarrage du logger PrestaShop. L'emplacement dépend de l'hébergeur ; php -i | grep error_log le révèle.
• Log du serveur web, Apache (/var/log/apache2/error.log) ou Nginx (/var/log/nginx/error.log). C'est là qu'apparaît une erreur 500 nue sans détail PHP.
• Back-office, Paramètres avancés > Logs montre les événements que PrestaShop enregistre lui-même (échecs de connexion, échecs d'e-mail), mais pas les erreurs PHP fatales.

La méthode qui trouve la cause : activez le mode debug (_PS_MODE_DEV_ à true dans config/defines.inc.php), puis lancez tail -f var/logs/prod.log dans un terminal et reproduisez l'erreur dans le navigateur. Regardez la ligne qui apparaît à l'instant exact du plantage et lisez la trace de pile de haut en bas jusqu'à la première ligne pointant vers /modules/ ou /themes/, c'est souvent le coupable. Désactivez ensuite le mode debug ; il expose des chemins internes.

Pour le guide développeur complet, traces de pile, recettes grep et erreurs courantes, consultez notre guide de dépannage PrestaShop.

Security Scan est conçu pour fonctionner avec PrestaShop 1.7, 8 et 9 ainsi que PHP 7.1 et plus récent. Les APIs PrestaShop dépréciées sont encapsulées afin que le module se comporte correctement sur chaque branche prise en charge.

Oui. Notre PrestaShop Security Scanner public et gratuit identifie passivement toute boutique que vous possédez directement depuis son URL - version PrestaShop et PHP, risque de fin de vie et en-têtes de sécurité HTTPS - en quelques secondes, sans rien installer. Il lit seulement ce que tout visiteur voit déjà. Installez le module lorsque vous voulez le scan profond et privé de vos modules, fichiers et permissions.

Security Scan est gratuit et sert uniquement à la détection : il trouve les problèmes, note votre boutique de 0 à 100 et affiche les étapes de correction manuelles. Security Revolution agit sur les mêmes résultats - corrections en un clic, durcissement de la boutique, surveillance de l’intégrité des fichiers core, alertes de changement et gestion d’un parc de boutiques depuis un tableau de bord. Commencez avec Security Scan ; passez à la suite quand vous voulez automatiser les corrections et la surveillance.

Non. Un scan autonome depuis le tableau de bord ou la CLI reste entièrement sur votre serveur : le rapport est généré localement et les seules requêtes sortantes sont des auto-contrôles vers vos propres URLs publiques, protégés contre l’accès aux adresses internes (SSRF). Rien ne nous est envoyé. Si vous activez explicitement le connecteur fleet optionnel, les résultats de scan sont envoyés - via un canal signé - uniquement au hub que vous avez configuré.

Oui. Security Scan sert uniquement à la détection : il lit vos fichiers, votre configuration, votre base de données et vos propres URLs publiques. La seule chose qu’il écrit est son propre historique de scan. Il ne modifie jamais les fichiers, réglages, produits, commandes ou clients de la boutique, vous pouvez donc l’exécuter sur une boutique en production à tout moment, sans risque.

Ces quatre erreurs HTTP sont celles que rencontrent le plus souvent les marchands PrestaShop. Voici ce que chacune signifie et où regarder d'abord.

403 Forbidden, le serveur refuse la requête, presque toujours un problème de droits ou de règle d'accès. Réinitialisez les permissions (755 pour les dossiers, 644 pour les fichiers), vérifiez le .htaccess pour des règles Deny trop larges, et consultez les logs WAF/ModSecurity pour les faux positifs.

404 Not Found, l'URL ne pointe vers rien. Le plus souvent les URL simplifiées sont activées mais .htaccess/mod_rewrite ne génère pas les réécritures : allez dans Paramètres de la boutique → Trafic & SEO, confirmez les URL simplifiées et enregistrez pour régénérer. Supprimer un produit sans redirection 301 (ex. un ancien /exemple-produit.html) laisse aussi des 404.

500 Internal Server Error, une faute côté serveur, le plus souvent une erreur fatale PHP, un .htaccess invalide, une mauvaise version de PHP pour votre installation, un échec de connexion à la base, ou un module défaillant. Diagnostic le plus rapide : passez _PS_MODE_DEV_ à true dans config/defines.inc.php pour voir l'erreur réelle (remettez-le ensuite), puis vérifiez le log PHP et les logs PrestaShop dans var/logs/. Désactivez un module récent en renommant son dossier via FTP.

503 Service Unavailable. Le serveur ne peut pas répondre pour l'instant. Causes habituelles : mode maintenance resté actif (Paramètres de la boutique → Général → Maintenance), un drapeau de maintenance laissé après une mise à jour, ou une surcharge serveur lors d'un pic de trafic.

Pour des 500/503 persistants, notre module Performance Revolution réduit la charge backend via le cache et la gestion d'OPcache. Pour le détail pas à pas, voir notre guide de débogage PrestaShop.

Non - ce module est conçu uniquement pour la détection. Il repère rapidement les risques courants et connus, puis vous indique exactement comment corriger chacun d’eux à la main. Les corrections automatiques en un clic, le durcissement et la surveillance se trouvent dans Security Revolution.

La plupart des rapports de déconnexions aléatoires, paniers vides et boucles de connexion admin viennent de la configuration cookies/sessions. PrestaShop stocke des états importants comme le client, le panier, la langue et les données de connexion dans un cookie chiffré, tandis que PHP peut aussi conserver des données de session côté serveur. Si le cookie ne peut pas être lu, est limité au mauvais hôte, est rejeté par le navigateur ou devient trop volumineux, la boutique perd l'état entre les chargements de page.

Vérification rapide dans le navigateur

Browser DevTools > Application/Storage > Cookies

Domain: should match the canonical host, e.g. www.example.com or .example.com
Secure: true when the shop is HTTPS
HttpOnly: true for the main PrestaShop cookie
SameSite: Lax is common, but payment POST/3-D Secure returns may need None; Secure
Size: keep the main cookie below the browser 4096-byte limit
Host: do not mix www and non-www in the same checkout

Pourquoi les clients sont déconnectés

• La clé de cookie a changé : si _COOKIE_KEY_ ou la clé de chiffrement cookie plus récente a été écrasée pendant un déploiement, les anciens cookies deviennent illisibles et tout le monde est déconnecté. Restaurez la clé depuis une sauvegarde.
• Incohérence de domaine : les cookies définis pour example.com peuvent ne pas se comporter pareil sur www.example.com. Choisissez un hôte canonique et redirigez l'autre avant que PrestaShop ne traite la requête.
• Incohérence SSL : si la boutique bascule entre HTTP et HTTPS, les cookies sécurisés peuvent ne pas être envoyés. Forcez HTTPS de manière cohérente.
• Cookie trop volumineux : PrestaShop rejette les payloads de cookie trop gros, car les navigateurs limitent les cookies autour de 4096 octets. Les modules ne doivent pas stocker de grands tableaux ou de données de debug dans le cookie.
• Incohérence de stockage de session : sur plusieurs nœuds web, les sessions basées sur fichiers nécessitent des sessions persistantes ou un stockage partagé comme Redis.

Panier vide après paiement

Si le panier disparaît uniquement après le retour depuis un fournisseur de paiement, testez toute la redirection de paiement avec DevTools ouvert. Les retours POST cross-site et les flux 3-D Secure peuvent être affectés par SameSite. Pour ces flux, le cookie peut nécessiter SameSite=None; Secure. Gardez HttpOnly et Secure activés.

Vérifications de cache

Après avoir modifié les réglages de domaine, SSL, cookies ou redirections, videz le cache PrestaShop, OPcache et tout CDN/cache pleine page. Les pages mises en cache sous l'ancien hôte ou protocole peuvent continuer à envoyer les clients vers le mauvais domaine et faire paraître un problème de cookie aléatoire.

GDPR

Le cookie session/panier PrestaShop est essentiel et ne nécessite pas de consentement marketing. Les cookies d'analytics, publicitaires, chat et tracking en ont besoin. Utilisez un module de consentement cookies ou une CMP qui bloque réellement les scripts non essentiels jusqu'au consentement ; une bannière qui charge quand même le tracking ne règle pas la conformité. Consultez notre guide GDPR et conformité cookies.

Quand PrestaShop est lent, MySQL est souvent le premier endroit à regarder : une seule page produit ou catégorie peut déclencher bien plus de cent requêtes SQL, et une requête non indexée ralentit toute la page. Le moyen le plus rapide de la trouver est de rendre les requêtes lentes visibles.

L’outil serveur classique est le MySQL slow query log. Définissez slow_query_log = 1 et un seuil long_query_time (commencez autour d’une seconde, puis baissez-le), et MySQL enregistre chaque requête trop longue, avec le nombre de lignes examinées versus renvoyées. Lancez EXPLAIN sur les pires cas : un scan complet type: ALL sur une grande table est le coupable, et un index ciblé le corrige généralement.

Si vous préférez ne pas toucher à la configuration serveur, MPR Performance Revolution peut profiler depuis l’intérieur de PrestaShop, mais la couverture dépend du chemin d’instrumentation. L’instrumentation intégrée installe un logger SQL Doctrine DBAL pour les composants Symfony/Doctrine ; la couverture complète des requêtes classiques PrestaShop Db nécessite l’installation de l’override optionnel de profiling base de données. Avec l’instrumentation pertinente active, le profiler peut afficher le nombre de requêtes, le temps total de requêtes, les requêtes les plus lentes avec nombre d’appels et texte SQL, ainsi que les hooks de module lents.

Le seuil de requête lente propre au module est séparé du seuil du log serveur MySQL. Son seuil par défaut est de 0.1 seconde, donc il peut attraper des requêtes lentes au niveau PrestaShop qui n’apparaîtraient jamais dans un slow log serveur réglé à 1 seconde. Il stocke les requêtes lentes dans sa propre table par hash de requête, incrémente le nombre d’occurrences pour les répétitions, et garde le contexte contrôleur et stack-trace afin que vous voyiez d’où vient la requête.

L’analyseur intégré exécute EXPLAIN et signale les problèmes courants : scans complets type = ALL, filesort, tables temporaires, clés possibles non utilisées, estimations de lignes au-dessus de 10000, SELECT *, recherches LIKE avec wildcard initial et conditions OR larges. Ces avertissements ne sont pas des corrections automatiques, mais ils vous indiquent s’il faut ajouter un index, réécrire une requête, réduire la charge de données d’un module ou archiver d’anciennes données.

Server slow log: best for database-wide slow SQL across everything using MySQL.
Performance Revolution built-in profiler: best for Doctrine/Symfony DBAL queries and module timing.
Performance Revolution optional Db override: needed for full classic PrestaShop Db query coverage.

Un grand nombre de déclinaisons produit peut ralentir à la fois le front-office et le back-office, car chaque déclinaison crée des lignes supplémentaires pour les attributs, le stock, les prix, les images et les associations boutique. Le vrai coût est multiplicatif : 6 tailles x 8 couleurs x 5 finitions font déjà 240 déclinaisons pour un seul produit.

Commencez par trouver les produits avec les plus gros ensembles de déclinaisons :

SELECT id_product, COUNT(*) AS combinations
FROM ps_product_attribute
GROUP BY id_product
HAVING combinations > 200
ORDER BY combinations DESC;

Vérifiez ensuite les lignes de stock pour les produits lourds en déclinaisons :

SELECT id_product, COUNT(*) AS stock_rows
FROM ps_stock_available
WHERE id_product_attribute <> 0
GROUP BY id_product
ORDER BY stock_rows DESC;

Les corrections courantes consistent à réduire les dimensions d'attributs inutiles, diviser les très gros produits configurables en produits séparés, éviter les déclinaisons pour les options qui n'affectent ni le prix ni le stock, et utiliser un module de configurateur pour les options sur commande au lieu de générer toutes les combinaisons possibles.

Vérifiez aussi les limites opérationnelles. L'enregistrement de gros formulaires de déclinaisons peut atteindre max_input_vars, post_max_size, memory_limit ou les timeouts de requête du serveur web. Les tâches de synchronisation de stock et les imports peuvent aussi devenir lents s'ils mettent à jour une par une des milliers de lignes de stock de déclinaisons.

Après de gros changements, reconstruisez les index de recherche et de recherche à facettes, videz le cache et vérifiez les slow query logs. Si Performance Revolution est installé, son profiler de requêtes peut aider à identifier si les requêtes de déclinaisons, de stock ou de navigation à facettes sont le goulot d'étranglement.

Un back-office PrestaShop lent a souvent une cause différente d'un front-office lent, donc profilez-le séparément. Commencez par une URL admin lente, mesurez dans DevTools Network si le délai vient du temps serveur ou des assets navigateur, puis parcourez modules, widgets de dashboard, base de données, cache et limites serveur.

Ce qu'il faut profiler en premier

• Modules : Module Manager, le dashboard et les pages de configuration peuvent charger des métadonnées de modules, des hooks, des autoloaders et des notifications externes. Déconnectez-vous d'Addons, désinstallez les modules inutilisés et testez sur staging si la page lente s'améliore avec les modules admin non essentiels désactivés.
• Widgets de dashboard : si seul le dashboard est lent, désactivez d'abord les widgets de statistiques, welcome/gamification et flux externes. Les widgets sont souvent plus lents que le shell admin principal.
• Base de données : vérifiez les requêtes lentes et les tables gonflées comme paniers, invités, connexions, logs, logs mail et sessions abandonnées. Nettoyez les anciennes lignes selon un planning, puis optimisez les grosses tables pendant une maintenance.
• Cache : assurez-vous que le mode debug est désactivé, que la compilation Smarty n'est pas forcée à chaque requête, que var/cache est inscriptible et qu'OPcache est activé pour PHP web. Videz et préchauffez le cache admin après les mises à niveau, mais ne laissez pas le back-office reconstruire le cache à chaque requête.
• Limites serveur : vérifiez le CPU steal, l'attente I/O disque, la pression mémoire, PHP-FPM pm.max_children, la taille du buffer pool MySQL et si le serveur swappe. Les hébergements mutualisés deviennent souvent lents aux heures chargées même si PrestaShop n'a pas changé.

Les causes les plus courantes

• La connexion Addons : certaines pages back-office contactent addons.prestashop.com pour les données de modules et notifications. Lorsque ce service est lent, l'admin peut attendre des timeouts. Se déconnecter d'Addons dans Module Manager supprime souvent les pires lenteurs.
• Mode debug laissé activé : la production ne doit pas tourner avec _PS_MODE_DEV_ activé. Le mode debug désactive ou affaiblit le cache et alourdit chaque requête admin.
• Trop de modules : les modules désactivés peuvent encore laisser des fichiers, hooks, onglets ou surcoûts d'autoload. Désinstallez ce que vous n'utilisez pas après avoir fait une sauvegarde.
• Pas d'OPcache : sans OPcache, PHP recompile de nombreux fichiers à chaque requête back-office.
• Base de données gonflée : les anciennes données opérationnelles ralentissent les grilles admin, statistiques et recherches.

Commandes rapides à demander à votre hébergeur

# PHP-FPM pressure
systemctl status php8.2-fpm
grep 'server reached pm.max_children' /var/log/php8.2-fpm.log

# Disk and memory pressure
free -m
vmstat 1 5
iostat -xz 1 5

# MySQL slow query log, if enabled
tail -f /var/log/mysql/mysql-slow.log

Performance Revolution aide avec le cache Redis, le cache de fragments/requêtes, le préchauffage du cache et les workflows de purge CDN, mais un ralentissement uniquement admin doit quand même être profilé. Si seul le dashboard est lent, supprimez des widgets. Si toutes les pages admin sont lentes, concentrez-vous d'abord sur OPcache, la capacité PHP-FPM, la latence de base de données et le coût des modules.

Security Revolution est un module de sécurité PrestaShop qui ajoute à votre boutique une couche de protection et de surveillance : il bloque les accès non autorisés, vous montre ce qui a changé, renforce les réponses et conserve des traces pour l'analyse après incident.

Accès et identité

• Authentification à deux facteurs (TOTP / Google Authenticator) pour les employés du back-office, avec suivi des sessions par utilisateur et possibilité de mettre fin à une session suspecte.
• Protection anti-force-brute : suivi des échecs de connexion, scoring d'IP et blocage automatique selon des seuils que vous définissez.
• Pare-feu configurable (autoriser / bloquer), avec blocage par pays ; chaque blocage enregistre le motif, le score et le pays, avec déblocage en un clic.

Intégrité et visibilité

• Surveillance de l'intégrité des fichiers, avec comparaison à une empreinte de référence et détection des écarts.
• Journal d'audit reliant les actions sensibles à l'IP, au pays et à l'employé ou client concerné.
• Scanner de vulnérabilités qui signale les réglages à risque : mode debug laissé actif en production, dossier install/ exposé, fichiers de sauvegarde exposés, version PHP visible dans les en-têtes.

Renforcement et exploitation

• Gestionnaire d'en-têtes de sécurité (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy) éditable depuis le back-office.
• Sauvegardes locales planifiées.
• Anti-abus e-mail : blocage des e-mails jetables et limites d'envoi.
• Moniteur de trafic avec analyse par pays et par bots/robots d'indexation.

Ce qu'il ne remplace pas : le durcissement au niveau serveur (pare-feu de l'hôte, fail2ban, correctifs OS), le HTTPS, un hébergement sûr, des mots de passe forts ou des sauvegardes hors site. Il les complète et rend visible l'activité à risque à l'intérieur de PrestaShop, là où la plupart des attaques réussissent une fois le périmètre franchi. Compatible avec les versions actuelles de PrestaShop.

Liste complète des fonctionnalités sur la page produit Security Revolution.

Non. Database Cleanup ne lance jamais de DELETE ouvert. Chaque tâche se termine par une clause LIMIT, donc une seule requête ne peut toucher qu’un nombre borné de lignes - c’est ce qui empêche un nettoyage de verrouiller vos tables pendant plusieurs minutes sur une boutique active.

Quand vous exécutez une tâche, le module répète le delete borné par lots et s’arrête à une limite de sécurité dure de 50 000 lignes par exécution. Si une table a plus que cela à nettoyer, l’espace de travail vous indique simplement de relancer la tâche - vous gardez le contrôle au lieu qu’une requête géante bloque la base. Les limites par tâche sont de 5 000 lignes pour paniers et prix expirés, et 10 000 pour statistiques de recherche, logs, connexions, enregistrements guest et logs mail.

Avant toute suppression, vous voyez le nombre exact de lignes pour chaque tâche, et une confirmation apparaît sur chaque action (le bouton run all avertit explicitement que les données ne peuvent pas être récupérées). Les tâches couvertes sont uniquement des données hors commandes : paniers abandonnés de plus de 30 jours qui ne sont jamais devenus commande, statistiques et logs de recherche de plus de 90 jours, règles de prix spécifiques expirées, anciennes connexions et guests orphelins, et entrées de log mail de plus de 30 jours.

Le nettoyage des paniers abandonnés fait explicitement un left join sur les commandes et ne retire que les paniers sans commande. Les statistiques de recherche utilisent statssearch, les logs utilisent log, l’historique visiteur utilise connections, les visiteurs orphelins utilisent guest, les logs mail utilisent mail, et les remises expirées utilisent specific_price lorsque la date de fin n’est pas la valeur ouverte 0000-00-00 00:00:00 et qu’elle est déjà passée.

L’écran d’intégrité utilise des seuils d’avertissement plutôt que de supprimer automatiquement : par exemple, paniers abandonnés après 1 000 lignes, guests après 5 000, logs après 10 000, connexions après 20 000, mail après 2 000 et stats de recherche après 50 000. Les réparations appellent les mêmes tâches de nettoyage bornées, donc le chemin de réparation d’intégrité suit les mêmes limites de sécurité que l’espace de travail.

C’est bien plus sûr que lancer du SQL brut à la main, mais la règle standard reste valable : sauvegardez votre base de données avant tout nettoyage sur une boutique live. Pour une suite de maintenance plus large qui couvre aussi images, cache et restes de modules, voir Cleanup Revolution.

reCAPTCHA & hCaptcha Protection ajoute une validation CAPTCHA aux formulaires front-office PrestaShop réellement ciblés par les bots, afin que les soumissions spam et créations de comptes automatisées soient arrêtées avant de vous atteindre. Chaque formulaire a son propre interrupteur on/off, donc vous pouvez protéger la connexion mais laisser le formulaire de contact ouvert, ou l’inverse.

Formulaires protégés (interrupteur par formulaire) :

• Formulaire de contact
• Connexion client
• Inscription client / création de compte
• Inscription newsletter

Le widget d’inscription est rendu via le hook du formulaire compte client. Le placement du consentement GDPR est spécifique au formulaire de contact : il est limité au contrôleur contact/module contactform et rend le widget CAPTCHA de contact là-bas.

Providers (un seul actif à la fois, modifiable sans réinstallation) :

• Google reCAPTCHA v2 - la case classique I am not a robot.
• Google reCAPTCHA v3 - invisible ; il score chaque interaction et vous définissez le seuil de score (0.5 par défaut ; plus haut est plus strict) sous lequel une requête est rejetée.
• hCaptcha - une alternative orientée confidentialité pour les boutiques qui préfèrent ne pas envoyer de données de trafic à Google.

La configuration se fait entièrement dans le Back Office : menu déroulant provider, champs site key et secret key, interrupteurs par formulaire, seuil v3, et contrôles de configuration qui vous avertissent quand des clés manquent afin que la protection ne soit pas silencieusement inactive. Compatible avec les versions PrestaShop actuelles.

Les valeurs par défaut d’installation sont volontairement inactives jusqu’à configuration : ENABLED=0, provider recaptcha_v2, site et secret keys vides, formulaires protégés définis sur contact,registration, seuil v3 0.5, fallback v3-to-v2 désactivé, et chargement conditionnel des scripts désactivé. Après ajout des clés et activation du module, la validation s’exécute côté serveur avant que l’action du formulaire concerné continue.

Pour v3, le module poste le token vers l’endpoint de vérification Google et compare le score renvoyé à votre seuil. Si le fallback v2 optionnel est activé et que les clés de fallback sont présentes, un score v3 bas stocke un flag de fallback court et demande au visiteur de compléter un challenge v2 checkbox au lieu d’échouer immédiatement. hCaptcha utilise l’endpoint de vérification hCaptcha et lit h-captcha-response ; les providers Google lisent g-recaptcha-response.

La couverture des thèmes a deux couches. Le module utilise les hooks de formulaire PrestaShop normaux quand ils existent, et un injecteur footer peut placer un widget avant les boutons submit pour des sélecteurs legacy courants quand un thème n’expose pas le hook idéal. Le chargement conditionnel des scripts peut garder les scripts provider hors des pages sans formulaires protégés, mais il est désactivé par défaut pour compatibilité avec les thèmes legacy.

Voir le walkthrough complet sur la page produit reCAPTCHA & hCaptcha Protection.

Oui, et dans Cleanup Revolution c'est le réglage par défaut. Quand le nettoyage d'images retire un fichier orphelin (une image sur le disque sans enregistrement correspondant en base), le mode corbeille la déplace dans un dossier corbeille daté de votre répertoire d'images (img/_cleanup_trash/AAAA-MM-JJ/) au lieu de la supprimer. En cas de conflit, les fichiers sont renommés : rien n'est écrasé.

Cela vous laisse une fenêtre de récupération : si un scan signale une image dont vous avez encore besoin, elle est dans le dossier corbeille et peut être restaurée en la replaçant. La durée de rétention est un réglage configurable (30 jours par défaut), et vous videz vous-même le dossier corbeille quand vous n'avez plus besoin des fichiers. Si vous préférez vous passer du filet de sécurité, désactivez le mode corbeille et le nettoyage supprime les fichiers directement.

Le scan d'images couvre les dossiers d'images produit, catégorie, fabricant et fournisseur, et chaque exécution est inscrite au journal des actions avec le nombre de fichiers, l'espace libéré et l'auteur du déclenchement. Ce comportement corbeille-et-restauration concerne les fichiers images ; les suppressions en base sont gérées à part, avec un aperçu dry-run et une double confirmation, et ne sont pas réversibles. Côté base, la règle reste donc de sauvegarder d'abord.

Cleanup Revolution est la suite de maintenance plus large : outre les images, elle gère les tâches de base de données, le cache et les fichiers temporaires, la détection de doublons (produits, catégories, caractéristiques, attributs) et les dossiers laissés par des modules retirés, avec automatisation cron et journal d'audit. Elle est multiboutique. Pour un nettoyage uniquement base de données, il y a le module plus simple Database Cleanup.