Boutique PrestaShop de démonstration

À quoi ça sert

demo-shop-prestashop/ (dépôt demos/demo-shop-prestashop) est une boutique PrestaShop comme un client l’aurait : PrestaShop installé automatiquement, module Titreo E-Pay présent et pré-rempli des URLs publiques, back-office prêt. Ce que l’image ne fait jamais — coller la clé d’API et le secret de webhook — est précisément l’onboarding que la démonstration doit montrer : le marchand les obtient dans la console marchand et les colle dans Modules → Titreo E-Pay → Configurer.

En production, le module est embarqué dans l’image (/opt/titreo/modules/titreoepay, cloné depuis plugins/prestashop par la CI) et resynchronisé dans modules/ à chaque démarrage par init-scripts/20-titreo.sh, qui l’installe une fois et applique l’identité HTTPS de la boutique. En développement, le dossier plugins/prestashop/titreoepay/ est monté en volume : on modifie le module sur sa machine, le changement est immédiat.

Elle s’inscrit dans le même docker-compose.dev.yml que le reste de l’écosystème (api, checkout-page, consoles…). Voir l’environnement de dev local et la vue d’ensemble de l’écosystème.

Ce qu’il y a dans le dossier

Fichier	Rôle
`demo-shop-prestashop/Dockerfile`	`prestashop/prestashop:8.2.8-8.1-apache` + module embarqué (`ARG MODULE_SRC`) + `curl`, `rsync`, `remoteip`.
`demo-shop-prestashop/apache/titreo-proxy.conf`	Derrière Caddy : `X-Forwarded-Proto: https` → `HTTPS=on`. Le back-office Symfony ignore les en-têtes `X-Forwarded-*`.
`demo-shop-prestashop/init-scripts/20-titreo.sh`	À chaque démarrage : resynchronise le module, l’installe une fois, pré-remplit les URLs publiques, affirme le domaine et l’HTTPS. Ne touche jamais à la clé d’API.
`demo-shop-prestashop/init-scripts-dev/10-titreo-webhook-host.sh`	Correctif dev seulement pour que les webhooks serveur-à-serveur atteignent la boutique par son nom Docker — incompatible avec HTTPS, jamais dans l’image.
`demo-shop-prestashop/README.md`	Procédure de démarrage (production et dev).

Le service demo-shop-prestashop, la base MariaDB et le montage du plugin sont déclarés dans le compose racine app/docker-compose.dev.yml, aux côtés des autres briques. Le docker-compose.dev.yml cité dans le README de la brique renvoie en pratique à ce fichier racine (définition factorisée).

Lancer la boutique

La sandbox a besoin de sa base MariaDB (service à part). Depuis la racine app/ :

docker compose -f docker-compose.dev.yml up -d mariadb demo-shop-prestashop

Le service est configuré pour une installation automatique (PS_INSTALL_AUTO: 1, identifiants admin pré-remplis) ; le premier démarrage prend ~2 min le temps que PrestaShop s’initialise. Paramètres clés du conteneur :

Paramètre	Valeur
Front office	`http://localhost:3600`
Back office	`http://localhost:3600/admin-titreo` (`PS_FOLDER_ADMIN: admin-titreo`)
Compte admin	`admin@example.com` / `prestashop1!`
Base de données	hôte `mariadb`, base `prestashop`, user/mdp `prestashop`, préfixe `ps_`
Domaine canonique	`localhost:3600` (`PS_DOMAIN`)

Activer et configurer le plugin

Une fois la boutique en ligne, le module est déjà présent grâce au montage en volume — il reste à l’installer depuis le back-office.

Back-office (/admin-titreo)
 └─ Modules → Module Manager
     └─ chercher "Titreo E-Pay" → Installer
         └─ engrenage (Configurer)

Configuration attendue par le plugin (cf. README de la brique) :

Champ	Valeur en sandbox	Pourquoi
API base URL	`http://api:3000`	Nom de service interne du backend dans le réseau Docker.
API key	`tep_test_…`	Clé créée côté console admin.
Webhook secret	valeur copiée depuis la console marchand	Signe/valide les webhooks entrants.
Checkout page URL	`http://localhost:3100`	Page de paiement vers laquelle l’acheteur est redirigé (navigateur).

Points d’intégration

flowchart LR
    B["Navigateur acheteur"] -->|"front :3600"| PS["PrestaShop (demo-shop-prestashop)"]
    PS -->|"redirection paiement"| CP["checkout-page :3100"]
    PS -->|"API REST :3000 (réseau Docker)"| API["api"]
    API -->|"webhook serveur-à-serveur"| PS
    B -->|"retour confirmation"| PS

Cible du webhook

C’est le point le plus subtil de la sandbox. La console marchand (http://localhost:3500/webhooks) doit pointer vers la boutique par son nom de service interne, car c’est le conteneur api qui émet l’appel :

http://demo-shop-prestashop/index.php?fc=module&module=titreoepay&controller=webhook

Or PrestaShop redirige (301/302) toute requête dont l’en-tête Host diffère de son domaine canonique (localhost:3600), ce qui casserait la livraison du webhook (commande bloquée en « Confirmation en cours »). Le script init-scripts/10-titreo-webhook-host.sh corrige cela en dev : il écrit le hostname interne (demo-shop-prestashop) dans la colonne domain_ssl de la ligne principale de ps_shop_url. findShopByHost() matche alors la ligne principale sans rediriger pour les appels serveur-à-serveur, pendant que le navigateur continue d’utiliser localhost:3600. Le script est idempotent (rejoué à chaque démarrage).

Parcours de test complet

Front : http://localhost:3600 — ajouter un produit au panier, aller au checkout.
Étape paiement → « Carte bancaire », seul moyen proposé et déjà coché.
Redirection vers la checkout-page (:3100), compléter le paiement.
Retour sur la boutique : la commande est créée au retour (ou par le webhook s’il est passé avant), puis redirection directe vers la confirmation.

En production — `presta.<domaine>`

Tout passe par le dépôt deploy : tep presta setup écrit les variables (PRESTA_*, mots de passe générés), ajoute l’origine à CORS_ALLOWED_ORIGINS (la page de retour du module interroge l’API depuis le navigateur), active le vhost, démarre mariadb et prestashop (profil compose presta) et attend la fin de l’installation. Le webhook marchand se déclare sur l’URL publique de la boutique — en production, l’API refuse tout webhook en http:// ou vers une adresse privée. Voir le RUNBOOK de deploy, § 9quinquies.

Habillage Lumen

La boutique se présente comme une vraie enseigne de luminaires, Lumen. Tout est dans le dépôt demo-shop-prestashop et posé au démarrage par init-scripts/20-titreo.sh :

theme/lumen/ : thème enfant de classic. Identité (mot-marque, crème et laiton, Cormorant Garamond et Source Sans 3) et quelques gabarits surchargés : en-tête, pied de page, vignette produit.
catalogue/ : 32 produits (produits.json), photos Unsplash détourées sur un fond commun (images/, sources et auteurs dans sources.json), logo et favicon (marque/).
tools/detourer.swift : détourage par Vision (macOS 14+), pose sur le fond crème avec une ombre de contact. --suspendu pour une suspension, --garder 1,2 pour choisir les objets gardés.
seed/lumen.php : collections, produits, pages, modules, Titreo E-Pay seul moyen de paiement. Idempotent, rejoué quand sa constante VERSION change (--force pour le relancer à la main). Les anciens produits sont désactivés, jamais supprimés.
Module titreodemoskin 2.0.0 : sections de l’accueil, bandeau « Boutique de démonstration », ligne de pied de page et notes manuscrites par étape (views/js/notes.js). ?demo=off les masque pour des captures propres, ?demo=on les rétablit.

Limites

En dev : SSL désactivé, secrets en clair, correctif domain_ssl réservé au compose local.
Couvre l’intégration du plugin et le contrat de webhook ; pour la logique d’orchestration côté serveur, voir le Backend.