Configurer le cache des feuilles de styles CSS dans PrestaShop

Quand on modifie un fichier CSS dans PrestaShop et que rien ne change visuellement, le réflexe est de vider le cache du navigateur. Mais le problème est souvent plus profond : entre le cache serveur Apache/Nginx, la concaténation CCC de PrestaShop et les en-têtes HTTP d'expiration, plusieurs couches de mise en cache peuvent empêcher vos modifications d'apparaître.

Voici comment reprendre le contrôle sur le cache CSS de votre boutique, que vous soyez sur un serveur dédié ou un hébergement mutualisé.

Comprendre les couches de cache impliquées

Avant de chercher une solution, il faut identifier quelle couche bloque la mise à jour de vos styles.

1. Le cache navigateur

Le navigateur stocke localement les fichiers CSS selon les en-têtes Cache-Control et Expires envoyés par le serveur. Un simple Ctrl + F5 (hard refresh) ou la navigation en mode privé suffit souvent à contourner ce cache.

2. Le cache PrestaShop (CCC)

PrestaShop dispose d'un système natif appelé CCC (Combine, Compress, Cache) qui concatène et minifie les fichiers CSS en un seul fichier. Ce fichier porte un nom haché (par exemple d41d8cd98f00b204e9800998ecf8427e.css), ce qui signifie que votre modification d'un fichier source ne sera pas prise en compte tant que ce cache n'est pas régénéré.

Pour le désactiver ou le purger :

• **PrestaShop 1.6 / 1.7 :** Back-office → Paramètres avancés → Performance → Concaténation CSS (CCC)
• **PrestaShop 8.x :** Back-office → Configurer → Paramètres avancés → Performance → Section « CCC (Combine, Compress, Cache) »

// Désactiver temporairement le CCC en base de données
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_CSS_THEME_CACHE';
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_JS_THEME_CACHE';

Bonne pratique : Désactivez toujours le CCC pendant la phase de développement. Réactivez-le uniquement avant la mise en production.

3. Le cache serveur (Apache / Nginx)

Apache et Nginx peuvent eux-mêmes mettre en cache les fichiers statiques via les modules mod_expires ou mod_headers (Apache) et la directive expires (Nginx).

#### Redémarrer Apache pour forcer la purge

Sur un serveur dédié ou VPS sous Ubuntu/Debian :

# Méthode recommandée (graceful, sans coupure)
sudo systemctl reload apache2

# Alternative : redémarrage complet
sudo systemctl restart apache2

Sur CentOS / AlmaLinux :

sudo systemctl reload httpd

Pour Nginx :

sudo nginx -t && sudo systemctl reload nginx

Important : Un reload est toujours préférable à un restart. Le reload applique la nouvelle configuration sans couper les connexions actives.

4. Le cache de l'hébergement mutualisé

Sur un hébergement mutualisé (OVH, Ionos, o2switch…), vous n'avez pas accès au redémarrage d'Apache. C'est l'hébergeur qui gère le serveur web.

Dans ce cas, vos leviers sont limités à :

• **Purger le cache PrestaShop** via le back-office (Paramètres avancés → Performance → Vider le cache)
• **Désactiver le CCC** le temps du développement
• **Ajouter un paramètre de version** (cache busting) à vos fichiers CSS
• **Contacter le support** de l'hébergeur pour demander un purge du cache Varnish s'il y en a un

Technique de cache busting pour forcer le rechargement

Le cache busting consiste à modifier l'URL du fichier CSS pour que le navigateur le considère comme un nouveau fichier. Deux approches :

Via un paramètre GET (rapide)

Dans votre template Smarty (PrestaShop 1.6/1.7) :

<link rel="stylesheet" href="{$css_dir}custom.css?v={$smarty.now}">

En PrestaShop 8.x avec un module :

$this->context->controller->registerStylesheet(
    'module-monmodule-custom',
    'modules/monmodule/views/css/custom.css',
    [
        'media'   => 'all',
        'priority' => 200,
        'version'  => '1.0.' . time(), // Force le rechargement
    ]
);

Attention : N'utilisez time() qu'en développement. En production, utilisez un numéro de version statique que vous incrémentez manuellement à chaque release.

Via le renommage du fichier (méthode propre)

Renommez le fichier à chaque modification (custom-v2.css, custom-v3.css). C'est la méthode la plus fiable car certains proxies ignorent les paramètres GET sur les fichiers statiques.

Travailler sur un environnement de développement

Modifier du CSS directement en production est une pratique risquée. Quand le CCC, le cache serveur et le cache navigateur sont actifs simultanément, il devient quasi impossible de déboguer correctement.

Créer un environnement de développement

La bonne pratique est de dupliquer votre boutique sur un sous-domaine :

1. **Copier les fichiers** de la boutique vers un répertoire dédié :

cp -r /var/www/prestashop /var/www/dev-prestashop

1. **Dupliquer la base de données** :

mysqldump -u root -p prestashop_prod > dump_prod.sql
mysql -u root -p prestashop_dev < dump_prod.sql

1. **Mettre à jour la configuration** dans `app/config/parameters.php` (PS 8.x) ou `config/settings.inc.php` (PS 1.6) :

// Adapter le nom de la base de données
'database_name' => 'prestashop_dev',

1. **Mettre à jour les URLs** dans `ps_shop_url` :

UPDATE ps_shop_url 
SET domain = 'dev.monsite.com', 
    domain_ssl = 'dev.monsite.com' 
WHERE id_shop = 1;

1. **Désactiver tous les caches** sur l'environnement de développement :

UPDATE ps_configuration SET value = '0' WHERE name IN (
    'PS_CSS_THEME_CACHE',
    'PS_JS_THEME_CACHE', 
    'PS_HTML_THEME_COMPRESSION',
    'PS_JS_HTML_THEME_COMPRESSION',
    'PS_HTACCESS_CACHE_CONTROL'
);

1. **Configurer le virtual host** Apache ou Nginx pour `dev.monsite.com`.

Alternative moderne : Docker

En PrestaShop 8.x, l'approche Docker simplifie considérablement la mise en place d'un environnement local :

docker run -d \
  --name ps-dev \
  -p 8080:80 \
  -e DB_SERVER=host.docker.internal \
  -e DB_NAME=prestashop_dev \
  -e PS_DOMAIN=localhost:8080 \
  -e PS_ENABLE_SSL=0 \
  prestashop/prestashop:8.1

Cette méthode garantit un environnement isolé et reproductible, sans risque d'impact sur la production.

Configuration optimale du cache en production

Une fois vos modifications validées en développement, voici la configuration recommandée pour la production.

Dans le `.htaccess` (Apache)

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|png|jpg|svg|woff2)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>

Dans Nginx

location ~* \.(css|js|png|jpg|jpeg|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

Activer le CCC dans PrestaShop

Dans le back-office : Paramètres avancés → Performance → CCC activé.

Combinés à un système de versionnement correct de vos assets, ces réglages offrent le meilleur compromis entre performance et capacité de mise à jour.

Checklist de diagnostic

Quand vos modifications CSS ne s'affichent pas, suivez cette checklist dans l'ordre :

1. ☐ Hard refresh navigateur (`Ctrl + Shift + R`)
2. ☐ Tester en navigation privée
3. ☐ Vider le cache Smarty : supprimer `var/cache/prod/` et `var/cache/dev/`
4. ☐ Désactiver le CCC dans le back-office
5. ☐ Vérifier que le fichier modifié est bien le bon (attention au thème enfant)
6. ☐ Recharger Apache/Nginx (`reload`, pas `restart`)
7. ☐ Vérifier l'absence de cache CDN ou Varnish intermédiaire
8. ☐ En mutualisé : contacter le support hébergeur si rien ne fonctionne