Il est temps de faire un point sur l’après migration du blog vers Hugo. Je suis très satisfait de la migration, même si comme je le prévoyais il y a eu pas mal de travail à faire pour la finaliser, changer l’apparence du thème pour arriver à ce que je souhaitais, soigner les détails et corriger les petits soucis à grands coups de script. Cela m’a aussi amené à revisualiser certains vieux articles, et même à faire un peu de nettoyage. Mais je commence à en voir le bout, enfin j’espère ! 😃
La page d’accueil
Depuis le début, une chose me tenait à cœur : je voulais faire un changement concernant la présentation des articles sur la page d’accueil. Par défaut, le thème Stack propose deux types d’affichage différents pour les en-têtes d’articles : les articles avec une image définie dans le frontmatter, et les autres. Ce qui donnait ceci :
Le header
Déjà, je trouvais l’image trop imposante, et je préférais le type d’affichage que j’avais sur mon Wordpress, avec toujours une miniature affichée en haut à gauche de l’article. J’avais dans un premier temps réduit la hauteur de l’image, en ajoutant ceci dans /assets/scss/custom.css :
/* réduction hauteur images en-tête articles */
.article-image img {
max-height: 150px !important;
width: 100% !important;
height: auto !important;
}
Ce qui donnait ceci :
C’était déjà plus agréable visuellement, et j’ai trouvé finalement que c’était pas mal d’utiliser cet affichage pour certaines catégories, en particulier la catégorie Voyage.
Les thumbnails
Restait à afficher un thumbnail pour les autres catégories (avec une image définie dans le frontmatter bien sûr), et après quelques tatonnements, c’était au-dessus de mes capacités. J’ai donc fait appel à l’AI de Google, et après quelques tâtonnements on a fini par y arriver.
NoteJe dis “on” car ce n’est pas aussi simple que ça en a l’air. Il ne suffit pas de demander à l’AI “affiche moi un thumbnail pour les articles d’une certaine catégorie sur la page d’accueil”.
J’ai commencé d’abord par creuser un peu le sujet par moi-même, repérant les fichiers concernés, pour me faire une idée ce qu’il fallait modifier. L’AI m’a ensuite proposé une solution, qui ne fonctionnait pas totalement, et à commencé à “dériver” vers des changements de plus en plus complexes et qui auraient provoqués à coup sûr des dysfonctionnements du thème. À ce moment là, il faut “recadrer” le problème et repartir d’une base saine pour l’améliorer. Comme à chaque fois, l’AI vous félicite de votre remarque et confirme que c’est le bon choix, puis propose alors un nouveau fichier, qui finit par faire ce que vous voulez. C’est quand même hyper bluffant. 😯
Finalement, il a suffit d’ajouter un nouveau paramètre dans le fichier Hugo.html pour lister les catégories où l’on souhaitait l’affichage par défaut du thème (avec header) :
[params]
# Liste des catégories pour lesquelles on souhaite afficher le header complet
nothumbnailCategories = ["Voyage", "Recettes"]
Et ensuite il n’a fallu modifié qu’un seul fichier : layouts/_partials/article/components/header.html.
Dans celui-ci on teste la catégorie, si elle fait partie de la liste ci-dessus, on applique un affichage normal (avec header), et dans le cas contraire, on affiche un thumbnail en s’inspirant de la vue Archive, qui le fait par défaut (voir fichier layouts/_partials/article-list/compact.html). De plus, quand on affiche un article, il ne faut pas afficher le header (ce qui est fait défaut quand une image est définie) pour les articles en mode “thumbnail”.
Ce qui donne ceci :
Il suffit de regarder la page d’accueil pour se faire une idée du rendu. Il me convient totalement, et je suis super content d’être arrivé à ce résultat, en plus c’est très propre (un nouveau paramètre, un fichier modifié), je ne risque pas de casser le thème. J’ai pour l’instant gardé le “full header” pour les catégories Voyage et Recettes, on verra à l’avenir, le paramètre me laisse une certaine souplesse.
Usage
Alors comment j’utilise au quotidien le blog Hugo quand il s’agit de créer un nouvel article ?
Le principe est simple : j’ai une copie locale du blog dans un dossier sur le PC (disons dans /Hugo/pled), qui occupe environ 5 Go. Ce dossier est sauvegardé quotidiennement sur mon NAS par Vorta.
Rédiger un nouvel article en markdown avec un simple éditeur de texte se révèle assez agréable, une fois que l’on a assimilé les principales syntaxes. Pour les autres, une petite “Cheatsheet” se révèle utile, comme celle que propose de base le thème Stack, et l’on se rend compte que le markdown peut être puissant :
J’utilise l’éditeur de Gnome gnome-text-editor qui est moderne, détecte les syntaxes markdown, inclut un vérificateur d’orthographe, et permet d’ajouter facilement les smileys (chose que Wordpress ne sait toujours pas faire par défaut à part une liste très basique).
J’affiche la page que je suis en train d’écrire dans mon navigateur (http://localhost:1313/) du serveur Hugo local pour en observer le rendu. Le seul souci avec cette configuration, c’est que dès que je sauve ou ajoute un fichier dans l’arborescence, Hugo lance un rebuild qui peut durer plusieurs minutes, avant que je ne puisse voir le rendu (la taille de 5 Go du blog est conséquent).
Pour contourner ce problème, j’ai une copie de mon blog (disons dans /Hugo/pled-mini) avec seulement les derniers articles mais avec exactement la même configuration. Et donc je travaille sur cette instance quand j’écris un nouvel article (rendu visuel immédiat ou presque) et lorsque j’ai fini, je transfère le dossier du nouvel article vers l’instance complète de mon blog. Rappel : je suis organsié en Page bundle comme le recommande Hugo, c’est-à-dire qu’un même dossier inclus le contenu ET les ressources, soit le texte, les images et tout autre fichier media. C’est donc très simple de transférer un article de pled-mini vers pled. Je procède de même lorsque je veux modifier l’apparence du blog.
Une fois mon article prêt, ou les modifs apportées au blog terminées, je n’ai plus qu’à exécuter ce simple script, basé sur rsync :
#!/bin/bash
USER=xxxxxxx
HOST=yyyyyyy.ftp.infomaniak.com
DIR=zzzzzz/pled.fr
hugo --cleanDestinationDir && rsync -e 'ssh -p 22' --archive --delete --exclude='/dir1' --exclude='/dir2' --verbose --compress --human-readable public/ ${USER}@${HOST}:~/${DIR}
NoteL’option
cleanDestinationDirde la commande hugo permet de supprimer les fichiers distants qui n’existent pas en local.
De la même façon, pour la commande rsync, l’option–excludepermet de ne pas effacer des dossiers qui se trouvent à la même hauteur que le site, et qui seraient supprimés par l’option–delete(qui efface sur le site distant tout ce qui n’est plus sur le site local).
Et voilà, mon blog en ligne a été mis à jour. C’est assez simple comme fonctionnement. Ce que j’apprécie le plus c’est que tout est fichier, comme dans Linux : Everything is a file. 😎
Les scripts Python
Il a quand même fallu faire un gros travail de modifications et d’ajustements dans les fichiers index.md des articles : corrections de liens post-migration, positionnement images, syntaxe markdown, contenu du frontmatter, etc…
Voilà les principales actions que j’ai du effectuer.
ImportantPour tout ce qui suit, j’ai utilisé l’AI Gemini pour me générer des scripts python et effectuer les tâches. J’ai été assez bluffé par la qualité des scripts proposés, une fois le problème clairement défini. Souvent la première version est la bonne, et au pire une ou deux corrections sont nécessaires avant d’aboutir au résultat souhaité (sans comparaison avec Mistral).
Liens internes cassés
Car non gérés par le script de migration wp2hugo : les liens internes au blog étaient restés en "/?p=XXX".
Heureusement, l’outil de migration ajoute dans le frontmatter de chaque article pas mal d’infos WP qui peuvent se révéler utiles pour la migration, comme l’origine de chaque article sous cette forme : guid: https://pled.fr/?p=15188. Il était donc possible d’imaginer un script qui crée un tableau en mémoire avec le “guid” de chaque fichier index.md du blog hugo, puis d’établir la correspondance et remplacer tous les liens internes dans le corps des articles avec le lien Hugo vers l’article.
Floatleft
La plupart de mes articles commençant par un miniature affichée en mode “floatleft” en début d’article, et cette class CSS avait été perdue lors de la migration. Il a donc fallu rajouter cette class dans assets/scss/custom.css :
/* Gestion postionnement des images, typiquement en début d'article */
img[src$='#floatleft']
{
float:left;
margin: .5em 1em .5em 0;
}
img[src$='#floatright']
{
float:right;
margin: .5em 0 .5em 1em;
}
Une fois ceci fait, un script python est allé modifier chaque article commençant par la définition d’une image  pour la remplacer par .
Enfin, un autre script a cherché en début d’article une image du type , et l’a ajouté au frontmatter pour que la manip “thumbnail” décrite plus haut fonctionne.
Gallery
Il a fallu remplacer les shortcodes de type gallery venant de l’outil de migration wp2hugo pour utiliser la syntaxe proposée par le thème Stack, dont le rendu est nettement meilleur. Voilà comment on affiche une gallerie avec Stack : le redimensionnent des images sur la même ligne est automatique, et on peut mettre autant d’images qu’on le souhaite :
  
Alors que le shortcode “gallery” issu de la migration affichait les images les unes sous les autres. 🙁 Et je préfère cette façon de faire à celle de WP avec son “Gallery block”. Cette remarque est d’ailleurs vraie pour l’ensemble de la syntaxe markdown comparée aux blocks WP. C’est pourquoi il est plus agréable d’écrire un article en markdown qu’avec WP (à mon avis).
Frontmatter
Un script python m’a aussi nettoyé les frontmatter issus de la migration. Le script wp2hugo ajoutait plein d’infos inutiles pour moi ; je les ai nettoyées, en supprimant si elles existent :
- l’entrée summary:
- l’entrée “_last_editor_used_jetpack”
- l’entrée “_edit_last”
- l’entrée “oembed…”
Il y avait aussi un cas plus compliqué, avec des entrées “enclosure” comme ci-dessous, et donc sur plusieurs lignes :
enclosure: |-
https://pled.fr/wp-content/uploads/2012/09/MemphisUnderground.mp3
1229277
audio/mpeg
Le script python généré par l’AI pour ce cas précis a nécessité d’utiliser python-frontmatter, c’est plus propre et plus sûr (dixit Gemini).
Et donc installation dans un environnement virtuel, à la racine du site Hugo, puis lancement du script :
$ cd /Hugo/pled
$ python -m venv .venv
$ source .venv/bin/activate
$ pip install python-frontmatter
$ python ~/Documents/Scripts/Hugo/clean-enclosure.py
Exposants
J’ai aussi utilisé un script Python pour transformer dans mes articles les XXe et autres XVIIIème en XXème et XVIIIème, quand j’ai vu que le markdown me permettait de le faire. Il a fallu que je formule correctement mon besoin pour que le script fasse ce qu’il fallait (ce n’était pas évident au départ d’identifier les bonnes “patterns”).
Nettoyage
Lors du passage en mode “thumbnail”, j’en ai profité pour supprimer environ 200 articles, principalement de la catégorie Photo : en fait ils annonçaient simplement un nouvel album photo, sans autre intérêt. Et comme les albums pour les Amis et la Famille sont désormais protégés par mot de passe pour respecter la vie privée, leur intérêt était nul. De plus, tous ces liens vers les albums étaient cassés, il aurait fallu tous les refaire : le jeu n’en valait pas la chandelle. Il y a un lien direct vers l’album Zenphoto à gauche de la page d’accueil, c’est suffisant.
D’ailleurs, en repassant sur les tout premiers articles du blog, je pense qu’il y en a encore d’autres à supprimer : je découvrais pas mal de choses à cette époque, y compris le blog. Certains articles, très courts, expliquent comment je suis passé de Wordpress v1.5.2 à la v2.0.1. Cela n’a plus aucun intérêt aujourd’hui ! 😁
Documentation
Un petit mot sur la documentation pour finir : le thème Stack est vraiment d’excellente qualité, et j’ai découvert qu’en plus de la documentation, il y avait un deepwiki où l’on peut poser des questions à l’AI (Devin) avec une qualité de réponse excellente. C’est vraiment un énorme plus ! 👍
NoteJe ne connaissais pas ce Deepwiki, mais apparemment, il y a là plein de dépôts Github qui y ont été déclarés (par le dev de chaque projet j’imagine) : ensuite l’IA parcourt le dépôt en question (code, documentation) et fournit des réponses aux questions posées. C’est vraiment impressionnant ! Comme il est dit en bas de page :
What is DeepWiki?
DeepWiki provides up-to-date documentation you can talk to, for every repo in the world.
Think Deep Research for GitHub.
Conclusion
Voilà, il y aura certainement encore d’autres choses à faire et/ou à modifier, mais le blog commence à ressembler à ce que je voulais, sans avoir rien perdu, en particulier les commentaires (grâce à Remark42.
Il reste sans doute un peu de ménage à faire sur les vieux articles. Sans doute d’autres à corriger si quelque chose a été cassé sans que je m’en rende compte.
Je réfléchis aussi réduire le nombre de catégories. J’avais dans l’enthousiasme créé une nouvelle catégorie Hugo quand j’ai commencé à réfléchir à la migration. Mais en fait, je l’ai supprimée et remplacée par la catégorie Weblog que j’ai utilisée pour tous les articles concerant Wordpress. C’est plus cohérent comme ça.
Mais j’ai par exemple trois catégories Ubuntu, Debian et EndeavourOS : pourquoi ne pas les regrouper sous une seule catégorie Linux Desktop par exemple ? J’ai vu que le thème gère les TAGS, je pourrais alors les utiliser pour spécifier l’OS ? La réflexion est en cours, je ne sais pas trop si cela va vraiment apporter quelque chose.