Hummingbird : personnaliser le thème sans le casser

Il existe deux manières de personnaliser un thème Prestashop. La première consiste à ouvrir les fichiers du thème et à les modifier. Elle est plus rapide le premier jour, et coûte cher tous les autres jours. La seconde demande une demi-journée de mise en place et permet de suivre les mises à jour pendant des années.

Voici comment je m’y prends, et surtout pourquoi.

Le thème enfant, sans négociation

La règle fondatrice : on ne modifie jamais le thème d’origine. Un thème enfant hérite de tout et ne contient que les écarts. Les avantages sont immédiats et cumulatifs :

• la mise à jour du thème parent ne détruit plus votre travail ;
• l’écart entre le standard et votre boutique devient lisible — c’est le contenu du dossier enfant, rien d’autre ;
• reprendre le projet trois ans plus tard, ou le confier à quelqu’un d’autre, redevient possible.

Ce dernier point est celui qu’on sous-estime le plus. Un thème modifié en profondeur ne se documente pas : il faut le lire en entier pour savoir ce qui a été touché. Un thème enfant se lit en listant ses fichiers.

Surcharger un template, pas tout le thème

La tentation, quand un bloc ne convient pas, est de copier le template complet dans l’enfant pour y changer trois lignes. Ça fonctionne — et ça recrée exactement le problème qu’on voulait éviter : ce fichier ne bénéficiera plus jamais des corrections apportées en amont.

Avant de copier un template, je me pose la question dans cet ordre :

1. Est-ce que du CSS suffit ? Souvent oui. C’est la modification la moins invasive qui soit.
2. Est-ce qu’un hook existe ? Insérer du contenu via un hook laisse le template intact et survit aux mises à jour.
3. Est-ce qu’une variable de thème suffit ? Couleurs, espacements, rayons : beaucoup de choses se règlent sans toucher au balisage.
4. Sinon seulement, surcharger le template — et le noter, avec la date et la raison.

Cette dernière habitude paraît bureaucratique. Elle ne l’est pas : au moment de la migration suivante, la question posée pour chaque fichier surchargé sera « pourquoi ? ». Si personne ne sait répondre, on garde par prudence une modification devenue inutile, et la dette se perpétue.

La chaîne d’assets

Les thèmes récents viennent avec leur propre outillage de compilation. La tentation est grande de le contourner et d’ajouter une feuille de style à la main dans le head. Ça marche, et ça vous prive du reste : purge des styles inutilisés, préfixage, minification, cohérence des variables.

Prenez le temps de faire tourner la chaîne officielle. Une fois montée, elle ne demande plus rien, et votre CSS reste dans le même système que celui du thème plutôt qu’à côté.

Vérifier ce qu’on n’a pas cassé

Une personnalisation de thème casse rarement la page qu’on regarde — elle casse une autre page, qu’on ne regarde pas. Le tunnel de commande, en particulier, est un endroit où une régression visuelle se paie directement en chiffre d’affaires.

Ma liste minimale, à repasser après toute modification structurante :

• fiche produit avec déclinaisons, et fiche produit sans ;
• panier vide, panier plein, panier avec code promo ;
• tunnel complet jusqu’au paiement, en client connecté et en invité ;
• pages de compte : commandes, adresses, retours ;
• une page CMS, une page catégorie, une recherche sans résultat.

Dix minutes, à chaque fois. C’est le meilleur rapport temps investi sur ennuis évités que je connaisse.

Le critère qui tranche

Avant chaque modification, une seule question : est-ce que la prochaine mise à jour du thème va effacer ce que je suis en train d’écrire ? Si la réponse est oui, ce n’est pas la bonne façon de le faire. Il y en a presque toujours une autre, à peine plus longue, qui tiendra dans le temps.