Un blog plus statique
Un échange avec Bruno Adelé, qui fut l'initiateur du projet CaCause à une époque (déjà 5 ans) où les blogs statiques n'avaient pas d'autre alternative que Disqus, a titillé mon intellect. Bruno envisage de migrer son blog vers Hugo et d'utiliser le gestionnaire de commentaires staticman dont la particularité est de soumettre les commentaires par des pull-request GIT.
Cela m'a rappelé le projet Pecosys qui avait une approche similaire : les commentaires étaient partie intégrante du blog, publiés dans GIT sous forme de fichiers au format Markdown et convertis en HTML par le moteur de blog Pelican. La complexité de mise en oeuvre de Pecosys (un dépôt GIT privé, un e-mail dédié, un plugin spécifique pour Pelican) ont eu raison du projet. Deux ans plus tard, je codais Stacosys en simplifiant un peu les pré-requis système. Entre temps, des alternatives crédibles à Disqus avaient vu le jour comme Isso notamment. Stacosys est donc resté un projet personnel et depuis, il gère les commentaires de ce blog.
Dans Stacosys, les commentaires ne font plus partie des sources du blog. le navigateur Web du lecteur communique directement avec Stacosys via une API REST et une instance de Stacosys peut être partagée entre plusieurs sites par [des requêtes CORS](https://fr.wikipedia.org/wiki/Cross- origin_resource_sharing). Stacosys stocke les commentaires dans sa base de données et il ne fait plus de GIT. Contrairement à Pecosys (PElican COmment SYStem), Stacosys n'est pas lié à un moteur de blog particulier, il est facilement intégrable dans une page HTML par un peu de JavaScript.
Au vu de mon utilisation mono-site de Stacosys je me suis demandé si je ne pourrais pas revenir à une génération des commentaires en pages statiques. Cela apporte plusieurs avantages :
- une plus grande rapidité de navigation : au lieu d'ajouter les commentaires à la page en asynchrone par JavaScript, ils font partie de la page
- la capacité à supporter plus d'utilisateurs simultanés car le serveur HTTP ne sert que des ressources statiques
- plus de sécurité sur mon serveur grâce une surface d'attaque réduite : plus besoin d'une application HTTP REST accessible sur Internet
L'idée n'est pas réécrire Stacosys mais de pouvoir l'utiliser dans les deux cas de figure : mono-site et multi-site.
Le moteur de blog Hugo fournit une solution technique élégante à travers les data templates. Il s'agit de récupérer de l'information pendant la construction du blog pour enrichir les pages avec une information dynamique (qui peut changer à chaque build). On peut lire des fichiers JSON sur disque, ou mieux, faire des requêtes HTTP pour récupérer du JSON.
Ca tombe bien, Stacosys fournit une API REST qui renvoie du JSON :-) Ni une ni deux, j'ai adapté mes modèles pour que Hugo interroge Stacosys pendant sa phase de build et génère les articles en incluant les commentaires en fin de page.
Voici le template Hugo des commentaires qui utilise la fonction getJSON pour récupérer les commentaires de la page en cours :
<div id="stacosys-comments">
{{ $restParam := (printf "/comments?token=%v&url=%v" .Site.Params.widgets.stacosys_token .URL) }}
{{ $resp := getJSON .Site.Params.widgets.stacosys_url $restParam }}
{{ range $resp.data }}
<hr>
<div class="inline">
{{ if isset . "site" }}
<a href="{{ .site }}">
{{ end }}
<img src="http://www.gravatar.com/avatar/{{ .avatar }}.jpg" style="float:left; margin-right:10px" height="32" width="32">
{{ if isset . "site" }}
</a>
{{ end }}
<span class="title">{{ .author }}</span>
<span> - {{ .date }}</span>
</div>
<p>
{{ .content | markdownify }}
</p>
{{ end }}
</div>
et un exemple de données renvoyée par Stacosys :
{
"data": [
{
"author": "Bruno",
"avatar": "b97a3605714350fdad083394c974a9b4",
"content": "Ça donne effectivement envie de se laisser convaincre par un Librem. Le seul problème c'est que c'est déjà limite si j'ai un téléphone mobile et payer un tel prix alors que je pourrais pratiquement avoir un nouvel ordinateur au même montant, ça ne donne pas trop envie. Quand mon téléphone actuel cessera de fonctionner, peut-être que je choisirai plutôt de ne pas en racheter.",
"date": "2017-10-01 20:03:46"
},
{
"author": "Yax",
"avatar": "308a3596152a79231f3feedc49afa4ef",
"content": "Je comprends c'est pas mon budget téléphone non plus. Une alternative acceptable c'est le reconditionné de téléphones éprouvés et connus pour être bien supportés par les ROMs communautaires. Ça fait un peu d'écologie en prime.",
"date": "2017-10-01 22:20:37"
}
]
}
Il reste une interaction entre le serveur HTTP et Stacosys pour poster des commentaires via le formulaire mais on n'a plus besoin que Stacosys ait son nom FQDN propre et soit exposé sur Internet.
Le nouveau système ressemble à ceci :
Les sources complets sont sur mon Github.
C'est en place depuis le début de la semaine et je suis ravi du résultat. Combiné avec un Firefox Quantum pour la navigation ça roxe du poney !
Effectivement je réalise que j'ai pas fait d'effort de doc pour Stacosys comme j'avais fait pour Pecosys.
Basiquement, le projet dans sa branche master est celui que j'utilise : https://github.com/kianby/stacosys. Stacoys fonctionne à base d'e-mails pour approuver / refuser un commentaire. La gestion des e-mail est un composant que je partage avec d'autres projets, c'est géré par SRMail en branche 1.0.171104 : https://github.com/kianby/srmail/tree/1.0.171104. Attention, La version master de SRMail est en chantier, pas encore prête, je fais évoluer le projet vers une architecture plus teintée micro-service.
Du coup on a 2 services qui tournent tout le temps : stacosys et srmail. J'utilise supervisord pour gérer leur lancement.
Et enfin il y a le template hugo qui ajoute les commentaires à la page HTML générée et propose le formulaire : https://github.com/kianby/blog/blob/master/themes/hugo-pure-yax/layouts/partials/comments.html
Il y a encore un peu de JavaScript dans la gestion du formulaire mais, je pense moi aussi, à améliorer cela pour avoir une version qui fonctionne sans JavaScript. C'est en chantier, j'avance doucement, 1h par ci, 1h par là en week-end souvent.
Bon c'est assez touffu et mal documenté, si malgré tout tu veux y aller je peux faire du support sur par email : kianby@ sur le domaine du blog.
Merci de ton retour.
Salut,
Voila le blog est migré :) Y'a pas à dire Hugo est sacrément plus stable et plus rapide que pélican. Concernant stasticman, l’outil est pratique, Je vous le conseille, si vous voulez suivre vos commentaires sur un dépot git (pour ma part github, le plus facile à intégrer)
Le billet sous Hugo Migration de Pelican vers hugo
Salut Yax,
Hier j'ai lancé commie, un système de commentaires à peu près similaire à stacosys ou bien staticman — quand je l'ai écrit je ne connaissais pas stacosys, autrement je l'aurais peut-être utilisé.
Comme staticman, je met les commentaires dans le git de mon site (où le Pelican Comment System de Bernhard Scheirle les montre) — et comme stacosys, je laisse mon serveur envoyer des notifications email.
Je ne sais pas encore si mon système anti-spam — simplement demander une vérification du commentaire par email — va être suffisant.
Je vais regarder plus ce que tu fais avec stacosys. Il y aura peut-être des bonnes idées pour la prochaine version de mon système de commentaires.
@Thomas je suis très content que la famille des systèmes de commentaires pour sites statiques s'élargisse. J'ai décrit ma méthode rustique de modération dans cet article. Longue vie à commie.
Merci pour le billet :)
Comme toi je penche de nouveau à rebasculer les commentaires en statique, pour ne plus avoir vraiment besoin de Javascript sur le blog.
Aurais-tu une petite doc pour installer Stacosys sur Linux ?
Merci et au plaisir de te lire.