Go on Zwindler's Reflection

Refonte de l'UI de GroROTI

Fri, 22 May 2026 12:00:00 +0200

Si vous lisez régulièrement ce blog et mes aventures sur les réseaux sociaux, vous savez que j’aime énormément l’infrastructure, un peu le code backend (surtout en Golang), mais que dès qu’il s’agit de concevoir une interface graphique moderne et agréable, il n’y a plus personne.

C’est un fait établi, je n’ai aucune compétence en développement front. Dommage pour les offres FullSteak (jeu de mot pourri, mais plutôt approprié ici).

C’est exactement ce qui pénalisait GroROTI, un petit outil web open source en Go que j’avais développé en 2024 (en partie sur mon temps libre, en partie lorsque j’étais chez mon ancien employeur, ce qui explique pourquoi le dépôt soit hébergé sur leur GitHub).

Pour rappel, l’application permet d’évaluer rapidement et anonymement la qualité des réunions ou des ateliers via le format ROTI (Return On Time Invested).

Le problème, c’est que l’outil était fonctionnel, mais franchement moche. Un petit look Web 1.0, voire soviétique, qui était franchement assumé dans un premier temps, mais dont on se lasse assez vite.

Qu’à cela ne tienne. Fort de mes expériences plutôt concluantes avec la refonte de ma page Conférence (cf “Refonte de la page Conférences : data-driven avec Hugo”) et la v3 de mon projet pour cataloguer toutes les manières de déployer Kubernetes (cf “101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s’améliore”), j’ai fait chauffer un LLM perso pour lui demander de m’aider à rendre ça un peu plus agréable à l’oeil.

Le résultat va bien au-delà de mes compétences (“la barre est au sol” comme on dit). Si on compare les captures d’écran avant (à gauche) et après (à droite), le changement est flagrant :

Une page d’accueil transformée : Fini l’alignement de texte un peu triste. On passe sur une interface épurée, une colorimétrie violette moderne (petit clin d’oeil), un bloc de création “New ROTI” bien délimité et une barre latérale pour afficher les derniers examens créés.

Des résultats clairs : La page de restitution des votes affiche désormais la moyenne globale en grand, ainsi que le nombre de participants et les valeurs minimales et maximales sous forme de “cartes”. Le QR code de partage est lui aussi bien mieux intégré visuellement.

Un système de notation plus intuitif : Le vieux curseur glissant a été remplacé par un système de notation à 5 étoiles (avec support des demi notes) bien plus classique et parlant pour les utilisateurs. Le tout reste accompagné d’une zone de texte (redesignée) pour les retours optionnels, quand ils sont activés.

Juste un lifting

Sous le capot, l’application reste la même, je n’ai pas touché au code backend (*), juste la partie templates HTML (gotpl) et CSS.

(*) c’est pas 100% vrai, j’ai fait quelques modifs en 2025, notamment pour ajouter du tracing otel, support de la CR ServiceMonitor, amélioration du build multi arch et quelques bugfixes… dont je ne vous avais pas parlé.

Au final, ce petit truc en plus fait la diff entre un tool interne que je n’avais pas trop envie de mettre en avant, et un outil qui me parait utilisable en dehors de mon contexte pro :

https://github.com/deezer/GroROTI

Automatiser son site Hugo sans Github Action ou Vercel

Tue, 01 Aug 2023 06:00:00 +0200

Contexte

Fin 2021, après plus de 10 ans à écrire des articles de blog tech sur Wordpress, je prenais la décision radicale d’arrêter de maintenir cette bouse infâme (je mâche mes mots) et de partir sur des articles rédigés en markdown et un site statique avec Hugo.

Au tout début, je gérais le blog moi-même mais assez vite j’en ai eu assez de devoir aller rebuild le blog à chaque modification. J’ai rapidement mis un cron qui faisait des git pull régulièrement, mais on ne va pas se mentir, c’est assez crado…

Finalement, on m’a rapidement pointé que je devrais arrêter de m’embêter et utiliser Netlify ou Vercel.

J’étais pas super chaud, car ça allait à l’encontre de ma volonté d’auto héberger mon contenu et de limiter l’impact sur la vie privée de mes lecteurs, mais finalement, l’expérience utilisateur sur Vercel était tellement bonne que j’avais craqué. Je ferai peut-être un article là-dessus d’ailleurs, c’est la première fois que j’ai compris (ressenti) l’intérêt d’un PaaS.

Mais aujourd’hui, je reviens sur cette décision et j’essaye de voir ce qu’il est nécessaire de mettre en place pour disposer soi-même d’un site hugo qui se refresh tout seul dès qu’un commit arrive sur le dépôt git, sans utiliser de plateforme type Vercel ni d’outils types Github action+pages.

Prérequis

Je pars du principe que vous avez déjà un site statique généré avec Hugo. Si ce n’est pas le cas je vous invite à aller lire mes articles précédents sur le sujet (premiers pas, stats avec matomo, migration wordpress vers hugo).

Vous avez donc un serveur Linux sur lequel vous avez la main pour installer des choses et un dépôt git (sous Github dans mon cas, mais on peut probablement adapter l’article pour autre chose).

Hugo étant d’abord un générateur de site statique, je vais utiliser nginx en frontal pour servir les fichiers qu’on va générer. Jusqu’à il y a peu, l’usage du mode “server” de hugo n’était d’ailleurs pas conseillé en production (mais ça ne semble plus être le cas, je n’ai pas vu de warning dernièrement ?).

apt install nginx git

Déposer les sources sur le serveur

Dans mon cas, les sources de mon blog ne sont pas disponibles publiquement (parce que j’ai pas envie, c’est comme ça ¯\_(ツ)_/¯).

Il faut donc préalablement se loguer en SSH avec git avant de pouvoir pull le code. Et comme je n’ai pas envie de laisser ma clé privée sur le serveur qui va héberger mon blog, il faut que j’utilise une autre clé.

Dans mon cas, Github, qui héberge le code markdown de mon blog, a une notion de “deploy keys”, qui servent justement pour ça :

docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys

Je vais donc créer une clé sur le serveur qui héberge le blog :

ssh-keygen -t ed25519 -C "xxx@xxx.tld"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/toto/.ssh/id_ed25519):
[...]

Et je la copie dans le dossier de www-data (l’utilisateur nginx sous Ubuntu)

chmod 600 /root/.ssh/id_ed25519
sudo mkdir /var/www/.ssh/
sudo cp ~/.ssh/id_ed25519* /var/www/.ssh/
chown www-data: /var/www/.ssh/*

Une fois la clé créée, on doit l’ajouter dans Github.com. Je ne lui donne que les droits “read only” puisque le but c’est seulement de récupérer le code et générer le site statique, pas qu’on puisse éditer le code (cé pour la sécuritay).

Je retourne ensuite sur mon serveur et j’essaye de télécharger les sources et le thème:

cd /usr/share/nginx/html
GIT_SSH_COMMAND='ssh -i /var/www/.ssh/id_ed25519 -o IdentitiesOnly=yes' git clone git@github.com:zwindler/blog.example.org.git
cd blog.example.org/themes
git submodule add -f https://github.com/CaiJimmy/hugo-theme-stack.git
chown -R www-data: /usr/share/nginx/html/blog.example.org

Webhook

Pour réagir à l’arrivée d’un nouveau commit sur notre dépôt source, on va utiliser 2 choses :

un projet qui s’appelle sobrement “Webhook”.
configurer un webhook dans github, qui va envoyer l’info que quelque chose est arrivé sur le dépôt (mais on verra ça plus tard)

Revenons à “Webhook” dans un premier temps :

webhook is a lightweight configurable tool written in Go, that allows you to easily create HTTP endpoints (hooks) on your server, which you can use to execute configured commands. You can also pass data from the HTTP request (such as headers, payload or query variables) to your commands. webhook also allows you to specify rules which have to be satisfied in order for the hook to be triggered.

On récupère la dernière release et déposer le binaire sur notre serveur :

github.com/adnanh/webhook/releases/tag/2.8.1

export VERSION="2.8.1"
wget https://github.com/adnanh/webhook/releases/download/${VERSION}/webhook-linux-amd64.tar.gz

tar -xvf webhook*.tar.gz

sudo mv webhook-linux-amd64/webhook /usr/local/bin
rm -rf webhook-linux-amd64*

webhook --version

Une fois que c’est fait, on va générer une chaîne aléatoire qui va nous servir de “secret” qui sera partagé entre le binaire webhook qui tourne sur notre serveur et un webhook sur Github.com :

WHSECRET=`uuidgen | base64`
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa==

On crée un fichier de configuration hook.json pour déclarer nos webhooks

mkdir /etc/webhook
cat > /etc/webhook/hook.json << EOF
[
 {
 "id": "redeploy",
 "execute-command": "/usr/share/nginx/html/blog.example.org/blog_refresh.sh",
 "command-working-directory": "/usr/share/nginx/html/blog.example.org",
 "trigger-rule":
 {
 "match":
 {
 "type": "payload-hmac-sha1",
 "secret": "$WHSECRET",
 "parameter":
 {
 "source": "header",
 "name": "X-Hub-Signature"
 }
 }
 }
 }
]
EOF

Ici, quand le serveur va recevoir l’url /hooks/redeploy, on va lancer le script /usr/share/nginx/html/blog.example.org/blog_refresh.sh depuis le répertoire /usr/share/nginx/html/blog.example.org.

Charge à nous de créer un script qui va soit :

récupérer les sources (git pull)
relancer un build

Voilà à quoi pourrait ressembler le script blog_refresh.sh :

#!/bin/bash
cd /usr/share/nginx/html/blog.example.org

#pull latest version
GIT_SSH_COMMAND='ssh -i /var/www/.ssh/id_ed25519 -o IdentitiesOnly=yes' git clone git@github.com:zwindler/blog.example.org.git

#refresh theme submodule
git submodule init
git submodule update

#rebuild (fire and forget)
hugo --minify --gc &

On va ensuite créer un service systemd qui va lancer le binaire webhook en tâche de fond

cat > /etc/systemd/system/webhook.service << EOF
[Unit]
Description=Simple Golang webhook server
ConditionPathExists=/usr/local/bin/webhook
After=network.target

[Service]
User=www-data
Group=www-data
Type=simple
WorkingDirectory=/usr/share/nginx/html/blog.example.org
ExecStart=/usr/local/bin/webhook -ip 127.0.0.1 -hooks /etc/webhook/hook.json -verbose
Restart=on-failure

[Install]
WantedBy=default.target
EOF

systemctl enable webhook
systemctl start webhook

Côté Github.com, on crée le webhook qui va contacter le serveur webhook de la façon suivante :

On a maintenant un serveur web qui est en attente de certains événements webhooks et qui va lancer un script si jamais l’URL de webhook est appelée par Github.com.

Configuration nginx

Il reste maintenant toute la configuration de notre nginx en frontal à faire. En partant du principe qu’on vient juste de faire l’installation du package, on commence par supprimer le fichier /etc/nginx/sites-enabled/default, et on en crée un nouveau :

rm /etc/nginx/sites-enabled/default

cat > /etc/nginx/sites-available/blog.example.org.conf << EOF
# Root configuration
server {
 listen 80;
 server_name blog.example.org;

 location /hooks/ {
 proxy_pass http://127.0.0.1:9000/hooks/;
 }

 error_page 404 /404.html;

 location / {
 root /usr/share/nginx/html/blog.example.org/public;
 index index.html;
 }
}
EOF
ln -s /etc/nginx/sites-{available,enabled}/blog.example.org.conf

On vérifie que la configuration est valide et si oui on redémarre nginx

nginx -t
systemctl reload nginx

A partir de maintenant, toutes les URLs qui arriveront jusqu’à votre serveur en /hooks seront redirigées sur le logiciel “webhook” et le reste ira sur votre site statique (/usr/share/nginx/html/blog.example.org/public).

curl https://blog.example.org/hooks/redeploy -L
Hook rules were not satisfied.%

Ici le hook renvoie une erreur, car on a pas envoyé le token secret mais c’est probable que ça fonctionne. Toutes les autres pages renvoient bien une page du blog :

curl https://blog.example.org/
<!DOCTYPE html>
<html lang="fr-fr" dir="ltr">
 <head>
 <meta name="generator" content="Hugo 0.115.1"><meta charset='utf-8'>
[...]

On peut maintenant envoyer des commits et voir si ça déclenche des rebuilds de notre blog. Ou alors, on peut récupérer un push précédent et cliquer sur “Redeliver” si on veut trigger un rebuild du blog.

root@hugo:~# systemctl status webhook
* webhook.service - Simple Golang webhook server
 Loaded: loaded (/etc/systemd/system/webhook.service; enabled; vendor preset: enabled)
 Active: active (running) since Mon 2023-07-31 07:34:35 UTC; 33s ago
 Main PID: 900109 (webhook)
 Tasks: 15 (limit: 4574)
 Memory: 240.4M
 CPU: 45.504s
 CGroup: /system.slice/webhook.service
 |-900109 /usr/local/bin/webhook -ip 127.0.0.1 -hooks /etc/webhook/hook.json -verbose
 `-900161 hugo --minify --gc

Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 attempting to load hooks from /etc/webhook/hook.json
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 found 1 hook(s) in file
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 loaded: redeploy
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 serving hooks on http://127.0.0.1:9000/hooks/{id}
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 os signal watcher ready
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] incoming HTTP POST request from 127.0.0.1:43258
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] redeploy got matched
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] redeploy hook triggered successfully
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] 200 | 0 B | 1.151688ms | 127.0.0.1:9000 | POST /hooks/redeploy
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] executing /usr/share/nginx/html/blog.example.org/blog_refresh.sh
[...]
Jul 31 07:37:28 hugo webhook[900109]: Pages | 3572
Jul 31 07:37:28 hugo webhook[900109]: Paginator pages | 516
Jul 31 07:37:28 hugo webhook[900109]: Non-page files | 14
Jul 31 07:37:28 hugo webhook[900109]: Static files | 2282
Jul 31 07:37:28 hugo webhook[900109]: Processed images | 2
Jul 31 07:37:28 hugo webhook[900109]: Aliases | 1563
Jul 31 07:37:28 hugo webhook[900109]: Sitemaps | 1
Jul 31 07:37:28 hugo webhook[900109]: Cleaned | 0
Jul 31 07:37:28 hugo webhook[900109]: Total in 166131 ms
Jul 31 07:37:28 hugo webhook[900109]: [webhook] 2023/07/31 07:37:28 [f089a0] finished handling redeploy

Conclusion

Si vous êtes à l’aise avec Linux et nginx, ces quelques manipulations sont assez rapides à faire, il n’y a rien de vraiment complexe.

Cependant, ça demande à l’usage un peu d’administration et de vouloir mettre les mains dans le cambouis (avoir une VM à gérer). Je ne peux reprocher à personne de préférer l’utilisation de Github/Gitlab pages, couplé à de Github actions/Gitlab runners, voire de tout déléguer à Vercel/Netlify…

Mais j’avais envie de reprendre la main sur le hosting de mon blog (avec tous les inconvénients que ça va avoir en termes de maintien en condition opérationnelle), notamment pour disposer à nouveau de l’IPv6 (perdue lors du passage à Vercel) et une navigation sur mon blog plus respectueuse de votre vie privée (pas que j’aie pas confiance en Vercel, mais bon…).

Et c’est en revanche beaucoup plus simple que d’héberger son propre serveur Gitlab + Gitlab runners + Gitlab pages ;-).

Donc, pour mon usage, ça fait le taf :)

Ressources additionnelles

J'ai enfin migré de Wordpress vers Hugo - partie 2

Mon, 29 Nov 2021 08:00:00 +0000

Cette article fait partie d’une suite d’articles :

Extraire les données de WordPress

Normalement si vous avez lu la première partie, vous savez qu’on a un Hugo fonctionnel (mais vide). Et que dans mon cas, l’objectif était de migrer 12 ans d’historique (350 articles tout de même) de Wordpress vers notre Hugo.

Vous vous en doutez, le but n’est pas de reprendre les articles uns par uns (sauf si vous n’en avez qu’une dizaine, ça doit se faire) mais bien de trouver une méthode pour exporter le contenu existant en markdown pour repartir comme si de rien n’était.

La documentation officielle de Hugo donne plusieurs pistes pour migrer depuis Wordpress et c’est la première que j’avais utilisé en 2019 (la première fois que j’avais tenté de migrer, sans succès). J’ai re-installé l’extension wordpress-to-hugo-exporter (je vous invite quand même à regarder les alternatives car il n’est pas impossible que ça ait évolué depuis).

wordpress-to-hugo-exporter

La première chose à faire pour installer cette extension est de vérifier que votre serveur qui héberge le WordPress dispose bien de l’extension PHP zip.so.

cat /etc/php.d/40-zip.ini
; Enable ZIP extension module
extension=zip.so

On peut ensuite cloner le projet git du plugin directement dans le dossier plugin de WordPress

cd PATH_TO_WORDPRESS/wp-content/plugins/
git clone https://github.com/SchumacherFM/wordpress-to-hugo-exporter

A partir de là, il est possible de démarrer un export soit depuis l’interface, soit via un script en PHP lancé depuis le serveur en ligne de commandes. Évidemment, dans ce genre de procédures, on arrive toujours à un moment où on se tape un timeout quelque part. Dans mon cas, les données exportées (articles + medias, environ ~1.5 Go) prenaient 500 Mo de RAM et 20 minutes d’exécution.

On oublie donc le clic dans l’interface (sauf à tuner votre nginx pour autoriser des requêtes clients avec un timeout > 60s) et on lance depuis la ligne de commande. Et bien entendu, on augmente toutes les limites possibles et imaginables, notamment celle de wordpress via le fichier wp-config.php.

// Set initial default constants including WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, WP_DEBUG, SCRIPT_DEBUG, WP_CONTENT_DIR and WP_CACHE.
wp_initial_constants();
define( 'WP_MEMORY_LIMIT', '2048M' );
define( 'WP_MAX_MEMORY_LIMIT', '2048M' );

cd PATH_TO_WORDPRESS/wp-content/plugins/wordpress-to-hugo-exporter/
php hugo-export-cli.php memory_limit=-1

Qui devrait se terminer, si tout se passe bien, par un :

This is your file!
/tmp/wp-hugo.zip

Note: on peut également exporter les commentaires, il faut modifier manuellement une ligne dans le fichier hugo-export.php (voir la doc)

A partir de là, on a une archive qui contient vos posts, vos pages et vos médias importés (grosso modo tout wp-content).

L’archive a l’arborescence suivante :

un dossier posts qui contient tous les articles (posts dans la terminologie wordpress) dans un mélange de markdown + html brut (ce qui n’aura pas été correctement converti, on y reviendra)
un dossier wp-content qui contient tous les médias
des dossiers pour chacune de vos “pages (“à propos”, “mentions légales”, etc).

Importer dans Hugo

L’arborescence de Hugo est elle un peu différente. De base, tout ce qui est markdown doit être dans content, avec des sous dossiers en fonction du type de page (post ou page).

La première petite “blaguounette” est que les posts doivent être déposés dans le sous-dossier content/post (sans S à la fin !!!).

Chaque post commence par des métadonnées encadrées par des triples tirets “—” avant et après. Ca donne quelque chose comme ça :

---
title: 'ESXi 4.0 : Explorons l&rsquo;Hidden Console Part 1'
authors:
 - zwindler
type: post
date: 2010-04-28T08:32:20+00:00
url: /2010/04/28/esxi-4-0-explorons-lhidden-console-part-1/
featured_image: https://blog.example.org/wp-content/uploads/2014/10/vmware-220x162.jpg
categories:
 - Virtualisation
tags:
 - ESX(i)
 - Hidden Console
 - SSH
---

[L'article lui même...]

Ca peut différer un peu selon les thèmes je pense, mais grosso modo les markdown des pages iront eux dans content/page.

Enfin, tout ce qui est media (dossier wp-media) va dans un dossier static. On peut garder la même arborescence que wordpress (/année/mois/) mais rien ne nous y oblige.

So far, so good

Emile et Images

Enfin… so good, c’est vite dit…

Et oui parce que l’exporter n’exporte pas hyper bien un certain nombre de choses, à commencer par l’image de garde de chaque article :

featured_image: https://blog.example.org/wp-content/uploads/2014/10/vmware-220x162.jpg

On peut remarquer plusieurs soucis avec cette variable. D’abord, la variable utilisée pour indiquer le chemin de l’image dans les métadonnées générées est featured_image alors qu’Hugo attend image. Petit sed sur vos md pour corriger ça :

sed -i "s/featured_image/image/g" fichier.md

Mais bien sûr, ce n’est pas fini ;-)

Ensuite, on remarque qu’on a un chemin est une URL complète et non pas relative. Si vous gardez les média dans le chemin static/wp-content/uploads/YYYY/MM ça marchera, mais je trouve ça moche.

2 solutions :

on supprime /wp-content/uploads avec un bête sed -i "s!/wp-content/uploads!!g fichier.md
on passe en relatif en supprimant carrément toute la première partie de l’URL https://yourblog.example.org/wp-content/uploads

Si vous choisissez la 2ème solution (mon choix), faites quand même bien attention. En fonction de comment vous rédigez votre expression régulière, ça pourrait affecter aussi toutes les autres images que vous auriez en lien dans vos articles. Ce n’est pas forcément une mauvaise chose (moi j’aime mieux les liens relatifs car c’est plus flexible) mais ça demande un travail supplémentaire.

Images intermédiaires

Toujours dans les images, vous remarquerez aussi que l’image “mise en avant” (dans les métadonnées) possède un suffixe de type -111x222 juste avant l’extension. En fait, chaque fois que vous importez une image dans wordpress, celui ci la convertie en plusieurs tailles pour accélérer le chargement des pages.

Sauf que le wordpress-to-hugo-exporter choisi une des plus petites résolution pour l’image en tête de l’article. Ca sera souvent hyper moche…

Là encore, j’ai donc passé un gros sed pour virer tous les suffixes -111x222 avant l’extension, puis je n’ai copié QUE les images originales dans le dossier static (regex non triviale) :

cd PATH_TO_EXPORT/wp-content/uploads
for i in `seq 2010 1 2021`; do
 find $i -mindepth 1 -type f -regextype posix-egrep -not -iregex ".*/.*-[0-9]{1,4}x[0-9]{1,4}.*\..*" -exec cp {} PATH_TO_HUGO/static/{} \;;
done

Nettoyer les caractères spéciaux HTML

Si vous avez bien lu l’exemple de métadonnées exportées que j’ai donné, vous aurez peut être remarqué la présence d’un caractère spécial encodé ’ dans le titre.

Dans une page HTML, ce n’est pas grave, mais Hugo lui, ne les interprète pas comme tel dans le markdown. Il faut donc leur faire la chasse et tous les convertir 🤦. Et encore, il faut faire attention, car certains de ces caractères pourraient être légitimement écris en HTML (si vous faite un tuto sur HTML, ce n’est pas impossible par exemple)…

J’ai pour ma part lancé un gros sed (une fois de plus) sur tous mes articles mais prudence !

sed -i "s/&rsquo;/’/g" $1
sed -i "s/&#8211;/--/g" $1
sed -i "s/&#8230;/.../g" $1
sed -i "s/&gt;/>/g" $1
sed -i "s/&lt;/</g" $1
sed -i "s/&#8212;/-/g" $1
sed -i "s/&#8217;/'/g" $1
sed -i "s/&#215;/×/g" $1

Je n’ai pas osé modifier les caractères suivants, très souvent présents dans les URLs :

&#038
&#039
&quot;

Mais c’est quand même une bonne idée de faire une grosse recherche avec votre éditeur de texte favori pour voir s’il ne reste pas des &# qui traînent dans votre contenu.

HTML désactivé

Au delà des caractères spéciaux, il arrive aussi que l’exporter est un peu de mal avec les différents types d’éditeurs que Wordpress a pu avoir au fil du temps.

Typiquement, beaucoup du contenu “non texte” que j’ai ajouté au fil des années s’est retrouvé non converti par ce que j’ai rédigé s’est retrouvé exporté tel quel, en HTML brut inséré dans mon markdown.

C’est hyper traître car Hugo ne renvoie aucune erreur. Il manque “juste” des bouts ! On peut les retrouver en allant voir le code source de la page, qui affiche alors les commentaires HTML suivants :

<!-- raw HTML omitted -->

En attendant de nettoyer tout ça à grand coup de sed, on peut résoudre une partie des problèmes en “réactivant le support du code HTML dans le markdown dans votre config.yaml.

markup:
 goldmark:
 renderer:
 ## Set to true if you have HTML content inside Markdown
 unsafe: true

Ca permet de sauver les meubles mais ce n’est pas suffisant…

Markdown hates HTML

Même comme ça, on grosse partie du HTML sera HS… Tous les tableaux (table/tr/td) et listes (ul/li) HTML sont pétés car l’exporter laisse des sauts de lignes entre les blocs, que le markdown interprète mal. Il faudra supprimer tous les sauts de lignes en trop (ou réécrire en markdown)

<table class="Content" border="0" width="750">
<tr>
<td class="LargeBold">
SEND_CUSTOM_SVC_NOTIFICATION
</td>
</tr>
<tr>
<td class="MediumBold">
Command Format:
</td>
</tr>

Sachez également que toutes les “videos embedded” Youtube disparaîtront purement et simplement, et que pour les tweets, vous aurez une version très moche du tweet, sans l’image…

<blockquote class="twitter-tweet" data-width="550" data-lang="en" data-dnt="true" data-partner="jetpack">
 <p lang="fr" dir="ltr">
 [[#SAPHANA](ht tps://tw itter.com/hashtag/SAPHANA?src=hash&ref_src=twsrc%5Etfw)] Finies les mises à jour incompatibles avec votre plateforme, optez pour la simplicité et la tranquillité, chez SAP : on collecte, on connecte, ça marche : [t.co/2AdCCEQ97L](https://t.c o/2AdCCEQ97L) [pic.twi tter.com/yy7moMnZmC](ht tps://t.c o/yy7moMnZmC)
- SAP France (@SAPFrance)

 [October 8, 2018](ht tps://twiter.com/SAPFrance/status/1049286253533962241?ref_src=twsrc%5Etfw)
</blockquote>

J’en avais peu heureusement, j’ai donc pris des captures d’écran et ajouté des liens.

Balises de code, pre, etc.

Une autre grosse catégorie de code “mal exporté” est le “code”. Je donne souvent des bouts de scripts ou de code ou tout simplement des commandes à passer sur des serveurs. Et au fil des années, j’ai (& wordpress) changé plusieurs fois la façon d’afficher du code dans mes articles.

D’abord avec des balises HTML <pre></pre>, puis des balises <code></code>, puis via des extensions (pour avoir la coloration syntaxique), puis via du markdown via Jetpack, puis de nouveau via les extensions…

Autant dire que le HTML généré par Wordpress ne ressemble à rien…

Il a fallut faire un gros gros boulot pour détecter toutes les balises de code ouvrantes et fermantes pour les convertir en ``` de markdown…

Quelques exemples que j’ai rencontré :

<pre>

<pre class="brush: plain; title: ; notranslate" title="">
<pre class="brush: perl; collapse: false; title: ; wrap-lines: false; notranslate" title="">

<pre class="EnlighterJSRAW" data-enlighter-language="null">
<pre class="EnlighterJSRAW" data-enlighter-language="generic">
<pre class="EnlighterJSRAW" data-enlighter-language="generic" data-enlighter-theme="" >
... et bien d'autres encore

Final words

Je m’arrête là car l’article est déjà très long, mais il y a eu d’autres petits problèmes du même style, plus sporadiques…

Vous voyez donc qu’exporter le blog sur Hugo n’aura pas été de tout repos, dans mon cas. Et encore ! Je n’ai pas exporté les commentaires historiques (plus de 1600) !

Cependant, si vous avez un blog plus petit que celui ci, vous devriez avoir moins de mal et les conseils que je donne ici devraient vous permettre de régler rapidement 90% des problèmes.

Enjoy !

J'ai enfin migré de Wordpress vers Hugo - partie 1

Mon, 22 Nov 2021 08:00:00 +0000

Cette article fait partie d’une suite d’articles :

Plus de 2 ans et demi

Ca fait plus de 2 ans et demi que je râle que j’en ai ma claque de Wordpress.

Stack LEMP à maintenir, perfs bof (j’ai du mettre un cache pour passer sous la seconde, wtf…), plugins aux MAJs hasardeuses, failles de sécu, pas de support propre du markdown, éditeur à ch*** (Gutenberg, je te hais), … you name it.

Après 12 ans de blogging, il était temps de faire l’effort et de quitter Wordpress pour quelque chose qui me convient mieux : un moteur de blog statique (rien de dynamique dans ce que je poste) en markdown (parce que de toute façon c’est comme ça que j’écris mes articles à la base). Le tout dans git pour historiser tout ça.

Et j’ai choisi Hugo pour des raisons que je détaille dans l’article 2019 “Comment migrer de Wordpress à Hugo” si ça vous intéresse.

Forcément, c’est pas si facile

J’en parlais déjà dans l’article de 2019 : migrer de Wordpress à Hugo, forcément ce n’est pas si facile. D’ailleurs, j’avais même abandonné l’idée devant l’ampleur da tâche !

Ce n’est pas tant la partie technique (installation de Hugo, export du blog existant) le problème. En quelques minutes, on a un blog fonctionnel, l’export prend guère plus de temps. Rajouter l’outillage pour automatiser certaines tâches prend un peu de temps mais rien d’incroyable.

Mon problème était plutôt que je voulais obtenir au moins aussi bien que ce que j’avais avant, existant inclus.

Et c’est là que le bat blesse : wordpress, avec mes 12 ans (350 articles) d’historique, c’est au fil des années 15 façons différentes d’afficher du HTML… que le plugin d’export gère comme il peut ! Nous y reviendrons.

Je vais donc vous guider un peu sur la partie technique, puis j’aborderai ensuite les points pénibles du nettoyage du markdown, qui m’a pris un bonne partie de mes vacances (plusieurs journées à ~2-3 heures par jour). Il y aura aussi, plus tard, des articles sur l’outillage à mettre en place pour se faciliter la vie au quotidien.

Installation

L’installation en elle même est triviale. On a un binaire compilé en go packagé dans un .deb (ou les sources si vous voulez le builder vous même) disponible sur github. Fin.

sudo apt update
sudo apt upgrade

export VER="0.88.1"
wget https://github.com/gohugoio/hugo/releases/download/v${VER}/hugo_${VER}_Linux-64bit.deb
# ou https://github.com/gohugoio/hugo/releases/download/v${VER}/hugo_extended_${VER}_Linux-64bit.deb
sudo apt install ./hugo*_0.88.1_Linux-64bit.deb

A noter que dans mon cas, je n’ai pas téléchargé la version ci dessus, mais la version “extended”, nécessaire pour le thème que j’ai choisi, mais le principe est le même.

Initialisation du site et du dépôt git

Hugo est maintenant disponible sur votre machine.

A partir de là, je vous invite fortement à versionner tout ce que vous allez faire avec votre blog. C’est bien entendu optionnel mais pourquoi se priver de toute la puissance du couple markdown + git ?

On commence par créer un dossier puis on génère un squelette de site vierge avec hugo new site :

mkdir hugo && cd hugo
hugo new site toto
Congratulations! Your new Hugo site is created in toto.
Just a few more steps and you're ready to go:
1. Download a theme into the same-named folder.
Choose a theme from https://themes.gohugo.io/ or
create your own with the "hugo new theme <THEMENAME>" command.
2. Perhaps you want to add some content. You can add single files
with "hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>".
3. Start the built-in live server via "hugo server".
Visit https://gohugo.io/ for quickstart guide and full documentation.

A partir de là, on va pouvoir initialiser notre dépôt git

cd toto
git init

Bon, si jamais vous lancez la génération du blog avec simplement la commande de preview hugo server, vous allez être assez déçus, ça donne une page blanche. Mais, ça marche !

hugo server
Start building sites …
hugo v0.88.1-5BC54738+extended linux/amd64 BuildDate=2021-09-04T09:39:19Z VendorInfo=gohugoio
WARN 2021/11/14 06:57:47 found no layout file for "HTML" for kind "taxonomy": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2021/11/14 06:57:47 found no layout file for "HTML" for kind "home": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2021/11/14 06:57:47 found no layout file for "HTML" for kind "taxonomy": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.

 | EN
-------------------+-----
 Pages | 3
 Paginator pages | 0
 Non-page files | 0
 Static files | 0
 Processed images | 0
 Aliases | 0
 Sitemaps | 1
 Cleaned | 0

Built in 1 ms
Watching for changes in /toto/{archetypes,content,data,layouts,static}
Watching for config changes in /toto/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Ajout d’un thème

Avant même de commencer à ajouter du contenu, il est probable que vous allez vouloir choisir un thème. Il existe une liste de thèmes, plus fournie qu’en 2019, disponible ici.

Une fois le thème choisi, on va l’ajouter au site à l’aide de la (très utile) commande git git submodule qui va nous permettre de gérer notre thème et ses mises à jour avec git sans pour autant commiter tous les fichiers.

Dans mon cas j’ai choisi le thème “stack” mais le principe est grosso modo le même pour tous (à quelques détails d’implémentation près) :

cd themes/
git submodule add https://github.com/CaiJimmy/hugo-theme-stack.git
cd ..

Avant le premier article !

Si on veut bosser un peu proprement, on va vouloir éviter de commiter n’importe quoi. Comme hugo est un générateur de blog statique, on va bien entendu éviter de commiter le code statique généré par la commande hugo.

On utilise simplement un fichier .gitignore à la racine du projet pour ignorer tout ce qui est technique ou qui n’est pas du code :

cat > .gitignore << EOF
themes
resources/_gen
assets/jsconfig.json
public
EOF

On va aussi vouloir paramétrer a minima notre site. Vous aurez peut être remarqué qu’il existe un fichier config.toml généré par défaut par la commande hugo new site. Il s’agit de “l’ancienne” manière de faire de la configuration Hugo, mais surtout d’un fichier agnostique du thème utilisée. Généralement, il vaut mieux le supprimer et repartir du fichier d’exemple inclus avec votre thème.

Dans mon cas, il s’agit du fichier theme/hugo-theme-stack/config.yaml que j’ai donc copié à la racine du projet et modifié pour correspondre à mon site et mes besoins.

baseurl: https://blog.zwindler.fr
languageCode: fr-fr
theme: hugo-theme-stack
title: "Zwindler's Reflection"
[...]

Le premier commit

C’est un petit moment agréable dans n’importe quel projet informatique. Le premier commit.

Bon moi, comme j’ai hébergé le dépôt sur Github et qu’ils ont décidé de renommer master en main dans le nom de la branche par défaut on a un peu de gymnastique à faire, mais pourquoi pas.

git add .
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:zwindler/example.org.git
git push -u origin main

Le “code” de notre (absence de) blog est publié Internet :)

Et en prod ?

Vous pouvez donc commencer à écrire (dans content/post), tester votre blog en local, puis pousser le code sur git. Mais si jamais vous voulez héberger votre site ailleurs que sur votre laptop (et je parie que c’est le cas) ?

Et bien c’est là où c’est chouette d’utiliser git et un dépôt accessible depuis Internet. Vous n’avez qu’à reproduire l’installation de hugo, ajouter votre dépôt, initialiser les submodules (notre thème) et le tour est joué !

export VER="0.88.1"
wget https://github.com/gohugoio/hugo/releases/download/v${VER}/hugo_${VER}_Linux-64bit.deb
# ou https://github.com/gohugoio/hugo/releases/download/v${VER}/hugo_extended_${VER}_Linux-64bit.deb
sudo apt install ./hugo*_0.88.1_Linux-64bit.deb

git clone https://github.com/zwindler/toto.git
git submodule init
git submodule update

hugo

Normalement, le site devrait se générer, comme en local. Si vous n’avez pas d’historique à migrer, comme moi, vous êtes donc l’heureux propriétaire d’un blog statique fonctionnel :-). La classe !

Sinon, dans le prochain article, j’aborderai un plus gros morceau, à savoir l’export et le nettoyage du markdown depuis un Wordpress existant.