Tester, relire et livrer un module PrestaShop

6.1Un banc de contrôle, pas des clics

En 2018, j'écrivais ceci, en ouvrant ma série de tests de plugins WooCommerce. « Proposer de découvrir un plugin, c’est bien. Le tester un peu, c’est déjà beaucoup mieux. »

Huit ans plus tard, je rajouterais une phrase : le tester à la main, c'est bien, le faire tester par un programme, c'est mieux !

Pour Markdown Twin, on a écrit un petit banc de contrôle, en Python, sans aucune dépendance. Je l'adore :D Tu lui donnes l'adresse d'une boutique et une liste de pages, et pour chaque page, il fait ce que ferait un agent d'IA, puis un navigateur, et il vérifie tout.

• La page HTML répond 200, porte l'en-tête Link et Vary: Accept, et contient la balise qui annonce son jumeau.
• Le jumeau répond 200, en text/markdown; charset=utf-8, avec X-Robots-Tag: noindex, follow, un lien canonical et un en-tête YAML complet. Son markdown_url est bien l'adresse demandée, et il n'a qu'un seul titre de niveau 1.
• La négociation répond en Markdown à Accept: text/markdown, et jamais avec un cache public.

Puis deux adresses à part, un produit qui n'existe pas (on attend une 404 en Markdown) et /llms.txt.

/blog/partez-en-roadtrip-c2
  ok     HTML 200
  [...]
  ok     négociation : Markdown
  ok     négociation : jamais en cache public
adresses à part
  ok     produit inconnu .md : 404 en Markdown
  ok     llms.txt 200 text/plain
  ok     llms.txt : titre et sections
  ok     llms.txt : liens vers les jumeaux
0 échec(s)

Fais le compte avec moi : huit pages par boutique, dont trois du blog de labo, 21 contrôles par page, plus les deux adresses à part. Ça fait 172 contrôles, sans un échec en 9.2.0, sans un échec en 1.7.8.11. Le code de sortie du banc est le nombre d'échecs, ce qui permet de le relancer après chaque modification sans même lire la sortie.

Le jour où quelque chose casse, tu le sais à la relance suivante, sur les deux versions ;)

6.2Installer le zip, comme le marchand

Pendant le développement, le dossier du module est branché dans les boutiques du labo. Mais ce n'est pas ce dossier que le marchand recevra, et j'insiste là-dessus. Il recevra un zip, et c'est ce zip qu'il faut essayer.

Le zip, on le fabrique à partir du dépôt git du module, avec une seule commande. Je n'en connais pas de plus fiable.

git archive --format=zip --prefix=markdowntwin/ -o dist/markdowntwin-1.0.0.zip HEAD:markdowntwin

--prefix=markdowntwin/ met tout dans un dossier markdowntwin, celui que PrestaShop attend en ouvrant l'archive. Et git archive ne prend que ce qui est enregistré dans git. Un fichier de test oublié dans le dossier, un réglage local, un config.xml créé par PrestaShop à l'installation, rien de tout ça ne part.

Puis je te conseille de l'installer par l'administration, exactement comme le fera le marchand. Modules › Gestionnaire de modules, bouton « Installer un module », et on dépose le zip.

6.3Les mises à jour, et le dossier upgrade

Tu te souviens de la pastille verte « Mise à jour disponible », sur la carte du module ? Elle s'allume quand la version du fichier est plus récente que celle enregistrée en base.

Et quand le marchand lance la mise à jour, que se passe-t-il ?

D'après le code du cœur, PrestaShop cherche dans le dossier upgrade/ du module des fichiers nommés upgrade-1.1.0.php, upgrade-1.2.0.php, etc. Il retient ceux dont la version est plus récente que celle installée, et pas plus récente que celle du fichier. Chacun contient une fonction au nom imposé, upgrade_module_1_1_0() pour la 1.1.0.

Et s'il n'y a aucun fichier ? Le code de la 9.2.0 a un commentaire qui dit tout : « No files upgrade, then upgrade succeed ». La mise à jour réussit, le numéro de version change… et c'est tout. Le nouveau crochet n'est pas enregistré, le nouveau réglage n'est pas écrit. On l'a vu au chapitre sur les réglages, avec une valeur par défaut qui n'a jamais atteint le labo.

Markdown Twin 1.0.0 n'a pas encore de dossier upgrade/. Pour une première livraison, il n'en a pas besoin : aucune boutique ne l'a. Dès la première nouvelle version qui ajoute un crochet ou un réglage, il en faudra un, sinon les boutiques qui mettent à jour se retrouvent avec un module à moitié branché.

6.4La relecture : trois défauts que le labo n'avait pas vus

172 contrôles verts, deux versions. On livre ?

Eh bien non !

On relit d'abord le code, avec un œil méchant, en se posant une seule question : « Ce module tient-il debout chez un marchand qu'on ne connaît pas ? » Et la réponse a été non, trois fois.

1. Le prix sort même quand la boutique le cache. Une boutique peut cacher ses prix. En mode catalogue, pour un groupe de clients qui n'a pas le droit de les voir, ou produit par produit. La page HTML les cache. Mais le tableau des faits du jumeau, son en-tête YAML et les lignes de /llms.txt lisent le prix directement sur le produit, sans se poser la question. D'après le code, un agent d'IA verrait donc un prix qu'aucun visiteur ne voit. Le cœur a pourtant ce qu'il faut. En 1.7.8.11 comme en 9.2.0, Configuration::isCatalogMode() regarde le mode catalogue, le groupe du visiteur et le pays, et chaque produit a sa propre valeur show_price.

2. Le sommaire liste des produits réservés. Une catégorie peut être réservée à un groupe de clients, des professionnels par exemple. /llms.txt liste les catégories et les produits par des requêtes SQL qui ne regardent pas ces restrictions. Un visiteur anonyme ne verrait pas la catégorie, mais l'agent la trouverait dans le sommaire.

3. Sans URL simplifiées, le jumeau se perd. Je te l'ai raconté au chapitre sur les routes. Plus de route en .md, et le lien de découverte devient /index.php.md.

Pourquoi le banc n'a rien vu ? Je te le donne en mille. Parce que la boutique de démo dit oui à tout ! Pas de mode catalogue, pas de groupe restreint, pas de produit masqué, les URL simplifiées actives. Le banc testait ce que la boutique de démo savait montrer, et elle ne savait pas montrer ces cas-là.

La conclusion est simple, et je la tiens, quitte à livrer plus tard : rien de tout ça ne part chez le marchand avant d'être corrigé, puis testé sur une boutique qui contient ces pièges : un produit masqué, un groupe restreint, le mode catalogue, une deuxième langue, les URL simplifiées coupées.

6.5Ce que je n'ai pas testé

Je préfère te le dire franchement plutôt que de te laisser croire que le module a tout vu.

• Le mode debug. Il change des comportements. Exemple lu dans le code de la redirection canonique de la 9.2.0 : en mode debug, au lieu de rediriger, PrestaShop affiche « [Debug] This page has moved ». Le module n'a pas tourné dans ce mode.
• Une boutique multilingue, ni le multiboutique. Les deux boutiques du labo sont en français seul.
• PHP 7.1, le plancher de la 1.7.8.11, et les versions intermédiaires (8.x, 9.0, 9.1).
• Le validateur de PrestaShop, sur validator.prestashop.com. Il demande un compte : « Use your existing seller account to log in and use the Validator. » Le module n'est pas destiné à la place de marché, on ne l'y a pas passé.

6.6Livrer : un zip, une licence, et le marchand qui installe

Je préfère être clair là-dessus, Markdown Twin pour PrestaShop n'est pas un module libre. Il est livré sous une licence d'utilisation de Kōeki, pour la boutique du client et ses copies de test, sans revente ni diffusion.

Un module propriétaire dans l'écosystème PrestaShop, ce n'est pas une exception. Le cœur est sous licence OSL 3.0 et les modules de PrestaShop sous AFL 3.0, mais le serveur MCP installé d'office en 9.2 est propriétaire, je l'ai relevé dans le dossier Installer PrestaShop.

Et l'installation, ce n'est pas nous qui la faisons, mais le marchand, sur sa boutique, avec le zip et le bouton « Installer un module ». On ne touche pas à sa production. On lui donne une notice, l'adresse d'une page à vérifier après installation (le .md de sa page d'accueil), et la liste de ce qui a été testé, et sur quelle version.

Un module PrestaShop, c'est un dossier, une classe et quelques crochets. Mais un bon module, c'est surtout un module qu'on a fait tomber au labo avant qu'il ne tombe chez le marchand ;)

Co-fondateur de Kōeki · Consultant SEO et IA

Sébastien Grillot

Consultant SEO depuis 2009 : c'est ici, sur Inside da WeB, qu'il a monté sa première agence, spécialisée dans l'e-commerce. Il construit aujourd'hui ses propres outils avec l'IA, modules PrestaShop compris.

Son parcours completDiscuter de ta boutique avec KōekimIAou, ma newsletter IA