Boutiques en ligne
Deux boutiques PrestaShop composent ce projet : la première, qui vend un coffret mensuel par abonnement, est en service ; la seconde, une épicerie en ligne, n’a pas été publiée.
- Rôle
- Auteur unique
- Période
- Juin et septembre 2025
- État
- En service. Une boutique en service, une seconde arrêtée avant publication
- Technologies
- PrestaShop 8, PHP, MySQL, Docker Compose
- Dépôts
- Deux
Contexte
Il s’agit de deux travaux modestes : un PrestaShop standard, un thème enfant et un petit module pour chacun. La première boutique présente trois formules d’abonnement à un coffret mensuel. La seconde devait proposer un catalogue d’épicerie réparti en trois familles, et son développement s’est arrêté au bout de deux jours.
La boutique en service est Adanora ; le nom de la seconde ne figure pas dans cette étude.
Problème
PrestaShop se met à jour en remplaçant ses fichiers, de sorte que toute modification apportée au cœur ou au thème fourni est perdue à la mise à jour suivante. La page d’accueil de la première boutique demandait par ailleurs un bloc qu’aucun module standard ne fournit, à savoir trois déclinaisons d’un même produit présentées comme trois formules. Il fallait enfin décider de ce qui se versionne lorsque le dépôt contient l’arborescence entière d’un CMS.
Réponse apportée
Un thème enfant, aucune modification du cœur
Le thème enfant hérite des ressources du thème Classic et ne recopie que les gabarits qu’il modifie : l’en-tête, le pied de page, la fiche produit, la liste des produits et quelques blocs de la page d’accueil. Les gabarits des modules sont surchargés depuis le répertoire du thème, si bien qu’une mise à jour d’un module ne les efface pas.
Un module là où le thème ne suffisait pas
Le bloc des formules est un module d’une centaine de lignes, qui interroge la base pour obtenir les trois déclinaisons du produit et les transmet à un gabarit, que le thème surcharge à son tour pour les présenter en trois cartes. Le thème déclare ce module comme une dépendance, afin qu’il soit installé avec lui.
Savoir quoi versionner
La première boutique a d’abord versionné l’arborescence entière, soit plus de trente mille fichiers ajoutés en un commit, qu’il a fallu retirer ensuite en énumérant un à un les répertoires du cœur à ignorer. La seconde part de la règle inverse : tout ignorer, puis réintégrer les thèmes et le module. Cette règle est plus sûre, puisqu’un répertoire ajouté par une mise à jour reste ignoré, mais sa mise au point a tout de même demandé quatre commits.
Limites et perspectives
Le dépôt de la première boutique ne contient pas ce qui est en service : les gabarits, les polices et le module y sont pour l’essentiel hors version, et deux chemins de livraison coexistent sans qu’un document dise lequel fait foi. Il conviendrait de ramener ce code sous version avant toute autre évolution. L’identifiant du produit est par ailleurs inscrit dans le code du module, et les textes des formules figurent dans les gabarits, hors du système de traduction.
La seconde boutique n’a jamais dépassé l’ébauche : son module ne transmet pas ses données à son gabarit, son thème enfant se réduit à sa déclaration, et son catalogue est resté dans des fichiers qui n’ont pas été importés. Aucune des deux ne comporte de test ni de sauvegarde scriptée.