Vider le cache PrestaShop, même sans accès au back-office

Un module installé, un thème retouché, et la boutique affiche encore l’ancienne version, ou plus rien du tout. Premier réflexe : vider le cache PrestaShop. Vos commandes, vos produits et vos clients n’y sont pas : ils sont dans la base de données, et le cache ne garde que des copies que PrestaShop sait refaire. Pour la même raison, vider le cache n’allège pas une boutique : pour l’alléger, il faut nettoyer la base de données PrestaShop.

La difficulté, c’est de savoir où. Le dossier change entre la 1.6, la 1.7, la 8 et la 9, et le bouton du back-office ne sert à rien quand le back-office ne s’ouvre plus. Les chemins ci-dessous sont relevés dans le code de chaque version.

Le bouton « Vider le cache » du back-office (Clear cache)

Le back-office ne s’ouvre pas ? Passez directement au FTP. S’il s’ouvre, le bouton reste la meilleure méthode : il vide plus de choses qu’un passage par FTP, sans risque d’effacer le mauvais fichier.

• 1.6 : Paramètres avancés > Performances, bouton « Vider le cache » dans la barre en haut de la page.
• 1.7, 8 et 9 : Configurer > Paramètres avancés > Performances, même bouton. Le message « Tous les caches ont été effacés avec succès » confirme l’opération.

Version	Ce que le bouton vide
1.6	Templates Smarty, listes de modules en cache, CSS et JavaScript combinés (CCC) du thème actif ; l’index des classes est régénéré.
1.7	La même chose, plus le cache Symfony du mode en cours (production ou debug).
8	La même chose, plus le cache Doctrine et OPcache, si l’hébergeur le permet.
9	Comme en 8, pour la production et le debug, et pour chaque application : administration, boutique, API.

Il faut aussi le droit « Supprimer » sur la page Performances (1.7, 8 et 9) : un employé au profil limité sera refusé. Sur une 9.0.0, le bouton laissait une partie du cache en place (anomalie #38139), corrigé en 9.0.1 : complétez par FTP, ou mieux, mettez à jour.

Inutile de cliquer après chaque module. En 1.7.8, 8 et 9, installer, désinstaller ou mettre à jour un module vide déjà le cache Symfony, et changer de thème vide le cache Smarty.

Si la page reste vide juste après le clic, rechargez une fois : le cas a été signalé sur la 1.7.6 (anomalie #16617). Toujours vide ? Ne recliquez pas, passez par FTP. Pour retrouver ensuite l’accès à l’administration, voyez back-office PrestaShop inaccessible.

Vider le cache PrestaShop manuellement, par FTP

Par FTP, ou par le gestionnaire de fichiers de votre hébergeur : les dossiers sont les mêmes. Sans back-office, on vide le cache manuellement, dans les fichiers. Un logiciel FTP comme FileZilla convient ; le gestionnaire de fichiers va souvent plus vite, car le cache compte beaucoup de petits fichiers.

Quelle version avez-vous ?

À la racine de la boutique	Version
un dossier var/	1.7.4 ou plus récente (8 et 9 compris)
un dossier app/, sans var/	1.7.0 à 1.7.3
ni app/ ni var/	1.6

Les dossiers à vider selon la version (cache/, app/cache, var/cache)

Version	Videz le contenu de	Gardez
1.6	cache/smarty/compile/ cache/smarty/cache/ et le fichier cache/class_index.php	les index.php
1.7.0 à 1.7.3	app/cache/prod/ app/cache/dev/	le reste de app/
1.7.4 à 9	var/cache/prod/ var/cache/dev/	le reste de var/
CCC 1.6	themes/votre-thème/cache/	index.php
CCC 1.7 à 9	themes/votre-thème/assets/cache/	le dossier lui-même

La marche à suivre

1. Repérez la racine de la boutique : le dossier qui contient config/, modules/ et themes/.
2. Ouvrez le premier dossier du tableau pour votre version, prod par exemple.
3. Sélectionnez tout ce qu’il contient, sauf index.php et .htaccess s’il y en a, puis supprimez. Faites de même pour l’autre dossier de votre ligne (dev, ou smarty/cache en 1.6) ; en 1.6, supprimez aussi le fichier cache/class_index.php.
4. Ouvrez la boutique, une seule fois. Le premier chargement est lent : PrestaShop reconstruit son cache. Laissez-le finir.
5. En cas d’erreur à ce premier chargement, rechargez une fois, pas davantage.
6. Vérifiez la boutique, puis le back-office. Si la panne est toujours là, voyez quand le cache n’y est pour rien.

Un override sans effet : l’index des classes

cache/class_index.php indique à PrestaShop où trouver chaque classe et chaque surcharge (override). Supprimé, il est recréé au chargement suivant. C’est le fichier à effacer quand un override déposé à la main n’est pas pris en compte : PrestaShop ne le détecte pas seul. De la 1.7 à la 9, même logique, mais l’index est rangé dans var/cache/prod/ (app/cache/prod/ de la 1.7.0 à la 1.7.3). Les overrides installés par un module, eux, mettent l’index à jour sans aide.

Ce qu’on ne supprime jamais

Les tutoriels se contredisent : certains font supprimer les dossiers prod et dev, d’autres seulement leur contenu. Nous vidons le contenu. PrestaShop recrée en général un dossier de cache manquant, à condition de pouvoir écrire dans le dossier parent ; garder le dossier évite d’en dépendre. Le reste de cette liste n’est pas du cache du tout.

• Le dossier var/ entier. À côté du cache, il contient les journaux (var/logs/), dont on a besoin pour comprendre une panne, et des éléments livrés avec PrestaShop : var/sessions/ et var/SymfonyRequirements.php, plus var/modules/ en 8 et 9, et var/class_stub.php depuis la 8.1.
• var/.htaccess. Il interdit l’accès à var/ depuis un navigateur. Sans lui, sur un serveur Apache, journaux et cache peuvent devenir lisibles par n’importe qui.
• Les index.php des dossiers de cache. Ils renvoient le visiteur ailleurs au lieu d’afficher la liste des fichiers.
• En 1.7 et plus, le dossier cache/ à la racine, tel quel. Le cœur de PrestaShop ne s’en sert plus (son fichier deprecated.txt le signale), mais il garde son .htaccess, qui en bloque l’accès, et ses index.php : le vider n’apporte rien.
• En 1.6, cache/cacert.pem (certificats des connexions sécurisées sortantes), le dossier cache/purifier/, et le dossier themes/votre-thème/cache/ lui-même (son contenu se vide, le dossier reste) : sans ces dossiers, la combinaison CSS/JS se coupe sans prévenir et le filtrage HTML perd son cache.
• app/config/ et config/. C’est la configuration de la boutique, accès à la base compris.
• img/, sauf img/tmp/. Ce sont vos images produits.

Pas de « chmod 777 » non plus pour faire taire un message d’écriture. Si PrestaShop ne peut plus écrire dans son cache, c’est le propriétaire des fichiers qu’il faut corriger, avec l’hébergeur.

En ligne de commande : bin/console cache:clear

Avec un accès SSH, une commande remplace le FTP. Elle se lance depuis la racine de la boutique. La 1.6 n’en a pas : passez par FTP.

• 1.7.0 à 1.7.3 : php app/console cache:clear --env=prod
• 1.7.4 à 9 : php bin/console cache:clear --env=prod
• 9, si vous utilisez l’API d’administration : en plus, php bin/console cache:clear --env=prod --app-id=admin-api

Quatre précautions avant de lancer la commande :

1. --env=prod n’est pas facultatif. Sans lui, la commande démarre PrestaShop en mode développement. Selon la version, elle vide alors le cache de développement au lieu de celui de la boutique, ou reconstruit celui de la boutique avec la configuration de développement.
2. En 9, l’option --app-id. La commande standard suffit pour la boutique et l’administration. Ajoutez --app-id=admin-api seulement si vous utilisez l’API d’administration, et --app-id=front seulement si le conteneur expérimental du front est activé (documentation développeur de PrestaShop 9).
3. Le bon utilisateur. Lancée en root, la commande recrée des fichiers que le site ne pourra plus modifier, et la boutique tombe un peu plus tard. Connectez-vous avec l’utilisateur propriétaire des fichiers du site ; en cas de doute, demandez à l’hébergeur sous quel utilisateur tourne le site.
4. En 1.7 et 8, la base doit répondre. La commande s’y connecte (anomalie #23887) : base en panne, commande en échec, et le FTP reste la seule voie.

Sur la 1.7.6, la commande ne reconstruisait pas toujours l’index des classes (anomalie #15610) : un override déposé à la main pouvait rester sans effet. Supprimez alors class_index.php (dans var/cache/prod/, ou app/cache/prod/ de la 1.7.0 à la 1.7.3), ou utilisez le bouton. Si la commande répond par des erreurs de syntaxe PHP, la version de PHP en ligne de commande n’est sans doute pas celle du site ; l’hébergeur vous dira laquelle appeler.

Les réglages du cache dans Performances : Smarty, CCC, mode debug

Si vous devez vider le cache après chaque modification, regardez d’abord les réglages de Paramètres avancés > Performances.

Smarty : « Compilation des templates » et « Cache »

• « Ne jamais recompiler les fichiers de templates » : une modification de fichier .tpl ne s’affiche qu’après un vidage. C’est la valeur par défaut d’une installation 1.6.
• « Recompiler les fichiers de templates s’ils ont été mis à jour » : la valeur par défaut de la 1.7 à la 9, celle que nous gardons en production, car une modification de template s’affiche sans vidage. En 1.6, l’aide du back-office conseille plutôt « Ne jamais recompiler » en production ; il faut alors vider le cache après chaque modification de template.
• « Forcer la compilation à chaque appel » : seulement le temps de travailler sur le thème. La documentation développeur de PrestaShop 9 chiffre à 30 % le gain sur le temps de chargement quand la compilation forcée reste coupée en production.
• « Cache » sur Oui, et « Vider le cache » sur « Vider le cache chaque fois qu’il y a une modification », la valeur par défaut. Avec « Ne jamais vider les fichiers du cache », les modules ne peuvent plus effacer leurs propres templates mis en cache.

En 1.6 et 1.7, un « Type de mise en cache » réglé sur MySQL range le cache Smarty dans la base, table smarty_cache (précédée du préfixe de vos tables). Le FTP n’y touche pas ; le bouton, si. L’option a disparu du formulaire en 8.

CCC : CSS et JavaScript combinés

Le bloc « CCC (Concaténation, Compression et mise en Cache) » regroupe les feuilles de style et les scripts du thème. Deux de ses réglages concernent ce cache : « « Smart cache » pour les feuilles de style » et « « Smart cache » pour le code JavaScript ». Coupés à l’installation jusqu’en 8, ils sont activés par défaut sur une installation neuve de la 9.

Un CSS modifié qui ne change pas à l’écran vient souvent de là. Le bouton efface ces fichiers, que PrestaShop recrée au chargement suivant ; par FTP, videz le dossier assets/cache/ du thème (cache/ du thème en 1.6). Si la mise en page casse juste après l’activation, désactivez les deux « Smart cache » (en 1.6 : « Conserver les CSS telles quelles » et « Conserver le JavaScript tel quel »), videz le cache et prévenez le développeur du thème.

Mode debug : un autre jeu de cache

De la 1.7.4 à la 9, passer « Mode debug » sur Oui fait tourner la boutique sur var/cache/dev/. Le cache de production n’est pas reconstruit pour autant : une boutique qui marche en debug et plante en production a souvent un cache prod abîmé, à vider. En 9, changer le mode debug vide tout le cache.

Sans back-office, le réglage est la constante _PS_MODE_DEV_ de config/defines.inc.php (ou de config/defines_custom.inc.php s’il existe). Passez-la à true quelques minutes seulement, puis remettez false : le mode debug affiche les erreurs PHP à l’écran, visiteurs compris.

« Utiliser le cache » : Memcached ou APC

Ce cache d’objets, désactivé par défaut, s’appuie sur un service du serveur : Memcached, APC ou Xcache (1.6 propose aussi un cache fichiers). Redis n’est pas dans la liste du cœur, il passe par un module. Le bouton « Vider le cache » ne purge pas ce cache-là. S’il provoque des erreurs, c’est un réglage à revoir avec l’hébergeur, pas un dossier à vider.

Les caches hors de PrestaShop : OPcache, Varnish, Cloudflare, navigateur

Le cache de PrestaShop est vide, et la boutique montre toujours l’ancienne version ? D’autres copies se trouvent entre vos fichiers et l’écran du client. Premier test, sans rien toucher : ouvrez la boutique dans une fenêtre de navigation privée. Si la modification y apparaît, seul votre navigateur est en cause (point 4). Sinon, on vide les autres caches dans cet ordre, du serveur vers le visiteur :

1. Un fichier PHP remplacé par FTP, et rien ne change : OPcache, qui garde le code PHP compilé en mémoire. Réglé sans revalidation (opcache.validate_timestamps=0, que la documentation de PrestaShop autorise en production), il exécute l’ancien code jusqu’à sa remise à zéro ou au redémarrage de PHP (documentation PHP). Le bouton le remet à zéro en 8 et 9, pas en 1.6 ni en 1.7 ; sinon, l’hébergeur redémarre PHP.
2. La page reste ancienne pour tout le monde, même cache vidé : un cache de pages placé devant la boutique par l’hébergeur, Varnish par exemple. Sa purge dépend de son installation : panel de l’hébergeur, module, ou demande au support.
3. La boutique passe par Cloudflare : Caching > Configuration > Purge Cache. « Custom Purge » vide seulement les adresses indiquées ; « Purge Everything » vide tout, et chaque visite repasse alors par votre serveur le temps que le cache se refasse (documentation Cloudflare). Le « Development Mode » suspend le cache trois heures, mais ne purge rien.
4. Vous seul voyez l’ancienne version : votre navigateur. Fenêtre de navigation privée, ou rechargement forcé (Ctrl+F5 sous Windows, Cmd+Maj+R sur Mac).

Quand vider le cache règle le problème, et quand il n’y est pour rien

Vider le cache ne répare que ce qui vient d’une copie périmée : un fichier modifié, ajouté ou déplacé que PrestaShop n’a pas encore pris en compte.

Vider le cache aide	Vider le cache n’aide pas
Module installé, mis à jour ou supprimé par FTP, et back-office en erreur	« Link to database cannot be established » : la base ne répond pas
Override déposé à la main, sans effet	« Allowed memory size » : mémoire PHP
Fichier .tpl ou CSS modifié qui ne change pas à l’écran	« Fatal error » qui cite un fichier de module : le module lui-même
Après une modification de app/config/parameters.php (1.7 et plus)	Écran vide qui revient après chaque vidage : voyez la page blanche PrestaShop
Boutique qui marche en mode debug et plante en production	Boutique lente : un cache vide la ralentit le temps qu’il se reconstruise
Back-office en erreur juste après une mise à jour de fichiers	Base de données trop lourde : le cache n’y est pas

Le message exact d’une erreur est dans var/logs/ (1.7.4 et plus) ou dans le journal de l’hébergeur. Notre diagnostic guidé de l’erreur 500 part de ce message.

Cas à part : un var/cache/dev/ qui grossit jusqu’à remplir le disque, rapporté sur le forum PrestaShop. Le vider rend de la place, mais il faut trouver pourquoi il grossit, un mode debug oublié par exemple.

Annuler ou réparer après un vidage

Un cache vidé ne se restaure pas : il n’y a rien à restaurer, PrestaShop le reconstruit. Les vrais retours en arrière concernent ce qui a été supprimé en trop.

• Un dossier de cache supprimé (prod, smarty/compile, cache du thème) : recréez-le vide, au même endroit et sous le même nom, avec les mêmes droits que ses voisins.
• Un index.php ou un .htaccess supprimé : reprenez le fichier dans l’archive officielle de votre version exacte, au même chemin.
• Le dossier var/ supprimé en entier : restaurez-le depuis une sauvegarde, ou copiez celui de l’archive officielle de votre version. Les anciens journaux sont perdus.
• Des droits passés en 777 « pour essayer » : remettez les droits d’origine et le bon propriétaire, avec l’hébergeur si besoin.
• Un réglage de Performances changé « pour essayer » (compilation forcée, CCC) : revenez aux valeurs données dans les réglages du cache, puis videz le cache.

Où s’arrêter : les gestes à ne pas faire seul

Après un vidage et un rechargement, si la panne est toujours là, un second vidage n’y fera rien. Arrêtez-vous avant ces gestes :

• Relancer la commande en root, ou « réparer » les droits avec chmod et chown sans savoir sous quel utilisateur tourne le site.
• Supprimer d’autres dossiers « pour voir » : var/, app/, config/, modules/. Ce n’est plus du cache.
• Insister quand le cache refuse de se vider. Un bouton qui échoue sur « Directory not empty » se contourne souvent par FTP (anomalie #20582). Si le FTP ne peut pas supprimer les fichiers non plus, c’est un problème de droits, de disque ou de serveur.
• Vider le cache pendant une mise à jour de PrestaShop, ou après une mise à jour arrêtée en route. Notez l’étape affichée et faites-vous aider.
• Chercher à alléger la boutique par le cache. Ce qui grossit, c’est la base de données : l’index des tables PrestaShop qui grossissent dit quoi vider, et comment, selon la version.

Avant l’un de ces gestes, appelez le 09 72 03 59 17 ou écrivez trois lignes dans le formulaire : réponse en moins d’une heure, 7j/7, de 8 h à 22 h, et un prix fixe validé avant toute intervention.

Questions fréquentes sur le cache PrestaShop

Comment vider le cache PrestaShop sans accès au back-office ?

Par FTP ou par le gestionnaire de fichiers de l’hébergeur : videz le contenu de var/cache/prod/ et var/cache/dev/ (1.7.4 à 9), de app/cache/prod/ et app/cache/dev/ (1.7.0 à 1.7.3), ou de cache/smarty/compile/ et cache/smarty/cache/, plus le fichier cache/class_index.php (1.6). Gardez les dossiers et les fichiers index.php.

Où se trouve le dossier cache de PrestaShop ?

Dans var/cache/ à la racine de la boutique depuis la 1.7.4, avec un sous-dossier prod et un sous-dossier dev. De la 1.7.0 à la 1.7.3, dans app/cache/. En 1.6, dans cache/. En 9, var/cache/prod/ contient en plus un sous-dossier par application (admin, admin-api, front), vidé avec le reste.

Peut-on supprimer le dossier var/cache en entier ?

Mieux vaut le garder, avec ses dossiers prod et dev. Videz seulement le contenu de var/cache/prod/ et var/cache/dev/ : il se supprime sans risque. Le reste de var/ n’est pas du cache : on y trouve les journaux et un .htaccess qui en bloque l’accès.

Vider le cache efface-t-il des commandes, des produits ou des clients ?

Non. Commandes, produits et clients sont dans la base de données ; le cache ne contient que des fichiers que PrestaShop sait recalculer. Le premier chargement après un vidage est plus lent, le temps que PrestaShop reconstruise son cache.

Quelle commande pour vider le cache PrestaShop en SSH ?

php bin/console cache:clear --env=prod depuis la racine, de la 1.7.4 à la 9 (php app/console de la 1.7.0 à la 1.7.3). Sans --env=prod, la commande tourne en mode développement et ne traite pas correctement le cache de la boutique. En 9, ajoutez --app-id=admin-api dans une seconde commande si vous utilisez l’API d’administration.

Comment vider le cache d’un module PrestaShop ?

Le bouton « Vider le cache » vide le cache Smarty, où se trouvent les gabarits des modules ; installer, désinstaller ou mettre à jour un module vide déjà le cache Symfony en 1.7.8, 8 et 9. Un module qui gère son propre cache peut se brancher sur le bouton : de la 1.7.8 à la 9, PrestaShop prévient les modules à chaque vidage. S’il ne le fait pas, cherchez l’option dans sa configuration ou demandez à son éditeur.

Pourquoi ma modification n’apparaît-elle toujours pas après avoir vidé le cache ?

Un autre cache la retient : OPcache sur le serveur, Varnish, Cloudflare ou votre navigateur. Vérifiez aussi le réglage « Compilation des templates » : sur « Ne jamais recompiler », chaque modification de template demande un vidage.

Combien coûte un dépannage si vider le cache ne suffit pas ?

Chez CYBERIAL, dès 150 € HT, prix fixe validé avant toute intervention ; ces 150 € sont déduits si vous passez ensuite à la maintenance. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h, au 09 72 03 59 17 comme par formulaire.

Vous préférez qu’on s’en occupe ?

Si vider le cache PrestaShop n’a rien réglé, décrivez la panne dans le formulaire ci-dessous : l’adresse publique de la boutique, votre version si vous la connaissez, ce que vous avez déjà vidé (bouton, dossiers, commande) et ce qui s’affiche depuis.

Choisissez « Mise à jour qui a tout cassé » si l’affichage a cassé après une mise à jour, un module ou un thème. Prenez « Erreur 500 / Page blanche » si la boutique ou l’administration affiche une erreur ou une page vide, « Site lent » si elle ralentit depuis un changement de réglage du cache, sinon « Autre ». N’écrivez ni mot de passe ni adresse d’administration dans le formulaire.

Pour aller plus vite que le formulaire, appelez le 09 72 03 59 17 (7j/7, de 8 h à 22 h). Une fois la boutique rétablie, pour un suivi régulier : maintenance PrestaShop à 69 € HT/mois, sans engagement.