Image de remplacement sur 404

Le problème

Un visuel absent du disque ne devrait pas coûter un rendu de page complet.

PrestaShop renvoie vers son point d'entrée toute URL qui ne correspond à aucun fichier. Pour une image manquante, il instancie donc le contrôleur « page introuvable », qui rend la page 404 entière : le thème, l'en-tête, le pied, les requêtes de menu, de panier, de devises.

Une page qui demande cinquante visuels absents fait rendre cinquante fois la page 404 — environ 2,5 Mo de HTML et cinquante sessions ouvertes.

Le gain, mesuré

Sur PrestaShop 9.0.3 neuf, même boutique, même URL, module désinstallé puis installé :

	sans le module	avec le module
une image absente	50 858 à 51 053 octets de HTML	971 octets, ou 43 sans image de remplacement
un script, un style, une police	50 858 à 51 053 octets de HTML	0 octet
cookie de session envoyé	1 par requête	aucun
mise en cache	interdite	une minute
consigne aux moteurs	absente	ne pas indexer

Le module se greffe sur la première ligne de l'initialisation du contrôleur de boutique. Si l'URL demandait une image, il répond une image minuscule et sort : ni thème, ni devises, ni une seule requête du rendu.

Ce qu'il fait exactement

URL demandée	Réponse
.png, .jpg, .jpeg, .gif, .webp, .avif, .ico, .bmp	404 et votre image de remplacement, sinon un pixel transparent de 43 octets
.svg	404 et un SVG vide et valide — jamais un GIF annoncé comme un SVG
.js, .css, .map, .woff, .woff2, .ttf, .eot, .otf	404, corps vide
tout le reste	le module ne fait rien : la page 404 habituelle s'affiche

La réponse est un 404, pas un 200 : l'image n'existe pas, et un moteur de recherche comme un contrôleur de liens doit pouvoir le voir.

Ce qu'il couvre, et ce qu'il ne couvre pas

Il agit sur les images de catégorie, de page CMS, de marque, de fournisseur et de boutique, les URL d'image directes — celles qu'emploient un contenu éditorial, un export, un courriel ou un flux — et les scripts, styles, polices et cartes de source.

Il n'agit pas sur les images produit demandées par leur URL réécrite : PrestaShop sert déjà son propre substitut pour celles-là. Mesuré, un 200 de 64 585 octets. Le module ne s'en mêle pas.

Il ne voit pas les requêtes que le serveur web refuse avant PHP. Les dossiers img/, js/ et themes/ de PrestaShop portent chacun une liste d'extensions autorisées, et Apache confronte cette liste au premier segment de chemin manquant, pas au nom de fichier demandé. Un dossier intermédiaire absent donne donc un segment sans extension, donc un 403 qui n'atteint jamais le module.

Mesuré sur PrestaShop 9.0.3 : /themes/classic/assets/img/absent.jpg répond 403 parce que assets/img n'existe pas, là où /themes/classic/assets/css/absent.css — dont tous les dossiers existent — répond bien 404 avec un corps vide. Rien à corriger dans le module : c'est la configuration du serveur, et elle répond déjà court (277 octets, sans session).

Réglages

Back-office → Modules → *Image de remplacement sur 404* → Configurer.

• Répondre aux images et aux scripts, styles et polices : deux

interrupteurs indépendants.

• Image de remplacement : un chemin dans le dossier img/ de la boutique,

par exemple 404.gif ou cms/indisponible.png. Laissé vide, le module répond un pixel transparent qui ne déforme aucune mise en page — une balise d'image garde les dimensions que le style lui donne.

Si le chemin est refusé, le back-office le dit et nomme la raison, au lieu d'enregistrer en silence. Sont refusés : une sortie du dossier img/ (../, lien symbolique, chemin absolu — c'est le système de fichiers qui tranche, pas une lecture de la chaîne), une extension qui n'est pas une image, un .svg (il peut porter du script), un fichier illisible ou absent, et tout caractère de contrôle.

• Durée de cache : réglable de 0 à 3600 secondes. Une valeur longue fait

attendre un visiteur après la réparation d'un visuel ; zéro interdit la mise en cache.

Le module ne crée aucune table. Désinstallé, il retire ses quatre réglages.

Installation

Back-office → Modules → Installer un module → déposer le .zip, puis Configurer.