De quoi s’agit-il ? Vulgarisation : un site statique est un site dont le contenu n’est pas réécrit par le serveur au runtime. A l’opposé, un site dynamique peut avoir son contenu qui change “tout seul”, ou du moins avec des mécanismes côté serveur. L’avantage des sites dynamiques c’est la flexibilité, au pris de vulnérabilités, un système plus complexe à administrer et maintenir. Un site statique au contraire ne va rien exécuter sur le serveur, il n’y a que le serveur web qui tourne (Apache dans mon cas), pas de PHP / Ruby / Python / JS ou autre, donc peu de surface d’attaque, plus léger, plus simple à maintenir, mais faire de modifications est moins pratique.
Quand j’ai monté mon blog en 2014 (le temps passe vite …) j’ai utilisé un CMS (Content Management System) pour me faciliter la vie. J’ai pris Dotclear parce qu’il me semblait plus simple et facile à gérer qu’un “gros” comme Wordpress ou Drupal. Mais même s’il n’est pas très lourd, c’est toujours un CMS, donc avec du code et des scripts qui tournent, une base de donnée, des problèmes de backup et de mise à jour …
Cela fait littéralement des années que j’envisage de passer mon blog en statique. J’en avais entendu les louanges, et je dois avouer que l’IT n’est vraiment pas quelque chose qui me motive, donc je ne fais pas les mises à jour souvent, et c’est un problème. Surtout que quand je mets Dotclear à jour, c’est à chaque fois la cata, ya plein de trucs qui ne marchent plus, et je galère à re-monter le blog, et le résultat est foireux et tient avec du scotch … Sans parler des backups qui sont aléatoires. Bref, je suis client d’une simplification drastique de mon infra.
Il y a plusieurs années, donc, j’avais identifié un outil pour m’aider à faire la bascule : Pelican
C’est un outil en Python dont on m’a dit du bien, qui a l’air relativement simple. Point positif : il dispose d’un convertisseur pour importer des articles de plusieurs CMS connus, dont Dotclear ! En plus, il permet d’écrire les articles en Markdown, ce qui est tout de suite beaucoup plus pratique que d’utiliser un wysiwyg qui sera forcément foireux. Et la gestion des fichiers média sera tout de suite moins flexible, mais plus lisible et plus simple à gérer.
(Et, bon, aussi, c’est le seul que j’ai réussi à faire marcher, Hugo et Jekkyl n’ont pas été aussi coopératifs …)
Sur son blog, Fabien Sanglard a publié récemment un article rappelant sa philosophie concernant son blog, et ses préférences à ce sujet. Il défend une approche minimaliste, allant jusqu’à ne pas utiliser de CSS. Cette position est respectable, mais perso je ne suis pas un guerrier du HTML, donc je vais rester sur un intermédiaire et utiliser un outil :) En tous cas cet article m’a motivé à me mettre un coup de pied au derche pour me lancer sur la conversion.
J’ai donc fait un export de mon blog, ça se fait depuis l’interface d’admin de Dotclear, et ça sort un fichier texte qui contient tous les articles avec des meta-donnée; tout en vrac. On fait rentrer ce fichier dans le convertisseur, et ça génère tout plein de fichiers Markdown, avec des balises foireuses de partout. Sans surprise, 10 ans d’articles, rédigés sous plein de versions différentes de Dotclear, forcément il allait y avoir des problèmes. En particulier les caractères d’échappement, c’est le bazar, tous les scripts que j’utilise pour insérer des fichiers audio dans les articles, et toutes les images.
J’ai donc dû repasser sur tous les articles et faire du nettoyage. Ça m’a pris plusieurs jours mine de rien. J’ai aussi récupéré tous les fichiers média, j’ai refait un peu de rangement, que je n’osais pas faire dans Dotclear parce que trop compliqué à faire dans l’interface du CMS. Maintenant c’est beaucoup mieux rangé, j’ai tous les articles dans des fichiers Markdown, tout est homogène au niveau syntaxe et structure, et j’ai un peu plus l’impression de comprendre ce qu’il y a dans ce blog.
J’ai récupéré un code “tout fait” de lecteur audio avec playlist en HTML5 (+ JS) ici. Ça ne casse pas trois pattes à un canard mais ça fait le taf, pour mes albums. Je n’ai pas encore regardé pour y intégrer dans la barre latérale, je me demande si je vais le refaire … En gros j’ai recopié le contenu des balises \<main> dans le corps de l’article, et les lignes <script src="{static}extras/audio_player.js"></script> et <link rel="stylesheet" href="{static}extras/style.css"> (j’ai mis le javascript et le CSS dans un répertoire “extras”), et utilisé la balise {static} pour définir le chemin d’accès. Et ça marche, c’est cool.
J’ai trouvé un thème potable : pelican-twitchy.
Pour les images, je met en direct du HTML (Pelican le gère), avec un truc genre [<img src="{attach}assets/public_export/stomp/fuzz_factory/layout_10.svg" width="100%" alt="Layout">]({attach}assets/public_export/stomp/fuzz_factory/layout_10.svg) ce qui permet d’avoir les images redimensionnées à l’affichage de l’article, et quand on clique dessus on a l’image en taille réelle. Beaucoup plus lisible. L’idéal serait d’avoir un “zoom” qui ne quitte pas la page de l’article, mais bon, déjà c’est bien comme ça.
Et pour la mise en prod, de toutes façons je sauve tout sous Git et sur mon Gitlab, et je vais juste uploader le contenu du répertoire output sur le serveur. Je verrai plus tard, peut-être, pour faire un transfert direct du Gitlab vers le serveur. Et donc le backup est “intégré” : j’ai les sources en local sur mon poste et dans le Gitlab. Au final, sur le serveur du blog il n’y a plus que Apache qui tourne, donc les mises à jour se limiteront à faire sudo aptitude upgrade, et au pire il faudra re-démarrer le démon Apache, ce qui est tout de suite moins stressant. Pas de base de donnée, pas de PHP, tout est plus simple.
Voilà, une bonne chose de faite.
Cette opération de nettoyage m’a fait repasser sur tous mes articles depuis le début du blog. Il y a 10 ans, déjà … 100 articles dont une 50aine publiés. Et ça me fait bizarre de voir ce que j’écrivais, et comment je l’écrivais, il y a 10 ans. Beaucoup de choses ont changé, moi le premier. Il y a des choses que je n’assume pas trop, je me rends compte entre autres que j’étais beaucoup moins attentif à la lisibilité, et que j’utilisais beaucoup plus de langage trèèès familier et très “oral”, ce qui est beaucoup moins le cas maintenant. Les articles s’allongent aussi, mais parce que les sujets changent, on passe de petites descriptions d’enregistrements de covers à la rache à d’énormes études sur du dev embarqué ou de l’électronique et de la fabrication, forcément ça fait plus de choses à dire et à montrer. Qu’en conclure ? Pas grand chose.
En tous cas je suis bien content d’avoir fait le switch, je me sens beaucoup plus en confiance avec ce système beaucoup plus simple et facile à gérer.
Donc … A suivre !