Regeneration d'images PrestaShop : quand et comment reconstruire les miniatures

Comment PrestaShop gere les images produit

Chaque image telechargee dans PrestaShop passe par un pipeline de traitement. Lorsque vous ajoutez une image de produit, le systeme stocke le fichier original puis genere plusieurs versions redimensionnees appelees miniatures (thumbnails). Chaque miniature correspond a un type d'image defini dans le back office sous Design > Reglages des images. Ces types d'images specifient des dimensions en pixels exactes et sont lies a des contextes specifiques : listes de produits, pages produit, apercu du panier, en-tetes de categories, logos de fabricants, et bien d'autres.

PrestaShop stocke les images dans le repertoire /img/. Dans PrestaShop 1.7 et 8.x, les images produit sont organisees selon une structure de repertoires basee sur l'identifiant de l'image. Par exemple, une image avec l'ID 1234 est stockee dans /img/p/1/2/3/4/. A l'interieur de ce repertoire, vous trouverez l'image originale (nommee selon l'ID, comme 1234.jpg) et toutes les miniatures generees (comme 1234-home_default.jpg, 1234-large_default.jpg, 1234-small_default.jpg).

La convention de nommage suit le schema : {id_image}-{nom_type_image}.{extension}. Cela signifie que chaque type d'image que vous definissez cree un fichier supplementaire pour chaque image produit de votre catalogue. Une boutique avec 5 000 images produit et 8 types d'images aura environ 45 000 fichiers image (5 000 originaux plus 5 000 fois 8 miniatures). Cette echelle est importante lorsque vous devez les regenerer.

Comprendre les types d'images

Les types d'images sont definis dans la table de base de donnees ps_image_type et geres via le back office. Chaque type d'image a un nom, une largeur, une hauteur et des indicateurs precisant a quels types d'entites il s'applique (produits, categories, fabricants, fournisseurs, magasins). L'installation par defaut de PrestaShop inclut plusieurs types d'images :

cart_default fait typiquement 125x125 pixels, utilise dans le panier et le mini-panier. small_default fait environ 98x98 pixels, utilise dans les listes de produits de certains themes. medium_default fait environ 452x452 pixels, utilise pour les miniatures de produits sur la page produit. home_default fait environ 250x250 pixels, utilise sur la page d'accueil et dans les listes de categories. large_default fait environ 800x800 pixels, utilise comme image produit principale sur la page produit.

Les themes peuvent definir leurs propres exigences en matiere de types d'images. Lorsque vous installez un nouveau theme, il enregistre typiquement ses types d'images preferes pendant l'installation. Le point crucial est que les fichiers image reels sur le disque doivent correspondre a ce que le theme attend. Si le theme demande home_default a 340x340 mais que vos fichiers image ont ete generes a 250x250 parce que vous utilisiez un theme different precedemment, chaque liste de produits affichera des images aux dimensions incorrectes.

Quand la regeneration d'images est necessaire

Plusieurs situations necessitent une regeneration complete ou partielle des miniatures. Comprendre quand elle est veritablement necessaire vous evite de lancer un processus qui peut prendre des heures sur de grands catalogues.

Changement de theme

C'est la raison la plus courante. Differents themes necessitent differentes dimensions d'images. Lorsque vous passez d'un theme a un autre, les templates du nouveau theme referent des types d'images avec des dimensions specifiques. Si ces dimensions ne correspondent pas aux fichiers miniatures existants, les images apparaissent etirees, recadrees incorrectement ou floues. Apres l'installation d'un nouveau theme, verifiez toujours ses exigences en matiere de types d'images et regenerez les miniatures en consequence.

Modification des dimensions d'un type d'image

Si vous modifiez la largeur ou la hauteur d'un type d'image existant via Design > Reglages des images, la modification n'affecte que la definition dans la base de donnees. Tous les fichiers miniatures existants sur le disque conservent leurs anciennes dimensions. Vous devez regenerer les miniatures pour le type d'image modifie afin d'appliquer les nouvelles dimensions aux images existantes.

Ajout d'un nouveau type d'image

Lorsque vous creez un nouveau type d'image, aucun fichier miniature n'existe encore pour celui-ci. Si un template reference ce nouveau type d'image, il affichera des liens d'images casses jusqu'a ce que vous regeneriez. Le processus de regeneration cree les fichiers miniatures manquants pour chaque image existante.

Problemes de qualite d'image

Si vous modifiez le reglage de qualite de compression JPEG dans PrestaShop (situe dans Performance > Reglages des images ou la section de configuration des images selon votre version), les miniatures existantes ont ete generees avec l'ancien reglage de qualite. La regeneration applique le nouveau niveau de qualite a toutes les miniatures.

Apres une migration ou un changement de serveur

Parfois lors d'une migration, les fichiers miniatures sont perdus ou corrompus alors que les images originales survivent. Si les images produit apparaissent cassees mais que les originaux existent dans les repertoires attendus, la regeneration recree toutes les miniatures a partir des originaux.

Activation du format WebP

PrestaShop 8.x a introduit le support WebP pour les images produit. Lorsque vous activez la generation WebP, les images existantes n'obtiennent pas automatiquement de variantes WebP. Vous devez regenerer les miniatures pour creer les versions .webp a cote des fichiers JPEG ou PNG existants.

Regeneration via le panneau d'administration

PrestaShop fournit un outil de regeneration integre dans le back office sous Design > Reglages des images (ou Preferences > Images dans les versions anterieures). En bas de la page, vous trouverez la section de regeneration.

Options disponibles

Vous pouvez choisir d'effacer les images precedentes avant la regeneration. Lorsque cette option est activee, PrestaShop supprime toutes les miniatures existantes avant d'en creer de nouvelles. C'est utile lorsque vous souhaitez supprimer les miniatures pour des types d'images qui n'existent plus, mais cela signifie que toutes les images seront indisponibles pendant le processus de regeneration. Lorsqu'elle est desactivee, PrestaShop ecrase les miniatures existantes et cree les manquantes sans rien supprimer au prealable.

Vous pouvez selectionner les types d'entites a regenerer : produits, categories, fabricants, fournisseurs ou magasins. Si vous n'avez modifie que les dimensions des images produit, il n'est pas necessaire de regenerer les images de categories ou de fabricants.

Limites de l'approche via le panneau d'administration

La regeneration via le panneau d'administration s'execute comme une requete web. Cela cree plusieurs problemes pour les grands catalogues. Les serveurs web ont des limites de temps d'execution, typiquement de 30 a 300 secondes selon votre configuration. Une boutique avec 10 000 images produit et 8 types d'images doit generer 80 000 fichiers miniatures. Meme a un rythme genereux de 10 images par seconde, cela prend plus de deux heures. La plupart des serveurs web interrompront le processus bien avant qu'il ne soit termine.

Les limites de memoire s'appliquent egalement. Chaque image doit etre chargee en memoire, redimensionnee avec GD ou ImageMagick, et sauvegardee. Les images originales haute resolution peuvent consommer 20 a 50 Mo de memoire chacune pendant le traitement. La limite de memoire par defaut de PHP de 128 Mo ou 256 Mo peut etre rapidement epuisee, surtout lors du traitement sequentiel des images sans nettoyage memoire adequate.

Si le processus est interrompu par un timeout ou une erreur memoire, vous vous retrouvez avec un catalogue partiellement regenere. Certains produits ont de nouvelles miniatures, d'autres ont les anciennes, et certains n'en ont peut-etre aucune. Cet etat inconsistant est pire que le probleme initial.

Regeneration en ligne de commande pour les grands catalogues

Pour les boutiques de plus de quelques centaines de produits, la regeneration en ligne de commande est fortement recommandee. Elle contourne les limites de timeout du serveur web et peut etre configuree avec des limites de memoire plus elevees.

Utilisation de la console PrestaShop

PrestaShop 1.7.5 et versions ulterieures incluent une console Symfony. Vous pouvez regenerer les miniatures en utilisant :

php bin/console prestashop:image:regenerate

Cette commande accepte plusieurs options. Pour regenerer uniquement des types d'images specifiques, utilisez l'option --image-type suivie du nom du type d'image. Pour traiter uniquement les produits, categories ou autres types d'entites specifiques, utilisez l'option --entity. L'option --format vous permet de specifier quels formats de sortie generer (jpg, png, webp).

Executez la commande depuis le repertoire racine de PrestaShop. Si vous utilisez Docker, executez-la a l'interieur du conteneur :

docker exec -u www-data votre-conteneur php bin/console prestashop:image:regenerate

L'option -u www-data garantit que les fichiers generes appartiennent a l'utilisateur du serveur web. L'execution en tant que root cree des fichiers que le serveur web ne peut pas servir ni modifier ulterieurement.

Configuration de la memoire et du temps

Pour l'execution en CLI, vous pouvez augmenter les limites PHP directement dans la commande :

php -d memory_limit=512M -d max_execution_time=0 bin/console prestashop:image:regenerate

Definir max_execution_time=0 supprime completement la limite de temps, et 512 Mo de memoire sont suffisants pour la plupart des catalogues. Pour les boutiques avec des originaux en tres haute resolution (4000x4000 pixels ou plus), vous pourriez avoir besoin de 1 Go ou plus.

Approche de regeneration personnalisee

Pour les tres grands catalogues (50 000 images ou plus), meme la commande console peut etre lente ou problematique. Une approche PHP personnalisee vous permet de traiter les images par lots avec suivi de la progression, gestion des erreurs et possibilite de reprendre apres une interruption.

L'approche consiste a interroger la base de donnees pour tous les enregistrements d'images, a les parcourir par lots de 100 ou 200, a generer les miniatures pour chaque image et a enregistrer la progression. Si le processus est interrompu, vous pouvez reprendre la ou il s'est arrete en verifiant quelles miniatures existent deja.

Une approche par lots vous permet egalement de repartir la regeneration sur plusieurs executions pendant les heures creuses, evitant tout impact sur les performances de la boutique en production.

Generation WebP pendant la regeneration

WebP est un format d'image moderne qui offre des tailles de fichier significativement plus petites que le JPEG a qualite comparable. PrestaShop 8.x peut generer des versions WebP des miniatures pendant le processus de regeneration.

Activer le support WebP

Avant de regenerer, activez WebP dans votre configuration PrestaShop. Dans PrestaShop 8.x, cette option se trouve dans les reglages des images. Lorsqu'elle est activee, le processus de regeneration cree a la fois la miniature JPEG/PNG traditionnelle et une version .webp pour chaque type d'image.

Exigences serveur

La generation WebP necessite soit l'extension GD compilee avec le support WebP (--with-webp), soit l'extension ImageMagick avec les delegates WebP. Vous pouvez verifier le support GD avec phpinfo() ou gd_info(). Cherchez le support WebP dans la sortie. Si le support WebP est absent, le processus de regeneration saute silencieusement la creation WebP sans produire d'erreurs.

Considerations d'espace disque

Les fichiers WebP sont typiquement 25 a 35 pour cent plus petits que les fichiers JPEG equivalents, mais vous stockez les deux formats. Une boutique avec 40 000 miniatures JPEG occupant 2 Go d'espace disque aura besoin d'environ 3,4 Go au total apres la generation WebP (les 2 Go originaux plus environ 1,4 Go de fichiers WebP). Planifiez votre espace disque en consequence avant de lancer une regeneration complete.

Servir le WebP aux navigateurs

Generer des fichiers WebP n'est que la moitie de la solution. Votre theme et votre serveur doivent etre configures pour servir le WebP aux navigateurs qui le supportent tout en retombant sur le JPEG/PNG pour les navigateurs qui ne le supportent pas. Cela est typiquement gere via des elements <picture> dans les templates du theme ou par la negociation de contenu cote serveur en utilisant l'en-tete Accept.

Dans Apache, vous pouvez ajouter des regles de reecriture qui verifient le support WebP et servent la version WebP lorsqu'elle est disponible. Dans Nginx, la directive try_files peut verifier l'existence d'une version .webp de l'image demandee et la servir si l'en-tete Accept du navigateur inclut image/webp.

Impact sur les performances et mesures d'attenuation

La regeneration d'images est gourmande en CPU et en I/O. Sur une boutique en production, elle peut degrader significativement les performances si elle n'est pas geree avec soin.

Impact CPU

Chaque operation de redimensionnement d'image necessite le chargement de l'original en memoire, l'execution de l'algorithme de redimensionnement, l'application des reglages de qualite/compression et l'ecriture du resultat sur le disque. L'operation de redimensionnement elle-meme est couteuse en calcul, particulierement pour les grandes images reduites en petites miniatures. Dans un environnement d'hebergement mutualise, cela peut saturer le CPU et ralentir l'ensemble de la boutique.

Impact I/O

La regeneration lit chaque image originale et ecrit plusieurs fichiers miniatures. Sur les disques durs traditionnels, cela cree une charge I/O significative. Sur le stockage SSD, l'impact est bien moindre mais reste perceptible a grande echelle. Le schema d'I/O est particulierement defavorable aux disques rotatifs car il implique des lectures aleatoires (originaux disperses dans les repertoires) combinees a des ecritures sequentielles (miniatures dans les memes repertoires).

Executer la regeneration pendant les heures creuses

Planifiez la regeneration pour votre periode de trafic le plus faible. Pour les boutiques europeennes, c'est typiquement entre 2h et 6h du matin. Pour les boutiques avec un trafic mondial, il n'y a peut-etre pas de veritable periode creuse, mais vous pouvez identifier des points bas relatifs a partir de vos donnees d'analyse.

Utiliser nice et ionice

Sur les serveurs Linux, vous pouvez reduire la priorite du processus de regeneration pour qu'il ne prive pas les autres processus de ressources. La commande nice reduit la priorite CPU, et ionice reduit la priorite I/O :

nice -n 19 ionice -c 3 php bin/console prestashop:image:regenerate

Une valeur nice de 19 est la priorite la plus basse. La classe ionice 3 est la classe inactive, signifiant que le processus n'obtient du temps d'I/O que lorsque rien d'autre n'en a besoin. Cela reduit considerablement l'impact sur la boutique en production mais allonge la duree de la regeneration.

Montee en charge temporaire

Si vous etes sur un serveur cloud, envisagez de monter temporairement en puissance votre serveur (plus de coeurs CPU, plus de RAM, stockage plus rapide) pendant la duree de la regeneration, puis de redescendre. Le cout supplementaire pour quelques heures de ressources superieures est generalement minime compare a l'impact d'une regeneration lente sur plusieurs jours sur les performances de votre boutique.

Eviter les timeouts pendant la regeneration

Les timeouts sont le probleme le plus courant avec la regeneration d'images. Voici les reglages et configurations specifiques qui les previennent.

Configuration PHP

La directive max_execution_time limite la duree d'execution d'un processus PHP. Pour l'execution en CLI, elle est typiquement deja definie a 0 (illimite), mais verifiez avec php -i | grep max_execution_time. Pour la regeneration web via le panneau d'administration, augmentez cette valeur dans votre php.ini ou .htaccess :

php_value max_execution_time 7200

Augmentez egalement max_input_time si vous utilisez le panneau d'administration, car le timeout de soumission de formulaire est separe du timeout d'execution :

php_value max_input_time 7200

Timeout du serveur web

La directive Timeout d'Apache et les directives proxy_read_timeout / fastcgi_read_timeout de Nginx peuvent mettre fin aux requetes longues meme si PHP lui-meme n'a pas expire. Pour Apache : Timeout 7200. Pour Nginx, ajoutez a votre bloc server : fastcgi_read_timeout 7200; ou proxy_read_timeout 7200;.

Configuration PHP-FPM

Si vous utilisez PHP-FPM (ce qui est le cas de la plupart des configurations modernes), le request_terminate_timeout dans votre configuration de pool peut egalement tuer les processus longs. Definissez-le a 0 pour desactiver le timeout, ou alignez-le sur votre duree d'execution maximale souhaitee :

request_terminate_timeout = 7200

Timeouts Cloudflare et CDN

Si votre boutique est derriere Cloudflare ou un autre CDN, le CDN a son propre timeout de requete (le plan gratuit de Cloudflare a un timeout de 100 secondes). Cela rend la regeneration via le panneau d'administration effectivement impossible derriere un CDN. Vous devez soit utiliser la regeneration en CLI, contourner le CDN pour l'acces admin, ou utiliser une solution qui traite les images de maniere asynchrone.

Strategies de regeneration incrementale

La regeneration complete traite chaque image du catalogue. Pour les boutiques avec des dizaines de milliers d'images, cela peut prendre de nombreuses heures. Les approches incrementales ne traitent que les images qui ont reellement besoin de nouvelles miniatures.

Regeneration selective par type d'image

Si vous n'avez ajoute ou modifie qu'un seul type d'image, vous n'avez pas besoin de regenerer tous les types d'images. Utilisez l'option --image-type dans la commande console pour cibler uniquement le type d'image specifique qui a change. Cela reduit le travail a un huitieme (ou la fraction correspondante de vos types d'images totaux) d'une regeneration complete.

Traitement base sur la date

Si vous devez regenerer les miniatures uniquement pour les produits recemment ajoutes (par exemple, apres avoir corrige un probleme de traitement d'images), vous pouvez interroger la base de donnees pour les images ajoutees apres une date specifique et ne traiter que celles-ci. La table ps_image n'a pas de colonne de date par defaut, mais la table associee ps_product a les champs date_add et date_upd qui peuvent etre utilises pour identifier les produits recemment modifies.

Detection des miniatures manquantes

Au lieu de tout regenerer, scannez les repertoires d'images pour trouver les images auxquelles manquent des miniatures specifiques et ne regenerez que celles-ci. C'est l'approche la plus rapide lorsque vous avez ajoute un nouveau type d'image ou lorsqu'une regeneration partielle a ete interrompue.

La logique est simple : pour chaque ID d'image dans la base de donnees, verifiez si le fichier miniature attendu existe sur le disque. S'il n'existe pas, regenerez uniquement cette miniature. Cela transforme une regeneration complete de plusieurs heures en un processus cible qui pourrait ne prendre que quelques minutes.

Traitement parallele

Pour les tres grands catalogues, vous pouvez diviser la plage d'ID d'images en segments et les traiter en parallele avec plusieurs processus PHP. Par exemple, un processus gere les ID d'images 1 a 10 000, un autre gere 10 001 a 20 000, et ainsi de suite. Chaque processus s'execute independamment, et le debit combine est approximativement proportionnel au nombre de processus paralleles (limite par les coeurs CPU et la bande passante I/O).

Soyez prudent avec le traitement parallele et les I/O disque. Executer trop de processus simultanement sur un disque dur traditionnel causera de la contention I/O et ralentira en realite les choses. Sur du stockage SSD, 4 a 8 processus paralleles fonctionnent typiquement bien.

Considerations sur les formats d'images

PrestaShop supporte JPEG, PNG et GIF comme formats source, et peut generer des miniatures dans ces formats plus le WebP. Le format source affecte le comportement de la regeneration.

Images JPEG

Le JPEG est le format le plus courant pour les photos de produits. Il supporte la compression avec perte, ce qui signifie qu'a chaque sauvegarde d'un JPEG, une certaine qualite est perdue. C'est pourquoi regenerer les miniatures a partir des televersements originaux produit de meilleurs resultats que regenerer a partir de miniatures precedemment redimensionnees. Assurez-vous toujours de travailler a partir de l'image originale televersee, pas d'une miniature precedemment generee.

Images PNG

Le PNG supporte la transparence et la compression sans perte. Si vos images produit utilisent des fonds transparents, les miniatures PNG preservent cette transparence. Cependant, les fichiers PNG sont typiquement beaucoup plus volumineux que les fichiers JPEG. Demandez-vous si vous avez reellement besoin de la transparence. Si ce n'est pas le cas, convertir les images produit PNG en JPEG pendant la regeneration peut reduire significativement l'espace disque et ameliorer les temps de chargement des pages.

Traitement des GIF

PrestaShop peut accepter les televersements GIF, mais les miniatures generees a partir de sources GIF sont statiques (l'animation n'est pas preservee). Si vous avez des images produit GIF animees, sachez que la regeneration produit des miniatures statiques a partir de la premiere frame.

Verification apres la regeneration

Apres la fin de la regeneration, verifiez les resultats avant de supposer que tout est correct.

Verification ponctuelle de la qualite des images

Ouvrez plusieurs pages produit et inspectez les images visuellement. Verifiez que les miniatures sont nettes, correctement proportionnees, et ni etirees ni pixelisees. Portez une attention particuliere aux images qui etaient originalement petites (proches ou inferieures aux dimensions des miniatures), car ce sont celles qui presentent le plus de risques de problemes de qualite lors de la mise a l'echelle.

Verification du nombre de fichiers

Comparez le nombre de miniatures generees avec les attentes. Si vous avez 5 000 images produit et 8 types d'images, vous devriez avoir environ 40 000 fichiers miniatures (plus les originaux et potentiellement les variantes WebP). Un nombre significativement inferieur indique que le processus de regeneration a ete interrompu ou a rencontre des erreurs sur certaines images.

Verification des permissions de fichiers

Verifiez que les fichiers regeneres appartiennent a l'utilisateur du serveur web (typiquement www-data sur Debian/Ubuntu ou apache sur CentOS). Si vous avez execute la regeneration en tant que root, les fichiers peuvent ne pas etre lisibles par le serveur web, causant des images cassees en frontend. Corrigez avec : chown -R www-data:www-data img/p/.

Vidage du cache

Apres la regeneration, videz tous les caches. Cela inclut le cache interne de PrestaShop (Parametres avances > Performances), tout cache d'opcode (OPcache), et tout cache CDN ou reverse proxy. Les anciennes pages en cache peuvent encore referencer d'anciennes URLs d'images ou d'anciennes dimensions. Si vous utilisez un module qui genere des sprites CSS ou des images en ligne, regenerez-les egalement.

Si votre boutique est derriere Cloudflare, purgez le cache pour le chemin /img/ ou effectuez une purge complete du cache. Cloudflare met les images en cache de maniere aggressive, et les visiteurs peuvent voir d'anciennes miniatures jusqu'a ce que le cache CDN expire ou soit purge.

Resolution des problemes courants de regeneration

Miniatures noires ou corrompues

Cela indique generalement un probleme avec la bibliotheque GD. L'extension GD peut ne pas supporter le format source (par exemple, GD compile sans support JPEG). Verifiez les capacites de GD avec gd_info(). Une autre cause est la memoire insuffisante : si PHP ne peut pas allouer assez de memoire pour charger l'image originale, GD peut produire une image noire au lieu de lancer une erreur.

Dimensions incorrectes dans les miniatures generees

Si les miniatures ont des dimensions inattendues, verifiez les definitions des types d'images dans la base de donnees. Le panneau d'administration peut afficher une valeur tandis que la base de donnees en contient une autre (cela peut arriver apres un import echoue ou une modification manuelle de la base de donnees). Interrogez directement : SELECT * FROM ps_image_type WHERE name = 'home_default';

La regeneration se bloque sans progression

Un processus de regeneration bloque signifie generalement qu'il a rencontre une image tres volumineuse qui a epuise la memoire disponible. Verifiez le journal d'erreurs PHP pour les echecs d'allocation memoire. La solution est d'augmenter la limite de memoire ou de pre-traiter les images sources problematiques pour reduire leur resolution avant la regeneration.

Erreurs de permission refusee

Si la regeneration signale des erreurs de permission, le processus PHP ne peut pas ecrire dans les repertoires d'images. Cela arrive frequemment dans les environnements Docker ou les volumes montes en bind ont une propriete differente a l'interieur et a l'exterieur du conteneur. Assurez-vous que l'utilisateur executant la commande de regeneration a un acces en ecriture a l'ensemble de l'arborescence du repertoire /img/.

Resume

La regeneration d'images est une tache de maintenance que chaque proprietaire de boutique PrestaShop rencontre, generalement lors d'un changement de theme ou de l'optimisation des reglages d'images. Pour les petits catalogues (moins de 500 produits), l'outil du panneau d'administration fonctionne adequatement. Pour tout ce qui est plus grand, la regeneration en CLI est la seule approche fiable. Les principes cles sont : toujours travailler a partir des images originales, faire correspondre vos definitions de types d'images aux exigences de votre theme, gerer proactivement les ressources serveur et les timeouts, utiliser des approches incrementales quand c'est possible, et verifier les resultats apres la fin du processus. Le WebP devenant le standard pour les images web, la regeneration sert egalement de mecanisme pour creer des variantes au format moderne de l'ensemble de votre catalogue de produits, offrant des tailles de fichier plus petites et des chargements de page plus rapides a vos clients.