Non, je ne vais pas vous parler de Fenêtre sur rue ; et pour profiter comme il faut du morceau je vous propose de l’écouter calmement puis de revenir lire l’article en mettant cet autre son en fond.
Quand j’ai initialement créé Elauhel, j’avais déjà publié quelques sites/blogs en utilisant des CMS dynamiques type PhpBB, Dotclear et Wordpress.
À l’époque, la norme était d’utiliser un tel outil pour publier son blog.
Ayant une maîtrise technique très limitée et un manque de recul évident sur toutes ces choses, il était donc normal que je suive le mouvement et choisisse un dispositif comme Wordpress.
Surtout que ça apportait des fonctionnalités (commentaires, statistiques…) qui à ce moment-là m’apparaissaient pertinentes pour mon usage.
Depuis (15 ans, quand même), j’ai beaucoup appris, mes besoins et envies ont changé, et le Web a également énormément changé.
Si la norme en entreprise est de rendre les choses de plus en plus complexes en multipliant les briques dans une stack technique, depuis plusieurs années un contre-mouvement visant à revenir à des choses simples prend de plus en plus d’ampleur.
Certains l’appellent Small Web.
C’est ainsi que, pour publier du contenu sur le Web, de nombreux outils de génération de sites statiques ont vu le jour.
Je me permets une interruption ELI5.
Un site web peut exister sous deux formes : soit statique, soit dynamique (et cantique si ça parle de science-fiction et de toucher des enfants).
- Un site statique correspond à du contenu qui a été produit à un moment, qui est hébergé sur un serveur et qui est fourni directement au client (navigateur de la personne surfant sur le Web) en l’état. Exemple typique : une image.
- Un site dynamique correspond à du contenu qui est généré au moment où le client le demande, souvent en interrogeant un ou plusieurs référentiels type base de données. Exemple typique : le flux d’un site de réseau social.
Le site dynamique, depuis que la technologie existe, a toujours été vu comme supérieur, car il permet beaucoup plus de choses, en particulier d’avoir du contenu variable (dynamique…) à chaque rafraichissement d’une page, sans intervention de l’éditeur.
Mais pour ce faire, il nécessite des traitements bien plus importants côté serveur : consulter les référentiels et produire le contenu à la volée à partir de ceux-ci.
Lorsque cela répond au besoin même du site, c’est totalement pertinent.
Par contre, lorsque l’on a un site dont le contenu évolue peu (comprendre : moins d’une fois par jour en moyenne), que ce qui doit être fourni pour une URL donnée est toujours identique, et que seul l’éditeur du site est à l’origine des changements de contenu, alors la pertinence de consommer des ressources supplémentaires côté serveur est fortement mise en doute.
Nouvelle interruption : ici quand je parle de consommation de resources, cela a deux implications.
- La première est économique. Déployer un site statique plutôt que dynamique va nécessiter moins de ressources informatiques (stockage, base de données et calculs processeur) ce qui va se traduire par un coût moins important. Cependant, dans mon cas, via l’offre actuelle de mon hébergeur, cela ne change strictement rien. Pour autant, dans d’autres situations ou si je devais changer d’hébergeur, cela pourrait réellement réduire le coût de mise à disposition du site. Voir les détails techniques plus bas.
- La seconde est environnementale. Si le site consomme moins de ressources informatiques pour servir son contenu, alors nécessairement son impact environnemental est moindre. Si cela se fait sans contraintes (et même avec des avantages) en terme d’expérience, alors il serait dommage de s’en priver.
Sur la consommation de ressources, il y a aussi le sujet des requêtes réalisées par le navigateur. Que ce soit leur nombre ou leur taille.
Avec Wordpress, j’embarquais différents scripts JavaScript et même des polices qu’il fallait aller chercher soit sur le même serveur, soit sur une infrastructure externe.
Maintenant, j’ai fait en sorte de réduire cela au minimum et potentiellement, je pourrai aller encore plus loin. À étudier.
Pour ce blog, maintenant que j’ai retiré les commentaires (qui permettaient à n’importe qui d’être indirectement auteur du contenu) et que je n’utilise aucun plugin Wordpress visant à dynamiser le contenu, il est clair qu’avoir un CMS dynamique pour mettre à disposition le site est tout sauf indispensable.
Au contraire, cela apporte même des contraintes, car un site dynamique repose nécessairement sur un moteur faillible qui peut être exploité par des personnes mal intentionnées.
Résultat, il convient de maintenir ce dernier à jour pour éviter de s’exposer à des attaques, et chaque mise à jour peut provoquer des effets indésirables qui viennent casser des choses qui fonctionnaient très bien jusqu’à présent.
À l’inverse, un site statique ne repose sur aucune exécution de code.
En dehors de la plateforme qui héberge les fichiers, il n’y a rien qui est exposé et doit être mis à jour.
De plus, dans mon cas, la responsabilité de la plateforme incombe à mon hébergeur et non à moi.
Toujours niveau sécurité, pour administrer un site Wordpress, cela se fait via une interface wp-admin qui est simplement protégée par un mot de passe.
Il est certes possible de rajouter des protections type filtrage d’IP pour complexifier la tâche des attaquants, mais cela rend aussi l’expérience de l’éditeur bien plus complexe. Résultat cela offre un point d’attaque supplémentaire sur le site.
Et les milliers de tentatives que j’observe chaque jour le confirment.
À l’inverse, un site statique, il n’y a qu’à la plateforme que l’on peut tenter d’accéder.
Et là, c’est tout de suite bien plus facile à protéger tout en rendant l’expérience d’édition autant voir plus simple. J’y reviendrai.
À cela, s’ajoute le fait que plus le temps passe, plus l’expérience d’utilisation du back-office de Wordpress m’agace.
Je fais partie de ceux qui détestent Gutenberg et pour qui chaque écriture d’article s’avère être un calvaire.
De plus, depuis plusieurs années maintenant, j’utilise Markdown au quotidien pour rédiger du texte. Y compris mes brouillons pour ce site. Que je dois ensuite convertir dans le bon format…
Pouvoir très simplement rédiger en Markdown, via l’éditeur de mon choix (j’utilise IntelliJ pour écrire cet article par exemple) me simplifierait grandement la vie.
Fondamentalement, je n’avais donc pas raisons de continuer à utiliser Wordpress pour rendre accessible Elauhel.
Cependant, migrer plus de 1200 articles sur un nouveau système, ça ne s’improvise pas.
Quitte à migrer, autant en profiter pour revoir les choses en profondeur.
Et puis forcément, j’ai voulu faire le malin et jouer un peu de la technique pour expérimenter diverses choses dans le processus.
Résultat, j’ai d’abord dû tester différents outils de génération de sites statiques, me former à celui que j’avais choisi, choisir/construire/personnaliser un thème, structurer le contenu, mettre en place la pipeline de déploiement, tester différents outils d’exports de Wordpress vers Markdown, puis, enfin, commencer la procédure de migration.
Et entre chaque étape, évidemment, douter, tester, modifier, douter, tester…
Raison pour laquelle au moment où cet article sera publié, sur la nouvelle mouture, statique donc, de Elauhel, tout le contenu n’aura pas encore été migré.
Maintenant que je suis satisfait de l’aspect technique et de la structure de l’ensemble, il fallait que je le déploie en l’état plutôt que d’attendre d’avoir tout migré correctement, sinon avec l’arrivée de nouveaux articles sur la version Wordpress je ne m’en serais jamais sorti.
Et c’est également pour cela que j’ai fortement levé le pied sur les publications depuis août, pour me concentrer sur la nouvelle mouture tout en évitant de me rajouter de la charge de migration.
Bref, voilà, Elauhel est maintenant un site statique, propulsé par Hugo !
En retournant dans le passé, il est possible de tomber sur du contenu cassé, car non encore migré.
J’ai fait le choix, plutôt que d’essayer d’automatiser totalement cette migration, de procéder manuellement.
Pourquoi ?
- Pour me replonger personnellement dans chaque article ; j’ai oublié l’existence même d’une majorité d’entre eux
- Pour garantir le niveau de qualité du rendu de chacun
- Pour faire du nettoyage dans les tags/catégories
- Car avec les évolutions de Wordpress, le format d’enregistrement des articles a changé avec le temps, résultat après quelques heures de développement, je n’avais toujours pas un script qui était en mesure de tout convertir correctement
Je ne toucherai pas à leur contenu à proprement parler ; même s’ils contiennent d’horribles fautes ou des propos dans lesquels je ne me retrouve plus ; mais je vais m’assurer qu’ils soient tous parfaitement lisibles dans leur version statique, et enfin leur associer les bonnes nomenclatures.
L’avantage c’est que même si je décide d’abandonner Hugo dans le futur, il sera bien plus facile de partir sur un autre outil à partir de fichiers Markdown de qualité, que d’une base de données pourrie par des années d’évolutions de Wordpress.
J’avancerai progressivement, avec un objectif d’une dizaine d’articles par semaine.
Une page dédiée permet de suivre l’avancement du processus.
Tous les articles non encore migrés n’ont pas de tag et appartiennent à la catégorie 🦆 - À migrer
Pour m’assister pendant la migration, je conserve à cette adresse une version archivée de Elauhel sauce Wordpress.
Les articles en disparaitront au fur et à mesure de leur bascule.
Si vous souhaitez en savoir plus sur la partie technique, vous pouvez continuer à lire cet article ; sinon vous pouvez sauter directement sur le changelog, ou simplement retrouver une vie normale.
Comment ça marche
Voici le fonctionnement simplifié sous Wordpress :
Trois acteurs :
- Le producteur de contenu, moi
- L’hébergeur et serveur de contenu, O2Switch
- Le client, vous
Le processus de publication d’un article est relativement simple ; mais on constate que chaque visite implique un traîtement relativement complexe côté serveur.
Voici le fonctionnement simplifié avec Hugo :
Alors oui, à première vue, ça semble beaucoup plus complexe cette affaire, voir complètement overengineered !
Mais avant de me traiter d’escroc, laissez-moi m’expliquer…
Six acteurs (soit le double, oui) :
- Le producteur de contenu, toujours moi
- L’hébergeur et serveur de contenu, toujours O2Switch
- Le client, toujours vous
- La plateforme de build du contenu, AWS
- L’intermédiaire de publication sécurisée, rsync.net
- Le messager, Discord
Là où, avec un site dynamique, comme je l’expliquais plus tôt, le contenu est construit à chaque requête ; avec un site statique, il convient de réaliser ce travail une bonne fois pour toutes pour qu’il soit ensuite simplement servi tel quel aux clients.
Ici le build c’est justement Hugo qui le fait. Il convertit des fichiers Markdown en fichiers HTML qui seront servis aux clients.
J’aurais très bien pu faire cette étape sur mon ordinateur et me passer d’AWS ; surtout que j’ai déjà Hugo d’installé en local.
Mais en terme de processus de publication, c’est quand même relativement lourd de devoir écrire son fichier Markdown, lancer Hugo pour produire le HTML, puis envoyer le résultat sur le serveur distant.
Avec la solution mise en œuvre, je rédige mon fichier Markdown, je le push d’un simple clic (mangez vos morts ceux qui font du GIT en CLI) sur un repository CodeCommit et voilà.
Derrière, ça déclenche automatiquement une pipeline qui va exécuter une image contenant Hugo via CodeBuild, construire le HTML, l’uploader sur rsync.net et notifier O2Switch pour qu’il récupère le contenu depuis rsync.net.
Comme c’est un processus automatique, j’ai besoin de savoir s’il a réussi ou non. C’est pourquoi j’ai mis en place des notifications Discord.
Si vous suivez bien, vous devez vous demander : “Mais qu’est-ce que vient foutre rsync.net au milieu de tout ça ?! Pourquoi le contenu ne passe pas directement d’AWS à O2Switch ?!”. Et vous avez totalement raison de vous poser ces questions !
L’explication est simple : O2Switch permet de faire des transferts en SSH, mais demande à ce que l’on autorise, dans le panel d’administration, les hosts avec lesquels on veut communiquer.
Le principe de CodeBuild étant de pop une image sur une VM random dans l’infra AWS, je n’ai pas d’IP fixe et ne peut donc autoriser AWS à publier sur mon espace O2Switch en SSH.
A l’inverse, j’utilise rsync.net depuis plusieurs années pour, entre autres, y déposer les sauvegardes du contenu présent chez O2Switch.
L’IP est fixe, déclarée chez O2Switch depuis le premier jour et ça communique en permanence sans soucis.
En utilisant rsync.net comme intermédiaire, je peux ainsi faire du transfert SSH depuis AWS vers rsync.net, assurer une sauvegarde du contenu qui y est déposé, puis récupérer ce contenu en SSH sur O2Switch pour pouvoir le servir sur le Web.
Si j’insiste sur le .net c’est pour bien distinguer le service rsync.net du logiciel rsync que j’utilise dans l’image de CodeBuild pour n’envoyer sur rsync.net que les fichiers qui ont été modifiés depuis le dernier build.
Et soyons honnêtes, ça a aussi été l’occasion pour moi de m’amuser avec CodeStar !
Ce qui est important à noter c’est que, oui, le processus de publication est maintenant plus complexe et implique plus de ressources. Mais la publication n’a lieu qu’à chaque fois que je publie (…) un article.
Alors que le processus de consultation, lui, est maintenant bien plus simple. Et fondamentalement, il y a beaucoup plus de consultations que de publications.
Permettant une réduction globale de consommation de ressources.
Le petit bonus, c’est qu’avec l’offre Free Tier de CodeBuild, ça ne me coûte rien de plus. Je ne paie que pour rsync.net et O2Switch.
Changements
- Gestion du thème selon les réglages du navigateur, avec possibilité de passer de dark à light manuellement via un toggle à droite du titre du site.
- Modification de la favicon. Passage d’un Bleuet de France à un vélo rose dessiné par Dall-E. Pas certain de le garder mais, pour le moment, ça me plaît.
- Ajout d’une page 📋 Menu visant à lister l’ensemble des pages (à ne pas confondre avec les simples articles) disponibles, sans venir surcharger le bandeau supérieur comme c’était le cas avant.
- Emojis à gogo 🔥🔥🔥. À moins d’être un boomer 🧓 bloqué dans le passé, il faut reconnaître que les emojis 🤪 sont maintenant utilisés partout dans la communication 🗯 numérique et que lorsqu’ils sont correctement 👍 utilisés, ils permettent un ancrage visuel 👓 agréable. De plus, comme ils sont supportés par la majorité des systèmes 🍏 🐧 🏢 tout en étant nativement responsive 📱, cela permet d’ajouter facilement du style 💁♀️ sans trop perdre de temps. J’ai donc fait usage d’émojis à différents endroits, pour permettre un découpage ✂ plus visuel du site. Note : ce paragraphe est une illustration d’un mauvais usage des émojis. 🤬🤬🤬
- Nettoyage/réorganisation des catégories. Sous Wordpress, j’avais pas moins de 60 catégories ! Certaines avec plusieurs centaines d’articles, d’autres avec 1 ou même 0… Certains n’avaient peu d’intérêt, d’autres étaient trop proches pour justifier leur existence propre… Maintenant, j’ai mis en place un découpage en catégories pour tenter de différencier la raison d’être d’un article et des regroupements par tags, pour thématiser le contenu.
- Affichage des tags/catégories. Si sous Wordpress chaque article appartenait à au moins une catégorie, c’était une information qui n’était pas accessible aux lecteurs. Intérêt très limité donc. Seuls les robots, via le 🗺 Sitemap, y avaient accès. Maintenant l’information est disponible sur chaque article ainsi que sur une page dédiée : 🗂️ - Contenu.
- Passage des dates au format ISO 8601 qui est destinée à éviter toute confusion dans les communications internationales due au grand nombre de notations nationales différentes.
- Disparition totale des commentaires. J’avais désactivé la fonctionnalité sur Wordpress ce qui empêchait la création de nouveaux, mais les anciens restaient affichés. Hugo ne proposant pas cette fonctionnalité par défaut, j’y ai vu l’opportunité de les faire totalement disparaître. Désolé pour ceux qui tenaient à leurs messages.
- Ajout de nouvelles pages dédiées ou publication de pages existantes, mais qui n’étaient pas accessibles publiquement.
- Ajout d’une règle serveur pour que l’URL
/feeddu flux RSS Wordpress pointe sur la nouvelle URL/index.xmlafin que les clients RSS déjà abonnés ne voient pas la différence lors de la migration. - Mise à jour de la page 🪪 À propos qui avait déjà plus de 10 ans !
- Sûrement d’autres trucs qui viennent avec le thème PaperMod que j’ai pris comme base et dont je n’ai pas forcément conscience.
