Hugo on Pascal's weblog

Hugo : Installation de remark42 pour les commentaires

Thu, 16 Jul 2026 16:18:48 +0000

Je poursuis mon projet de passer le blog de WP à Hugo. Maintenant que j’ai installé mon serveur Hugo en local, que j’ai trouvé un thème, et que je l’ai personnalisé (voir article précédent), il est temps de penser au système de commentaires que je souhaite ajouter, et à le tester.

Comme je le disais dans l’article à propos de migrer le blog vers Hugo, j’ai choisi Remark42 comme système de commentaire. Il a plusieurs qualités qui m’ont intéressé :

on peut l’auto-héberger dans un container docker.
le thème Stack que j’ai choisi le supporte de base (utile surtout pour le css).
on peut importer les commentaires du site Wordpress que l’on migre.
Il est basé sur la sécurité et le respect de la vie privée.
Il est recommandé par l’outil de migration wp2hugo.

Il coche donc toutes les cases. Il lui manque peut-être une interface d’administration, mais est-ce vraiment utile ? on peut quand même bloquer un utilisateur, supprimer un commentaire, désactiver les commentaires pour un article. L’essentiel est là.

On trouve quelques tutos pour l’installer et le paramétrer comme par exemple :

C’est donc parti pour l’installation !

Docker

On commence bien sûr par installer le container Docker. Comme d’habitude, j’utilise Dockge pour ce faire, avec le fichier compose.yaml suivant (qui sera modifié par la suite, mais c’est une base pour démarrer) :

services:
  remark:
    image: ghcr.io/umputun/remark42:latest
    container_name: remark42
    hostname: remark42
    restart: always
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "5"
    # uncomment to expose directly (no proxy)
    ports:
      - 8132:8080
    #  - "443:8443"

    # uncomment to expose to reverse proxy running on the same host but not in docker
    #ports:
    #  - "127.0.0.1:8080:8080"

    environment:
      - REMARK_URL=https://remark42.mon-domaine.fr
      - SECRET=xxxxx
      - DEBUG=true
      - AUTH_GOOGLE_CID
      - AUTH_GOOGLE_CSEC
      - AUTH_GITHUB_CID=xxxxxxxxxxxxxxxxxxxxxxx
      - AUTH_GITHUB_CSEC=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
      - AUTH_FACEBOOK_CID
      - AUTH_FACEBOOK_CSEC
      - AUTH_DISQUS_CID
      - AUTH_DISQUS_CSEC
      # Enable it only for the initial comment import or for manual backups.
      # Do not leave the server running with the ADMIN_PASSWD set if you don't have an intention
      # to keep creating backups manually!
      - ADMIN_PASSWD=remark42
    volumes:
      - /srv/dev-disk-by-uuid-wwww-xxxx-yyyy-zzzz/AppData/remark42/var:/srv/var
networks: {}

J’ai laissé les paramètres d’authentification des réseaux sociaux, mais je n’utiliserai que Github, dont les paramètres sont expliqués plus bas.
J’ai défini au niveau de mon hébergeur un sous-domaine pour ce serveur.
Le paramètre REMARK_URL doit être l’adresse externe par laquelle le service sera utilisé.
Mon proxy (swag) tourne dans un autre container, et j’y ai ajouté un fichier remark42.subdomain.conf standard.
Le paramètre ADMIN_PASSWD est activé pour pouvoir importer les commentaires de WP. Je le désactiverai ensuite.

On le lance, et ajoute PING à l’adresse du serveur : on reçoit “pong”, et donc le service tourne ! :cool:

Autorisations

Remark42 supporte l’identification via les réseaux sociaux de type Facebook, Apple ou Google : je ne les traiterai pas ici, et je n’ai pas l’intention de les activer pour mon blog. Je souhaite autoriser les commentaires anonymes, ceux avec un compte mail classique, et pour le fun j’ai ajouté Github.

Mail

Voilà les paramètres à ajouter au fichier compose.yaml de remark42, à modifier en fonction de votre fournisseur :

SMTP_HOST=smtp.mail.com
SMTP_PORT=465
SMTP_TLS=true
SMTP_STARTTLS=
SMTP_USERNAME=user@exemple.fr
SMTP_PASSWORD=mot_de_passe
NOTIFY_USERS=email
NOTIFY_EMAIL_VERIFICATION_SUBJ # "Email verification" by default
NOTIFY_ADMINS=email
NOTIFY_EMAIL_FROM="Remark42 notifications"
ADMIN_SHARED_EMAIL=administrateur@mail.fr
AUTH_ANON=true # enable anonymous commenting

Les paramètres SMTP_ sont obligatoires pour utiliser les fonctions de mail de Remark42.
Les paramètres NOTIFY_ permettent à l’utilisateur et/ou à l’administrateur de recevoir un mail en cas de nouveau commentaire sur l’adresse définie avec ADMIN_SHARED_EMAIL.
Enfin, le paramètre AUTH_ANON autorise les commentaires anonymes.

Remark42 a l’air assez pointu sur la sécurité, et lors de votre premier commentaire, un TOKEN vous est envoyé par mail que vous devrez copier/coller pour pouvoir envoyer votre commentaire.

Concernant l’autorisation de commentaires anonymes, à voir à l’usage, car sans les plugins WP de filtrage et autres détections de commentaires indésirables envoyés par des bots (et ce n’est pas ça qui manque !), je ne sais pas du tout quel sera la situation avec Hugo et Remark42 sur ce sujet. Je devrai peut-être annuler les commentaires anonymes.

GitHub

Il faut d’abord créer un nouveau “OAuth App”: https://github.com/settings/developers. Renseigner “Application Name” and “Homepage URL” pour votre site. Sous “Authorization callback URL” saisir l’URL de type FQDN suivie de /auth/github/callback, soit par exemple : https://remark42.mysite.com/auth/github/callback

Noter le Client ID (as AUTH_GITHUB_CID) et le Client Secret ( AUTH_GITHUB_CSEC) pour les renseigner dans le fichier compose.yaml (voir plus haut).

Pendant la manip, j’ai eu cette erreur :

C’était le paramètre REMARK_URL dans le fichier compose.yaml qui était incorrect (je l’avais renseigné au départ avec une adresse locale 192.168.1.x). Il doit absolument être une l’adresse web accessible de l’extérieur :

REMARK_URL=https://remark42.mon-domaine.fr

Utilisation

Voilà, on peut donc s’identifier via Github, mail, ou choisir le mode anonyme, puis poster un commentaire.

Et cerise sur le gâteau, Remark42 permet aussi de voter pour un commentaire :

Modèles pour les mails ou les messages d’erreur

Pour aller un peu plus loin, on peut créer ses propres “templates” de messages envoyés par Remark42, pour les franciser par exemple. Pour un serveur en Docker, il faut récupérer les fichiers sources sur le site gihtub: https://github.com/umputun/remark42/tree/master/backend/app/templates/static

Puis les éditer, les traduire, et les sauvegarder dans un dossier customised_templates créé à la même hauteur que le dossier var. Et on ajoute un nouveau volume pour chaque fichier dans le fichier compose.yaml :

volumes:
  - ./var:/srv/var
  - ./customised_templates/email_confirmation_login.html.tmpl:/srv/email_confirmation_login.html.tmpl:ro
  - ./customised_templates/email_confirmation_subscription.html.tmpl:/srv/email_confirmation_subscription.html.tmpl:ro
  - ./customised_templates/email_reply.html.tmpl:/srv/email_reply.html.tmpl:ro
  - ./customised_templates/email_unsubscribe.html.tmpl:/srv/email_unsubscribe.html.tmpl:ro
  - ./customised_templates/error_response.html.tmpl:/srv/error_response.html.tmpl:ro

Une fois le serveur redémarré, les fichiers modifiés sont bien utilisés :

Administration

Pas d’interface web pour gérer les commentaires, c’est peut-être le point faible de remark42. Il existe cependant des solutions externes, comme celle-ci : https://github.com/lauralesteves/remark42-admin-ui mais je ne l’ai pas installée. Je ne suis pas certain d’en avoir besoin. Car il y a tout de même moyen de réaliser certaines actions :

Afficher les paramètres : liste les utilisateurs cachés ou bloqués.
Désactiver les commentaires pour l’article. Peut être réactivé si on le souhaite.
Bloquer un utilisateur définitivement ou temporairement.
Effacer un commentaire.

Il faut renseigner le paramètre suivant dans le fichier compose.yaml pour définir un administrateur :

ADMIN_SHARED_ID=github_xxxxxxxxxxxxxxxxxxxxxxx

On trouve cet ID en s’identifiant avec son compte Github par exemple sur la page d’un article, comme si l’on voulait poster un commentaire, puis on clique sur son nom : on trouve alors en haut à droite son ID :

ou avec son compte mail :

Une fois identifié comme administrateur, on a accès à certaines fonctions, comme afficher les utilisateurs cachés ou bloqués, ainsi que désactiver les commentaires sur un article donné.

Import

Maintenant que tout est prêt, il faut importer les commentaires du site WP que l’on souhaite migrer. Remark42 propose fort heureusement cette possibilité, et la documentation est ici. Cette opération est importante et à faire immédiatement, car elle va écraser tous les commentaires existants (ceux ayant servis pour les tests par exemple).

On part donc du fichier d’export au format XML généré par WP (Panneau d’admin - Outils - Export) comme on a fait pour Hugo. Il faut ensuite l’éditer pour remplacer l’URL du site si celle-ci est destinée à changer. Par exemple si j’importe les commentaires du blog WP à l’adresse https://wptest.pled.fr, mais que mon futur blog se trouvera à l’adresse https://myhugo.pled.fr, alors il faut éditer le fichier XML et remplacer toutes les occurrences correspondantes avec la nouvelle URL.

Une fois ceci fait, il faut copier le fichier d’export dans le dossier /srv/var du container, puis lancer la commande suivante qui va importer les commentaires :

pascal@NAS:/srv/dev-disk-by-uuid-071a-91e2-4184-971f-7697/AppData/remark42/var$ sudo docker exec -it remark42 import -p wordpress -f /srv/var/wptest-export.xml -s remark

Côté log du container docker, on doit voir quelque chose de ce style :

remark42  | 2026/07/05 08:41:33.969 [DEBUG] {api/migrator.go:236 api.(*Migrator).runImport} import request for site=remark, provider=wordpress
remark42  | 2026/07/05 08:41:34.268 [INFO]  {migrator/wordpress.go:153 migrator.(*WordPress).convert.func1} converted 4 comments, {inpItems:563 failedItems:0 inpComments:4 failedComments:0 rejectedComments:0}
remark42  | 2026/07/05 08:41:34.276 [DEBUG] {migrator/wordpress.go:85 migrator.(*WordPress).Import} imported 4 comments to site remark
remark42  | 2026/07/05 08:41:34.276 [DEBUG] {api/migrator.go:250 api.(*Migrator).runImport} import request completed. site=remark, provider=wordpress, comments=4

On voit clairement que les quatre commentaires de test ont bien été importés.

Dépannage

Si vous ne voyez pas les commentaires malgré les logs positifs du container, il s’agit probablement d’un problème d’URL. Les commentaires sont stockés avec l’URL de l’article concerné, et celle-ci doit absolument correspondre. Elle peut être erronée, ou simplement être en http au lieu de https, ou même manquer d’un “/” en fin d’adresse. Il va donc falloir vérifier ces points.

Dans le navigateur, afficher un article censé avoir des commentaires, et vérifier dans la console (outils dev web) du navigateur la requête réseau (onglet network) de type GET api/v1/find?...&url=<URL> effectuée, et vérifier particulièrement la valeur de l’URL réclamée, ce doit être celle de votre site, par exemple :

https://remark42.mon-nas.fr/api/v1/find?site=remark&url=https%3A%2F%2Fmon-site-hugo.fr%2Farticle-avec-bouts-de-code%2F&sort=-active&format=tree

En parallèle, aller voir les URLs stockées par remark42 pour les comparer : pour cela, exécutez la commande suivante (sur une seule ligne) :

$ sudo docker exec remark42 backup -s remark -f /srv/var/dump.gz && \
sudo docker exec remark42 sh -c "gunzip -c /srv/var/dump.gz | grep -oE '\"url\":\"[^\"]+\"' | sort | uniq -c"
remark42 v1.16.0-556e0a7-20260522T13:32:16
2026/07/06 11:25:10.007 [INFO]  {cmd/backup.go:26 cmd.(*BackupCommand).Execute} export to ./var/backup, site remark
2026/07/06 11:25:10.007 [DEBUG] {cmd/backup.go:35 cmd.(*BackupCommand).Execute} export file /srv/var/dump.gz
2026/07/06 11:25:10.093 [INFO]  {cmd/backup.go:78 cmd.(*BackupCommand).Execute} export completed, file /srv/var/dump.gz
      2 "url":"https://mon-site-hugo.fr/article-avec-bouts-de-code/"
      2 "url":"https://mon-site-hugo.fr/article-avec-citation/"

Si la commande ne passe pas, allez voir les backups, ou créez-en un, puis éditer le fichier :

$ sudo docker exec -it remark42 backup -s remark

NOTE: le paramètre ADMIN_PASSWD doit être activé sur le serveur pour que la commande fonctionne.

Puis récupérer dans le dossier /srv/var/backup le fichier de backup créé ( userbackup-remark-20260706T045628.gz par exemple). Il reste à décompresser le fichier puis à l’éditer. On peut alors vérifier l’URL stockée dans Remark42 :

{"id":"40","pid":"","text":"ceci est un commentaire premier niveau\n","user":{"name":"pled","id":"wordpress_8d4451bb47d8fcd71060d39bada39c4b01818ce3","picture":"","ip":"c5e2c316a3678a6bd0723a79aad2b6964f805917","admin":false},"locator":{"site":"remark","url":"https://myhugo.pled.fr/article-avec-bouts-de-code"},"score":0,"vote":0,"time":"2026-06-09T15:49:33Z","imported":true,"title":"Article avec bouts de code"}

Si les URLs diffèrent, le plus simple est sans doute de modifier le fichier d’export WP à l’aide d’un éditeur de texte, modifier toutes les URLs pour correspondre à ce que l’on attend, puis relancer l’import (qui écrasera l’existant).

On peut aussi créer un fichier remap.txt contenant sur une line les deux URLs concernées sur la même ligne, comme ceci par exemple :

https://hugo.mon-site.fr/* https://hugo.mon-site.fr/posts/*

Puis exécuter le commande suivante :

$ sudo docker exec remark42 remark42 remap -s remark -f /srv/var/remap.txt

Conclusion

Voilà, le système de commentaire est installé et fonctionnel. Cela m’a paru très compliqué au départ, mais finalement, en y allant étape par étape, tout s’est très bien passé.

Le seul problème que j’ai eu a été pour l’importation des commentaires, et c’était parce que j’avais oublié de renseigner dans le site Hugo le paramètre suivant dans le fichier hugo.toml :

baseURL = 'https://hugo.pled.fr/'

Donc une erreur de ma part à force de tester des choses sur Hugo en même temps, en réinstallant, repartant de zéro, etc…

Finalement, je suis très satisfait de ce résultat, Remak42 a l’air très bien, sobre et fonctionnel, exactement ce que je cherchais.

Hugo avec thème Stack : installation en local

Thu, 16 Jul 2026 14:30:08 +0000

Dans un précédent article, j’expliquais mon idée de migrer mon blog Wordpress sous Hugo, pour des raisons de performance et d’efficacité, mais aussi de simplification car si Wordpress permet de faire beaucoup de choses, je n’en ai pas de réel besoin, alors autant passer à quelque chose de plus simple et de totalement opensource.

Dans cette optique, la première étape est d’installer Hugo en local sur le PC afin de pouvoir commencer à l’utiliser, puis à adapter un thème à ce que je souhaite obtenir comme apparence.

Cet article est assez long puisque l’on va partir du thème Stack de départ, totalement vide :

Pour arriver à ça :

C’est parti, il y a du boulot ! :wink:

Installation

La première chose à faire est d’installer le paquet Hugo, comme on le ferait pour n’importe quel autre logiciel, et donc sur EndeavourOS taper la commande suivante :

$ sudo pacman -S hugo

Il faut ensuite choisir un thème sur cette page, et il en existe de tous types, le choix est vaste même en sélectionnant le type “Blog”. Pour chaque thème, une démo est accessible, c’est donc assez bien fait et cela aide à faire son choix.

En ce qui me concerne, j’ai choisi le thème Stack qui correspond à peu près à ce que je souhaite : une présentation classique des articles dans l’ordre chronologique, avec une image pour chaque article, une colonne (sidebar) de chaque côté, histoire de ne pas trop changer avec le thème actuel sur WP. Enfin, il dispose d’un mode “Dark” intégré.

Puis on suit la doc officielle https://gohugo.io/getting-started/quick-start/ et on passe les commandes suivantes qui vont créer le site, installer le thème stack et l’activer :

$ mkdir Hugo
$ cd Hugo
$ hugo new project pled
$ cd pled
$ git init
$ git submodule add https://github.com/CaiJimmy/hugo-theme-stack themes/stack
$ echo "theme = 'stack'" >> hugo.toml

Voilà, il suffit maintenant de lancer hugo en tant que serveur en se plaçant dans le répertoire avec la commande $ hugo server, pour obtenir immédiatement un site disponible localement, avec le thème stack, mais totalement vide :

$ hugo server
Watching for changes in /Hugo/pled/archetypes, /Hugo/pled/assets, /Hugo/pled/content, /Hugo/pled/data, /Hugo/pled/i18n, /Hugo/pled/layouts, /Hugo/pled/static, /Hugo/pled/themes/stack/archetypes, /Hugo/pled/themes/stack/assets/{icons,scss,ts}, /Hugo/pled/themes/stack/data, ... and 2 more
Watching for config changes in /Hugo/pled/hugo.toml, /Hugo/pled/themes/stack/config/_default
Start building sites …
hugo v0.163.3+extended+withdeploy linux/amd64 BuildDate=unknown

                  │ EN
──────────────────┼────
 Pages            │  8
 Paginator pages  │  0
 Non-page files   │  0
 Static files     │  0
 Processed images │  0
 Aliases          │  3
 Cleaned          │  0

Built in 24 ms
Environment: "development"
Serving pages from disk
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

Il ne reste plus qu’à se rendre sur l’adresse indiquée : http://localhost:1313 :

On ne peut pas dire que ce soit compliqué ! Par contre, ça manque de contenu ! :oops:

Contenu

Il y a un dossier “Demo” dans le thème ( themes/stack/demo). On peut le visualiser en lançant le script run.sh qui se trouve dans ce dossier, mais le fichier README.md précise :

This is an example site used for solely for testing purposes. It is not meant to be used as a template for your site.

Cela vaut le coup de le lancer et de voir le résultat, pour avoir une idée de ce que à quoi peut ressembler le thème. Quitte à tout effacer ensuite et repartir d’un site propre. C’est aussi un bon point de départ pour le transformer et le personnaliser ensuite. À moins de préférer partir de rien et de tout faire soi-même en suivant la documentation du thème. À chacun de choisir !

J’ai choisi une solution intermédiaire : j’ai installé la démo, regardé ce que l’on peut faire, puis suis reparti d’un site vide, en m’inspirant des fichiers du dossier demo au fur et à mesure de ce que je voulais faire, et en les personnalisant à chaque fois.

D’ailleurs, il faudra toujours penser à faire les modifications à la racine du site, en récréant l’arborescence du fichier, afin d’éviter tout perdre lors d’une mise à jour du thème. Par exemple, on récupère le fichier Hugo/pled/themes/stack/demo/config/_default/menu.toml et on le copie dans Hugo/pled/config/_default/menu.toml. Si les dossiers n’existent pas, il suffit de les créer pour avoir la même arborescence. Car si j’ai bien compris, Hugo regarde toujours d’abord à la racine du site, et seulement ensuite dans le dossier du thème.

Le plus simple pour l’instant est de copier tout le dossier themes/stack/demo/ content/ dans pled/content, soit les dossiers categories, page et post, à l’exception des fichiers _index.ja.md, _index.zh.md et _index.zh-hant-tw.md qui sont destinés au langues asiatiques, et donc inutiles (au moins dans mon cas).

Les articles vont immédiatement apparaître dans le navigateur, ainsi qu’un menu dans la colonne de gauche :

Le menu à gauche, ce sont en fait les pages définies dans le dossier pages que l’on vient de copier :

Il est donc très facile de les franciser en éditant le fichier index.md de chaque dossier.

Apparence

Il s’agit maintenant personnaliser le thème, et pour cela il va falloir modifier essentiellement les trois fichiers suivants : hugo.toml à la racine du site, puis dans themes/stack/config/_default/ : menu.toml et params.toml.

Fichier hugo.toml

Le premier fichier à aller mettre à jour est le fichier hugo.toml, à la racine du site. Son contenu par défaut est le suivant :

baseURL = 'https://example.org/'
locale = 'en-us'
title = 'My New Hugo Project'
theme = 'stack'

Que l’on peut vite transformer en :

baseURL = 'https://myhugo.pled.fr/'
locale = 'fr'
title = "Pascal's weblog"
theme = 'stack'

Le param baseURL doit représenter l’URL réelle de votre site quand il sera en ligne (ce sera nécessaire quand le site statique sera copié à cette adresse).
Le paramètre theme a été mis à jour quand on a installé le thème stack.
J’ai utilisé un double guillemet pour encadrer le param title, puisque j’ai un simple guillemet dans le titre de mon blog.

Fichier menu.toml

Le fichier menu.toml va permettre d’ajouter les icônes des réseaux sociaux que vous voulez afficher. Dans un premier temps, je décide d’afficher une icône pour Github, Mail et Mastodon. On va d’abord récupérer le fichier Hugo/pled/themes/stack/demo/config/_default/menu.toml et le copier dans Hugo/pled/config/_default/menu.toml (créer les dossiers manquants).

Mais si l’icône Github est bien présente dans le thème par défaut, ce n’est pas le cas pour le Mail et Mastodon. Il va donc falloir créer ces icônes.

Icônes

Je suis allé sur le site https://tablericons.com/ pour chercher les icônes manquantes. Une fois la bonne icône trouvée, on édite le code du fichier .svg correspondant (c’est un fichier texte). J’ai créé ainsi un fichier mail.svg et un autre brand-mastodon.svg. Et on l’adapte le dessin au thème en allant voir le code de l’icône github par exemple (dans themes/stack/assets/icons), pour notamment la couleur, l’épaisseur du trait, etc… afin d’avoir des icônes avec le même style. Ce sont les infos au début du fichier .svg qui définissent tout ça :

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="24"
  height="24"
  viewBox="0 0 24 24"
  fill="none"
  stroke="currentColor"
  stroke-width="2"
  stroke-linecap="round"
  stroke-linejoin="round"
>

La suite du fichier .svg, représentent les données numériques qui vont dessiner l’icône, donc on n’y touche pas.

Une fois les icônes requises créées et copiées dans le dossier themes/stack/assets/icons, on peut modifier le contenu du fichier menu.toml comme ceci :

[[social]]
    identifier = "mail"
    name       = "Mail"
    url        = "mailto:myname@myprovider.com"

    [social.params]
        icon = "mail"

[[social]]
    identifier = "github"
    name       = "GitHub"
    url        = "https://github.com/myname/"

    [social.params]
        icon = "brand-github"

[[social]]
    identifier = "mastodon"
    name       = "Mastodon"
    url        = "https://mastodon.fr/@myname"

    [social.params]
        icon = "brand-mastodon"

Et les icônes souhaitées apparaissent dans le menu de gauche :

Fichier params.toml

Celui-ci contient plus d’infos et va permettre de continuer à personnaliser le thème.

Widgets

Et on commence par le menu de droite, proposé par le thème. Ce sont les “widgets”, et ils s’activent dans ce fichier params.toml, que l’on modifie donc comme suit :

[widgets]
    homepage = [
        { type = "search" },
        { type = "archives", params = { limit = 5 } },
        { type = "categories", params = { limit = 10 } },
        { type = "tag-cloud", params = { limit = 10 } },
    ]
    page     = []

NOTE : on peut activer ces widgets pour la homepage et/ou pour les pages… Pour l’instant, je ne les déclare que pour la homepage, ce qui nous affiche dans la partie droite de la page d’accueil :

Je ne pense pas garder la ligne “tag-cloud”, puisque sur mon blog, je n’utilise que les catégories. Mais la possibilité est là, les “mots clés” se définissant dans le front matter de chaque article (tout comme les catégories) :

---
title: Image Gallery
description: Showcasing the built-in image gallery support
date: 2026-01-26
slug: image-gallery
image: helena-hertz-wWZzXlDpMog-unsplash.jpg
categories:
    - Documentation
tags:
    - Gallery
    - Photoswipe
toc: false
---

Vous remarquez au passage le paramètre toc qui permet d’afficher facilement une table des matières pour un article donné (écrit en markdown je le rappelle). Cela montre la puissance d’Hugo et la facilité d’utilisation, comparé à Wordpress.

Avatar

Puis on va ajouter une icône (avatar) dans le dossier Hugo/pled/assets/img et on modifie la section sidebar comme suit :

[sidebar]
    compact = false
    emoji    = "🍥"
    subtitle = "Mon prochain blog fait avec Hugo"
    avatar  = "img/avatar.png"

Voilà le résultat après avoir relancé Hugo :

Pour la petite emoji 🍥, je l’ai récupérée sur le site du thème, afin d’en avoir la dernière version. Il s’agit de l’emoji “Fish Cake with Swirl”, qui me fait penser au logo Debian ! Plus d’infos sur cette page.

Favicon

Concernant la favicon du site, qui s’affiche dans l’onglet du navigateur, il suffit d’ajouter cette ligne dans le fichier, après avoir copié le fichier favicon.png, toujours dans le dossier Hugo/pled/assets/img :

favicon = "img/favicon.png"

Copyright

On peut personnaliser les informations de Copyright :

[footer]
    since      = 2005
    customText = "Blog ouvert depuis le 25 décembre 2005"

Commentaires

Dans ce fichier, on va aussi trouver tous les systèmes de commentaires supportés par le thème. Une fois votre système de commentaires choisi (Hugo n’intègre rien à ce sujet, ce n’est pas de son ressort), on peut supprimer tous les autres devenus inutiles.

J’ai choisi Remark42. Je ne laisse donc que ceci :

[comments]
    enabled  = true
    provider = "remark42"

    [comments.remark42]
        host                    = "https://remark42.monserveur.fr"
        site                    = "remark"
        locale                  = "fr"
        max_shown_comments      = 15
        show_email_subscription = true

Divers

Il y a d’autres paramètres dans ce fichier, comme les diagrammes Mermaid, qu’il convient de laisser au cas où le besoin s’en fait sentir un jour.

Les “AlertIcon” définies dans ce fichier seront aussi pratiques pour afficher des messages de ce style dans un article :

Voilà pour l’essentiel de ce que j’ai vu dans ce fichier params.toml.

Page Archive

La page Archive est plutôt intéressante. Elle affiche en haut la liste des catégories avec une image (ou pas), ce qui permet de filter selon la catégorie souhaitée :

Puis elle affiche les articles par date, en ligne, avec une icône correspondant à l’image en tête de l’article (s’il y en une de définie dans le front matter). Mais elle est affichée à droite dans la page, après le bloc contenant le titre :

Je préfère avoir l’image affichée à gauche, comme je l’avais pour mon blog WP.

On procède toujours de la même façon, en copiant le fichier que l’on veut personnaliser du thème vers la racine du site. Ici, je copie Hugo/pled/themes/stack/layouts/_partials/article-list/compact.html dans Hugo/pled/layouts/_partials/article-list/compact.html.

Puis je le modifie en déplaçant le bloc suivant AVANT le bloc <div class="articles-details">

{{- $image := partial "helper/image" (dict "Image" .Params.image "Resources" .Resources "Context" .) -}}
        {{ if $image }}

            {{ partial "helper/thumbnail-image" (dict
                "Resource" $image.Resource
                "Width" 60
                "Height" 60
                "Resize" .Site.Params.ImageProcessing.Thumbnail.Enabled
                "Attributes" (dict
                    "src" $image.Permalink
                    "alt" .Title
                    "loading" "lazy"
                    "width" $image.Width
                    "height" $image.Height
                )
            ) }}

        {{ end }}

Et le tour est joué :

Lien vers mon album Zenphoto

J’ai aussi besoin d’ajouter un lien direct vers mon album-photo Zenphoto, qui tourne sur un sous-domaine.

La première chose à faire, c’est de créer une icône Zenphoto qui n’existe pas par défaut. Cette fois je suis allé sur le site svgicons pour la trouver, puis j’ai procédé de la même manière que précédemment pour harmoniser son apparence, et j’ai copié le fichier .svg dans le dossier icons du theme.

On crée ensuite l’entrée dans le menu de gauche en l’ajoutant dans le fichier hugo.toml : c’est la méthode 2 de la doc pour créer une entrée dans le menu. Puisque l’on sort du blog (newTab: false), la limitation de ne pas avoir le lien highlighté n’est pas gênant.

[menu]
[[menu.main]]
    name = "Album Photo"
    url = "https://zenphoto.pled.fr"
    weight = 10
    identifier = "zenphoto"
    [menu.main.params]
        icon = "brand-zenphoto"
        newTab = false

et voilà mon lien vers Zenphoto qui apparaît dans le menu de gauche :

Liens Voyage

Je veux aussi ajouter un lien vers les articles de la catégorie Voyage pour les mettre en évidence. Il s’agit d’afficher tous les articles de cette catégorie en cliquant sur cette entrée. J’ai auparavant créé un article de cette catégorie pour mes tests, avec l’aide d’un outil de migration WP vers Hugo.

Là aussi, il va me falloir commencer par trouver une icône, et la copier dans le dossier du thème. On procède toujours de la même façon à ce sujet.

Cette fois, je vais utiliser la méthode 1 de la documentation. Il me suffit de créer un dossier Voyage dans Hugo/pled/content/pages, et d’y créer un fichier index.md (inspiré de celui du dossier archives) :

---
title: "Voyage"
date: 2026-05-15
layout: "voyage"
slug: "voyage"
menu:
    main:
        weight: -70
        params:
            icon: world
---

Et voilà l’entrée Voyage qui apparaît dans le menu avec l’icône que j’ai choisi :

Reste à créer le “layout” défini pour cette page “Voyage”. Il faudra créer un fichier voyage.html dans le dossier Hugo/pled/layouts. Je me suis inspiré du layout de la page archives.html, en l’adaptant pour n’afficher que les pages de la catégorie “Voyage” :

{{ define "body-class" }}template-archives{{ end }}
{{ define "main" }}

    {{ $voyage := site.GetPage "/categories/voyage" }}
    {{ with $voyage }}

                {{ partial "article-list/tile" $voyage }}

    {{ end }}

{{ $pages := where .Site.RegularPages "Params.categories" "intersect" (slice "Voyage") }}

    {{ range $pages.GroupByDate "2006" }}
    {{ $id := lower (replace .Key " " "-") }}

        {{ .Key }}

            {{ range .Pages }}
                {{ partial "article-list/compact" . }}
            {{ end }}

    {{ end }}

    {{ partialCached "footer/footer" . }}
{{ end }}

Reste à attribuer une image à cette catégorie. Pour ce faire, je crée un dossier Voyage dans Hugo/pled/categories dans lequel je copie une image de mon choix ainsi qu’un fichier _index.md avec le contenu suivant :

---
title: Voyage
description: "Articles à propos de mes voyages"
slug: "voyage"
image: "riziere.png"
style:
    background: "#2a9d8f"
    color: "#fff"
---

Et voilà le résultat en cliquant sur le menu Voyage :

Description

Avec Hugo, je peux ajouter une description pour chaque article (ça remplace l’excerpt de WP avantageusement je trouve). Ce champ description se trouve dans le front matter en début de chaque fichier .md où l’on peut ajouter les metadata de chaque article.

Dans l’article de la catégorie Voyage que j’ai créé, le front matter est comme ceci :

---
title: "Asie 2023 - Présentation"
date: 2026-05-04
slug: "asie-2023-le-voyage"
image: carte.png
description: "Description du voyage de 2023 : le parcours, les changements qu'il a fallu faire, et les cours de cuisine"
categories:
    - Voyage
---

Je souhaite que la description s’affiche dans les pages Voyage et Archive, je trouve cela plus clair. On a vu que c’est la page /pled/layouts/_partials/article-list/compact.html qui est utilisée pour ce type de vue. Je la modifie en ajoutant la partie description sous la partie title :

<div class="article-details">
            <h2 class="article-title">
                {{- .Title -}}
            </h2>

                {{ with .Params.description }}
                    <p class="section-description">{{ . }}</p>
                {{ end }}

Et voilà le résultat :

Il en sera de même pour la page Archives…

Conclusion

Voilà désormais la page d’accueil du blog : il commence à ressembler à ce que je souhaite.

La hauteur des images pour chaque article me paraît tout de même un peu grande, je préférerais carrément revenir à ce que j’ai sur WP, c’est-à-dire une petite image spécifique alignée à gauche et le texte qui commence à la même hauteur :

Mais le thème Stack ne fonctionne pas ainsi, apparemment il prend la première image de l’article et en extrait une partie qu’il redimensionne pour l’afficher comme en-tête… Ce traitement des images par le thème a l’air complexe, et je ne suis pas allé plus loin pour l’instant. J’ai tout de même trouvé comment réduire facilement la hauteur des images : il suffit de rajouter ce code CSS dans le fichier /Hugo/pled/assets/scss/custom.scss (là encore, on crée le fichier et l’arborescence) :

/* réduction hauteur images en-tête articles */
.article-image img {
  max-height: 150px !important;
  width: 100% !important;
  height: auto !important;
}

C’est déjà un peu mieux à mon goût :

Conclusion

Voilà, je vais m’arrêter là pour l’instant, le résultat obtenu est déjà pas mal je trouve. Pour l’envoyer sur mon hébergeur, il suffit d’arrêter le serveur local, puis de lancer la commande $ hugo :

$ hugo
Start building sites …
hugo v0.164.0+extended+withdeploy linux/amd64 BuildDate=unknown

WARN  Raw HTML omitted while rendering "/Backup/Hugo/pled/content/post/asie-2023-le-voyage/index.md"; see https://gohugo.io/getting-started/configuration-markup/#rendererunsafe
You can suppress this warning by adding the following to your project configuration:
ignoreLogs = ['warning-goldmark-raw-html']
WARN  Raw HTML omitted while rendering "/Backup/Hugo/pled/content/post/test-de-galerie-photo.md"; see https://gohugo.io/getting-started/configuration-markup/#rendererunsafe
You can suppress this warning by adding the following to your project configuration:
ignoreLogs = ['warning-goldmark-raw-html']
WARN  Raw HTML omitted while rendering "/Backup/Hugo/pled/content/post/Markdown Syntax/index.md"; see https://gohugo.io/getting-started/configuration-markup/#rendererunsafe
You can suppress this warning by adding the following to your project configuration:
ignoreLogs = ['warning-goldmark-raw-html']
WARN  Raw HTML omitted while rendering "/Backup/Hugo/pled/content/post/shortcodes/index.md"; see https://gohugo.io/getting-started/configuration-markup/#rendererunsafe
You can suppress this warning by adding the following to your project configuration:
ignoreLogs = ['warning-goldmark-raw-html']

                  │ EN
──────────────────┼─────
 Pages            │ 101
 Paginator pages  │   3
 Non-page files   │  12
 Static files     │  24
 Processed images │  21
 Aliases          │  26
 Cleaned          │   0

Total in 219 ms

Cette commande génère toutes les pages statiques en HTML pour pouvoir afficher le site comme il se doit. Pour l’instant, je ne tiens pas compte des WARN, ça n’a pas l’air très important. Une fois ceci fait, il ne reste plus qu’à envoyer le contenu du dossier public sur le site prévu, et le blog est disponible.

Cette découverte de Hugo et du thème Stack s’est révélée très intéressante. Je suis tout de même arrivé à personnaliser pas mal de trucs assez facilement. J’ai vu aussi que certaines parties peuvent être complexes, notamment ces pages HTML qui sont un mix de pur html et de shortcodes Hugo que je ne maîtrise pas du tout pour l’instant.

Mais c’est très prometteur quand même, et tout aussi passionnant. Cela ne fait que m’encourager à continuer dans cette voie.

Migrer le blog vers Hugo

Mon, 29 Jun 2026 15:10:37 +0000

Je suis en train de réfléchir sérieusement à migrer mon blog Wordpress vers Hugo, un SSG ( S tatic S ite G enerator) qui offre simplicité et rapidité comparé à “l’usine à gaz” qu’est Wordpress. Attention, il ne s’agit pas ici pour moi de critiquer WP, je l’ai utilisé pendant assez longtemps (~20 ans) et j’étais bien content de l’avoir. Mais il est vrai que c’est assez lourd, avec le PHP, la base de données, les plugins incertains… Pour un simple blog comme le mien, je n’ai honnêtement pas besoin d’autant de complexité.

Car ce sont autant de surfaces d’attaque, avec tout ce code généré ; il suffit d’ailleurs de voir le nombre de mises à jour de WP, sans parler de la qualité des plugins que l’on a activé sur son site, plus ou moins bien écrits, plus ou moins maintenus, etc… Avec Hugo et ses pages statiques en HTML, il n’y a rien à attaquer car rien ne s’exécute. Il ne faut pour autant pas idéaliser la chose, car si on ajoute un système de commentaires (externe), il faudra gérer la question des spams, car Hugo ne propose évidemment rien sur le sujet…

L’autre aspect problématique de WP, c’est la performance (d’où le terme “usine à gaz” utilisé), et sans un hébergeur qui a toutes capacités de mise en cache et d’optimisation en tous genres, le temps d’affichage d’une page serait vraiment très long. Hugo, en tant que SSG, génère des pages statiques en HTML, et il suffit donc de les envoyer au navigateur, et c’est évidemment beaucoup plus rapide :

Hugo, c’est donc le choix de la simplicité : on écrit ses articles en markdown, et Hugo se charge de les convertir en HTML. Il y a certainement moins de possibilités qu’avec Gutenberg, l’éditeur de WP (encore qu’il y a les shortcodes dans Hugo). Il y a surtout les aspects pas du tout gérés par Hugo, comme les formulaires ou les commentaires, mais avec des solutions externes pour les remplacer.

Mais ce côté simplification me plaît, se concentrer sur le texte de l’article, et laisser tomber les petites fioritures que permet WP avec le choix d’une multitude de plugins, mais qui finalement ne sont pas indispensables. Avoir un blog très rapide, des articles qui s’affichent en un clin d’œil, et qui se concentrent sur l’essentiel, c’est tentant. Alors pourquoi pas ?

Mais qu’est-ce que ça implique vraiment ?

Découverte

Il existe beaucoup d’articles sur Hugo, le SSG est très populaire et son développement actif, ce qui est une bonne chose. Ce n’est donc pas la littérature sur le sujet qui manque, et encore moins sur la migration en venant de Wordpress. J’ai retenu ces deux articles :

Pourquoi migrer : https://benoit.gouthiere.be/blog/migration-wordpress-hugo/
Comprendre Hugo : https://www.regisphilibert.com/blog/2019/01/from-wordpress-to-hugo-a-mindset-transition/

Un autre environnement

Déjà, on change totalement d’environnement, il y aura plein de nouvelles choses à apprendre, c’est certain, à commencer par Hugo. J’ai commencé par l’installer sur mon PC, jouer un peu avec, générer les pages HMTL, les envoyer sur mon hébergeur. Il faut reconnaître que c’est assez simple et intuitif, une fois que l’on a assimilé les bases. On commence par la doc bien entendu, qui est d’ailleurs très bien faite. Et notamment la page de Quicktart, et en quelques minutes vous avez votre premier site disponible. Toutes les modifications faites sur les fichiers .md ou de configuration sont pris en compte dynamiquement, c’est très pratique quand on teste quelque chose. Et quand on le souhaite, on génère le site statique (dans le dossier public) qu’il suffit d’envoyer sur votre hébergeur par exemple, et voilà le tour est joué. Cette première approche s’est révélée facile et cela donne envie de continuer et d’approfondir.

Puis j’ai voulu choisir un thème. Et là, le thème Stack qui me plaît me renvoie sur une page Github qui me dit :

J’ai mis du temps à comprendre de quoi il retournait : en fait il recommande de l’installer sur Github comme un dépôt, qui permet de générer automatiquement le site statique toujours sur Github. De plus, le thème sera automatiquement mis à jour si une nouvelle version est publiée. On passe vraiment dans un autre monde, un monde de développeur, ce que je ne suis pas. Mais cela laisse entrevoir de nouvelles possibilités, si l’on souhaite les apprendre (ainsi qu’une certaine maîtrise de Github). Mais à priori je ne compte pas aller jusque là.

Heureusement, on peut aussi installer ce thème en local sur sa machine, et c’est ce que j’ai fait pour l’instant, ne maîtrisant pas Github (cela ferait beaucoup trop de choses nouvelles à appréhender en même temps). Je suis beaucoup plus à l’aise en local, et quand il s’agira de personnaliser le thème pour correspondre à mes souhaits, cela sera beaucoup plus facile ainsi.

Hébergeur

Un autre avantage d’Hugo, c’est de pouvoir se passer d’hébergeur, d’abord parce que les optimisations requises par WP sont désormais inutiles, et parce qu’il y a des solutions gratuites pour ce type de site statique : on peut donc utiliser les GitHub Pages, mais aussi Netlify, ou encore les Cloudflare Pages. À terme, je peux même imaginer auto-héberger mon blog sur mon NAS, tout simplement.

Il me suffira de conserver mon nom de domaine, et d’en faire ce que je veux. D’ailleurs, Github Pages supporte les “custom domain”, si je souhaitais bénéficier du déploiement automatisé mentionné plus haut.

Migration

Le projet est donc tentant mais cela implique de migrer mon blog WP, soit près de 1500 articles, et cela signifie certainement un très gros travail de migration, même s’il y a des outils et autres scripts qui sont là pour aider : en gros, on exporte le site WP au format XML (opération standard que permet le tableau d’administration de WP), puis un script va convertir tous les articles et les pages exportés au format Markdown. C’est déjà un énorme travail de fait, et disons que le texte de chaque article est correctement migré, mais qu’en est-il du reste ?

C’est-à-dire tout le HTML autre que le texte : les liens (par exemple l’attribut _target="blank" qui permet d’ouvrir le lien dans un nouvel onglet n’existe pas en markdown), les images, tableaux, mais surtout tous les différents blocs de Gutenberg que j’ai utilisé (audio, vidéo, galerie, etc…) qui utilisent un format spécifique, et d’autres cas particuliers que je découvrirai certainement au cours de l’opération. Il faudra repasser sur certaines choses, si je peux l’automatiser avec un script, ça ira, mais sinon revoir tous les articles un par un s’avérerait un énorme boulot.

Et comment seront migrées les pages de mes journaux de voyage où j’ai fait un beau “page template” avec un sommaire glissant à droite ? Probable qu’il me faudra en revoir la présentation, même si j’ai vu que les templates existaient avec Hugo (après tout ce n’est que du HTML et du CSS), donc il y aura peut-être une solution ?

Les autres choses auxquelles il faut porter attention :

Thème

Pour le thème, l’apparence globale sera revue de A à Z, à moins de vouloir le recréer à l’aide de l’AI comme je l’ai lu une fois. Pour ma part, j’ai choisi un thème disponible pour Hugo, et ce sera l’occasion de profiter de ce nouveau thème et de l’adapter à mes souhaits. Cela donnera un coup de neuf au blog, c’est très bien comme ça. Et si certaines choses disparaîtront, de nouvelles seront présentes, c’est le principe de tout changement.

Plugins

Avec WP, j’essayais de limiter le nombre de plugins au maximum, pour ne pas alourdir ni compliquer la gestion du site, mais il y en a quand même quelques uns : l’idée c’est de se passer d’eux quand c’est possible (simplification) et de voir les solutions pour les autres.

Il y a bien sûr le plugin Akismet pour lutter contre les spams, très efficace et indispensable avec WP. Je verrai comment cela va se passer sur cet aspect avec Hugo ou plutôt avec Remark42, le système de commentaires que j’ai repéré pour l’instant, et ce qu’il propose à ce sujet : sera-t-il toujours possible de conserver les commentaires anonymes ? Ce n’est pas certain.

Autre exemple : Je pensais faire une croix sur la citation que j’affiche en haut de la colonne de droite : il s’agit du plugin UtterQuotes (qui d’ailleurs n’était plus maintenu depuis des années, mais fonctionnait encore pour l’essentiel, avec une table dédiée dans la BdD). Typiquement le genre de choses qui n’existe pas sur Hugo, mais en lisant cet article, j’ai pu recréer le système. Il a aussi fallu extraire mes citations de la BdD, et les importer dans un fichier .json, pour cela Mistral AI m’a fourni un script en quelques secondes. De bonnes surprises peuvent donc aussi se produire durant la migration.

Il y a aussi d’autres plugins dont je devrais me passer, comme celui qui me permettait d’afficher la liste d’articles par catégories, sous forme d’excerpt, mais cette possibilité est présente de base avec le thème Stack que j’ai choisi.

Les commentaires

Pour revenir aux commentaires, il y a plusieurs solutions externes de proposées pour Hugo, et notamment Disqus, le plus connu. Mais il n’est pas libre, et exploite vos données, il est donc hors-jeu d’entrée pour mon blog. Certains autres se basent sur Github où il faut donc avoir un compte pour poster un commentaire, c’est un peu limitatif. Il en reste quelques autres, et il faut idéalement qu’il soit supporté par votre thème pour assurer une intégration facile.

J’ai donc commencé à regarder Remark42 de plus près, il a l’air de cocher pas mal de cases, axé sur le respect de la vie privée, et que l’on peut auto-héberger via Docker. Je n’ai donc pas tardé à installer le container sur mon NAS et commencé à jouer avec. Il permet l’authentification par email, ou par les réseaux sociaux (chose que je ne compte pas implémenter avec l’exception de Github), mais aussi les commentaires anonymes, que j’aimerais bien conserver, à voir si cela sera possible (risque de spams). Il lui manque juste une interface d’administration, mais si j’en avais besoin, j’ai vu qu’il existait des solutions externes, comme celle-ci : https://github.com/lauralesteves/remark42-admin-ui, si nécessaire. Le monde du logiciel libre est vaste…

Remark42 permet aussi d’importer les commentaires de WP, je n’ai pas encore testé à fond cette option, j’espère qu’elle fonctionne, ça m’embêterait de perdre tous les commentaires existants.

Les outils de migration

Voilà ce que j’ai vu pour l’instant sur le sujet : la plupart reposent donc sur l’export que permet de faire WP via le menu Outils - Exporter. On choisit “Tout” et on récupère un fichier .xml que l’outil va traiter. On en trouve une liste ici : https://gohugo.io/tools/migrations. Ou encore sur une liste fournie par un utilisateur sur le forum ici : https://discourse.gohugo.io/t/best-practices-or-a-smarter-way-to-create-a-60k-pages-website/46328. Mais elles ne fonctionnent pas toutes : certaines sont assez anciennes et ne sont pas mises à jour depuis plusieurs années, d’autres proposent un script python qu’ils ont créé pour eux… et qui ne fonctionne tout simplement pas ! D’autres encore s’installent comme plugins dans WP, mais de ce que j’ai pu voir, elles ne sont pas mises à jour non plus, et plutôt basiques.

J’ai retenu les deux les plus réputées qui sont :

wordpress-export-to-mardown (écrit en JS) : J’aime bien le fait qu’il permette d’organiser les articles dans une arborescence de type année/mois/article. On obtient un dossier pour chaque article, avec dans chaque un dossier images, où l’on retrouve les images de l’article. C’est l’organisation que j’aimerais retrouver. Mais il est plutôt limité : on peut dire qu’il gère les articles et les images, ainsi que les catégories. Et ça s’arrête là.

wp2hugo (écrit en Go) : le script est souvent mentionné, et il est sans doute le plus complet, gérant bien les contenus multimédias (liens videos, audio), et plein d’autres choses. Mais il crée les nouveaux articles à plat dans un répertoire, et les images sont dans le dossier static, en recréant l’arborescence de wordpress, genre static/wordpress/upload/year/month. Ce n’est pas ce que je voudrais.

En posant la question au développeur sur son projet Github, il m’a parlé d’un outil complémentaire qu’il est en train de développer, hugomanager, et qui permet entre autres, de réorganiser les posts en dossiers indépendants contenant ses propres images. Cela me conviendrait beaucoup plus. Pour l’instant, cela ne fonctionne pas, mais j’avance avec le dev sur le sujet.

Pour l’organisation en dossier “year/month” de l’ensemble des articles, j’ai aussi créé une issue, et il l’a déjà implémentée dans wp2hugo. Avec ces deux modifications, on obtiendrait avec le script un dossier posts avec à l’intérieur une organisation par année puis par mois, et pour chaque article un sous-dossier images. Ce serait parfait pour moi.

Si j’arrive grâce à lui à pouvoir résoudre les principaux problèmes de cette migration, cela va beaucoup m’aider. Il a l’air assez réactif, et prêt à ajouter des options à son outil, c’est vraiment génial ! :cool:

Conclusion

Je suis très tenté de me lancer dans cette aventure ! L’esprit me plaît, l’approche d’un site statique aussi, je vais donc continuer à creuser et faire quelques tests de migration pour évaluer le travail que j’aurais à faire.

Chez mon hébergeur Infomaniak, j’ai déjà créé un deuxième WP de test, ou je crée quelques articles et pages pour avoir un échantillon représentatif du contenu de mon blog. Puis je l’exporte en XML, et en local sur mon PC, je peux lancer le script de migration et regarder ce que cela donne dans Hugo. Parallèlement, je personnalise le thème que j’ai choisi et m’adapte aux changements que cela oblige. Je peux même pousser le HTML généré par Hugo sur un autre sous-domaine de mon hébergeur pour voir le rendu “en ligne”. Côté commentaires, Remark42 fonctionne en auto-hébergé, avec l’identification par github, mail ou de manière anonyme. Seul l’importation ne fonctionne pas pour l’instant, mais je n’ai pas vraiment creusé.

Voilà où j’en suis, ça a quand même bien avancé, je continue de tester le script de migration et de suggérer des améliorations ou créer des bugs, d’apprendre aussi sur Hugo, le thème, le système de commentaire Remark42, etc… On verra comment ce projet évolue, j’espère pour un jour faire la bascule vers ce nouveau système.