Au-delà des fonctionnalités métier (chèques cadeaux, essais, FAQ, etc.), un site PrestaShop pour un vélociste a besoin d’un module socle. Celui qui contient les surcharges fines, les optimisations performances, les hooks transversaux et la configuration spécifique à la boutique.
C’est le rôle du module Veloland, qui orchestre l’écosystème sans pour autant tout faire lui-même.
Côté client : ce qu’il améliore en silence
Le client final ne sait pas que le module existe — il sent juste que le site est rapide. Concrètement :
- Toutes les images produits sont servies en WebP ou AVIF si le navigateur les supporte (fallback JPG sinon), via un override de
Link::getImageLink() - Le score PageSpeed reste élevé même sur les pages catégorie chargées en photos
- Les redirections internes respectent les URLs friendly (correctif d’un bug PS9 sur les ModuleFrontController)
- Le cookie session reste valide derrière Cloudflare (correctif
PS_COOKIE_CHECKIP)
Côté technique
Le module agit comme une couche de coordination plutôt que comme un module fonctionnel autonome. Il se branche sur plusieurs hooks PrestaShop pour intervenir de manière transversale sur le rendu et le routage du site.
Le hook overrideImageLink est utilisé pour injecter les variantes WebP et AVIF dans les balises <picture> rendues par PrestaShop, en complément du JPEG existant servi en fallback. Cette substitution s’effectue sans recopier la totalité de la classe Link, par simple ajout des sources alternatives à l’intérieur du markup produit. Un override de la classe Link est néanmoins maintenu pour la méthode getCatImageLink(), à laquelle l’override ajoute un paramètre extension qui manquait dans la signature native pour servir les images de catégorie au bon format.
Le hook actionFrontControllerInit configure quant à lui les en-têtes de cache pour les assets statiques, ce qui réduit les requêtes répétées au CDN. Le bootstrap du module déclare les configurations spécifiques à Veloland (numéros de téléphone, adresses des magasins, identifiants des partenaires Lorient Agglo), centralisées en un seul endroit plutôt qu’éparpillées dans le thème.
S’y ajoutent plusieurs correctifs ponctuels qui n’ont pas justifié la création d’un module séparé : une correction du canonical pour les ModuleFrontController en PrestaShop 9, ainsi qu’un override d’image_types afin de générer le format product_main_2x en 1440×1440 pixels pour les écrans haute densité.
Pourquoi un module socle plutôt que tout dans le thème
Un thème PrestaShop est mis à jour quand le design évolue. Un module reste stable même si le thème change. Mettre les overrides et hooks transverses dans le thème, c’est s’exposer à les perdre à la prochaine refonte. Dans le module socle, ils survivent à un changement de thème ou à une mise à jour PS9.
