Invention de CaddyTailor

Les commencements

Gérer le contenu

Je ne vais pas revenir jusqu'à mon premier site internet personnel, cela nous ferait remonter bien trop loin, jusqu'au siècle précédent et j'avoue ne pas me rappeller de toutes les étapes qui m'ont mené jusqu'ici. Pour résumer, j'ai commencé à faire du HTML brut, bientôt matiné de PHP, avant de passer à b2evolution¹, un très ancien fork de WordPress qui a beaucoup évolué depuis. Cela fut suivi d'une longue période d'expérimentations variées. Et puis un jour, j'ai découvert Jekyll, une générateur de sites statiques fonctionnant à l'aide de templates et de fichiers textes simples (au format Markdown). Étant donné que mes sites consistent, pour l'essentiel, à présenter un contenu avec pas ou peu d'éléments dynamiques (peut-être remettrais-je un jour un système de commentaires et des statistiques...), la solution m'a parue séduisante. Je l'ai donc rapidement adoptée.

Mais Jekyll est écrit en Ruby, langage que je ne connais pas, ce qui enfreint un de mes critères de choix pour mes outils : préférer ceux qui sont écrits dans un langage que je maîtrise. Heureusement, le succès de Jekyll a été tel que des outils similaires ont bientôt vu le jour dans d'autres écosystèmes. Voilà comment j'ai adopté Sculpin. Et j'en fus satisfait quelques années...

Servir le contenu

J'ai longtemps laissé mon fournisseur d'accès héberger mon site. Mais j'ai finis par trouver la solution trop restrictive, et j'ai décidé de passer à l'auto-hébergement. J'ai alors longtemps utilisé Apache. Je suis ensuite passé à Lighttpd, un serveur web plus léger et que j'ai conservé longtemps. Je ne crois pas avoir jamais utilisé Nginx à titre personnel (si ce n'est dans des containers Docker). Et puis un jour j'ai découvert Caddy. La gestion automatique des certificats m'a immédiatement séduit. Je l'ai adopté et il s'est révélé depuis très pratique à utiliser à tout point de vue. À tel point que j'ai fini par lui consacrer un article élogieux dans Linux Pratique.

Durant les recherches qui accompagnaient la rédaction de cet article, j'ai découvert que Caddy embarque Go Template. Caddy est donc capable de servir un contenu défini de la même façon que les générateurs de sites statiques, mais sans passer par l'étape de compilation ! On peut ainsi créer des sites quasi-statiques avec des performances très proches, et la même sécurité (puisque le site est en lecture seule pour les visiteurs).

Naissance de CaddyTailor

J'étais très séduit par l'efficacité et l'élégance du procédé. J'explorais donc la solution de façon détaillée, en m'appuyant en particulier sur le code source du site officiel de Caddy. Mais après quelques expérimentations, je relevais un aspect méthodologique qui me posais problème. Depuis longtemps, j'ai pris l'habitude de gérer mes contenus en sous-domaines (voyez en bas de cette page), partageant le même thème sur plusieurs sites. En l'état, Caddy Templates ne permettait pas de le réaliser facilement : en effet, il fallait séparer la couche de présentation des données, ce qui est en soi une bonne pratique, mais le système n'était pas pensé pour cela : tout était mélangé allègrement.

J'eus alors l'idée de séparer données et templates dans deux dossiers distincts et de le faire fonctionner ensemble en n'ayant recours qu'aux possibilités offertes par Caddy. Cela ne fut pas une chose aisée. Mais après avoir un peu torturé la configuration de Caddy et développé un template routeur (je vois les cheveux de ce qui comprennent se dresser sur leurs têtes), je finis par atteindre mon objectif.

Arrivé là, il me semblait que la démarche pouvait être généralisée et qu'elle pourrait servir à d'autres. J'imaginais alors un framework ou un modèle pouvant servir de base aux développements de thèmes pour Caddy : CaddyTailor était né.

Je passais alors un bon moment à organiser les choses de façon à donner la souplesse requise. Je configurais un environnmenent Docker permettant à tout développeur de répliquer facilement l'environnement de travail et de découvrir la configuration de Caddy qui autorise ce fonctionnement. Je mis au point un système de configuration permettant de paramétrer le thème à partir du contenu, permettant ainsi le changement rapide de thème. Je créais un premier thème Base, très laid car dépourvu de mise en forme, mais qui montre que le concept fonctionne et comment. Je déclinais ensuite ce thème en deux versions BaseOnePage, destiné à réaliser des sites "OnePage", mais en gérant les différents contenus dans des fichiers Markdown distincts, les rendant plus faciles à manipuler ; et BaseOnePage2d, suivant la même idée, mais permettant une navigation horizontale sur certaines parties à la manière de sliders (dis comme ça, l'idée n'a pas l'air très convainquante, mais vous verez, je compte m'en servir bientôt, je vous dirai quand).

Nécessaire contribution à Caddy

Je rencontrais toute de même une difficulté que je ne parvenais pas ne parvenais pas à résoudre en utilisant seulement les templates Caddy : je voulais utiliser les dossiers comme des entrées de menus permettant d'accéder à des index présentant les fichies markdown comme des contenus. Mais les templates étaient incapables de différenciés dossiers et fichiers, quelque soit la façon dont je m'y prenne. La seule solution aurait été d'avoir recours à des directives de configuration laborieuses. Je posais à tout hasard la question à la communauté et je fus alors encouragé à contribuer.

Moi, coder en Go ? Je connaissais de réputation, mais c'est tout. Je n'avais même jamais vu le fameux "Hello World !" rédigé dans ce langage. Heureusement, j'ai été aimablement guidé, et le code source incluait déjà une fonction très proche de celle dont j'avais besoin. Après quelques échanges un peu laborieux, ma proposition fut amendée et adoptée. J'avoue que c'est pour moi un honneur d'être listé parmi les contributeurs d'un logiciel tel que Caddy. À l'heure où j'écris ces lignes, cette fonction n'est pas encore incluse dans la version stable (2.6.4). Mais pas besoin d'attendre la prochaine (2.7, qu'on m'a assuré être pour bientôt) pour explorer CaddyTailor : en effet, l'environnement Docker embarque la bonne version. Par contre si vous voulez l'utiliser autrement, il vous faudra compiler vous-même la branche master.

Retour aux thèmes

Dès lors, mon problème était réglé, je pouvais en toute confiance développer mes thèmes. Après avoir approfondi les trois premiers déjà existants, je me lançais dans la création de Pure, un portage depuis le thème que j'avais réalisé pour Sculpin. C'est celui que vous avez sous les yeux. J'en profitais pour y apporter l'une ou l'autre amélioration, mais je résitais à la tentation d'une refonte : en effet, il utilise Bootstrap, et j'ai très envie de le passer à TailwindCSS, mais ce serait pour une autre fois.

La suite

CaddyTailor manque encore cruellement de documentation. L'article que j'ai écris pour Linux Magazine, à paraître bientôt, racontant l'histoire que vous venez de lire mais d'un point de vue plus technique, n'y suffira pas : il n'est pas public pour commencer, et il n'aborde pas toutes les questions utiles. Il faudra donc que j'explique les choses un peu plus en détails.

J'envisage de créer un "faux" thème Core : d'un thème à l'autre, des fonctionnalités récurrentes apparaissent et il pourrait être intéressant de les factoriser... mais je crains que cela ne soit difficile, voire source de problèmes. Il faut encore que j'y réfléchisse.

En attendant, je vais déjà migrer mes différents sites perso. Cela ne devrait pas être trop difficile. Je vous tiendrai au courant.