JeffGeerling.com migre vers Hugo

 (jeffgeerling.com)
2 points par GN⁺ 2026-01-06 | 1 commentaires | Partager sur WhatsApp
  • JeffGeerling.com, exploité sur une base Drupal depuis 2009, passe au générateur de site statique (SSG) Hugo afin d’améliorer l’efficacité du blog personnel
  • Les nombreux upgrades et la charge de maintenance accumulés de Drupal 6 à 10 ont été le principal déclencheur de cette transition
  • Hugo prend en charge une rédaction basée sur Markdown, ce qui simplifie une procédure de publication auparavant complexe, avec un déploiement possible en une seule ligne de commande
  • Pendant la migration, quelques problèmes peuvent survenir, comme des liens d’image erronés ou des URL perdues ; les fonctions de commentaires et de recherche seront rétablies dans une étape ultérieure
  • Pour les développeurs individuels, c’est un exemple concret des avantages d’un site statique, avec un workflow plus simple et une maintenance plus efficace

Pourquoi passer de Drupal à Hugo

  • Le site a démarré en Drupal 6 en 2009, puis a été progressivement mis à niveau vers 7, 8, 9 et 10
    • Le CMS, utilisé professionnellement pendant plus de dix ans, avait aussi été adopté pour le blog personnel
  • Après le processus de mise à niveau complexe de Drupal 7 vers 8, la fatigue s’est accumulée à l’idée de maintenir sur un blog personnel une Digital Experience Platform (DXP) de niveau entreprise
  • Le blog sert d’espace annexe pour des projets personnels et du contenu YouTube ; la décision de migrer vise à se concentrer sur l’écriture plutôt que sur la maintenance du CMS

Pourquoi Hugo

  • Il existait déjà une expérience de migration d’anciens sites de loisir vers un hébergement statique, certains ayant été convertis vers Jekyll ou Hugo
  • Jekyll convient bien à GitHub Pages, mais en tant que non-spécialiste de Ruby, la préférence va à la configuration simple et à la rapidité de Hugo
  • Hugo offre une prise en charge native de Markdown, ce qui s’intègre naturellement au mode de rédaction existant

Processus de migration et problèmes rencontrés

  • La migration est en cours dans l’issue GitHub #158
  • Avec plus de 3a0500 articles et vingt ans de données, il peut subsister quelques images cassées, erreurs de liens ou redirections manquantes
  • L’objectif est de conserver autant que possible la structure d’URL existante ou d’ajouter des redirections

Amélioration du workflow avec Markdown

  • Tous les articles sont rédigés en Markdown depuis 2020
    • Auparavant, les billets étaient écrits en Markdown dans Sublime Text, convertis en HTML, puis téléversés manuellement dans Drupal
  • Dans Drupal, la publication d’un article nécessitait une procédure en plusieurs étapes
    • Coller le corps du texte, téléverser et insérer les images individuellement, modifier la date de publication, vider le cache, etc.
    • Cela incluait même la gestion du cache Cloudflare pour faire face aux attaques DDoS, ce qui rendait le processus encore plus complexe
  • Avec Hugo, il suffit d’écrire un fichier Markdown puis d’exécuter hugo && git commit && git push pour publier immédiatement
  • La charge d’administration serveur liée à Composer, Drush, PHP, MariaDB, Nginx et autres disparaît, ce qui améliore l’efficacité de maintenance

Suite du plan (TODOs)

  • La fonction de commentaires doit être rétablie dans une deuxième phase via un système de commentaires statiques auto-hébergé
  • La recherche sur le site reposait autrefois sur Apache Solr, mais elle est actuellement désactivée
    • Une méthode d’implémentation de la recherche dans Hugo est à l’étude dans l’issue #168
  • Au début de la migration, les commentaires restent désactivés, et la reprise de l’existant devrait prendre du temps

Ce que signifie cette transition

  • Abandon d’une structure complexe de création et de gestion de contenu sous Drupal au profit d’un modèle d’exploitation de site statique plus simple et plus efficace
  • Un exemple concret montrant comment les développeurs individuels peuvent réduire la charge de maintenance et se concentrer sur la création
  • La migration vers Hugo est présentée comme un moyen d’améliorer la pérennité de l’exploitation d’un blog personnel

À lire aussi

1 commentaires

 
GN⁺ 2026-01-06
Commentaires sur Hacker News

  • Il y a quelques années, j’ai migré mon site personnel vers un générateur de site statique basé sur Common Lisp que j’ai développé moi-même
    Au départ, il faisait environ 850 lignes, et maintenant il est monté à environ 1 500 lignes ; il rend statiquement presque tout, y compris les billets de blog, le livre d’or, les pages de commentaires et les flux RSS par tag
    Comme j’écris moi-même tout le code, le HTML et le CSS à la main, je peux garder un contrôle esthétique total, et ajouter de nouvelles fonctionnalités rapidement
    Par exemple, il a suffi d’environ 40 lignes de code CL et de 15 minutes pour ajouter une page de « backlinks »
    Maintenant, c’est très stable, donc j’ai rarement besoin d’y toucher et je peux me concentrer uniquement sur l’écriture

    • Avec un tempérament comme le mien, un blog auto-hébergé était le problème
      Je passais tout mon temps à bricoler le moteur du blog, et au final je n’écrivais plus
      Je suis donc volontairement revenu à une solution d’hébergement avec moins de contrôle. Maintenant, je peux me concentrer uniquement sur l’écriture
    • J’aime aussi la liberté et la stabilité d’un générateur de site statique à usage unique
      Avant, je maintenais un projet public appelé Tclssg, et grâce aux retours des utilisateurs j’ai documenté le projet et ajouté beaucoup de fonctionnalités
      Mais comme c’était un projet public, il était difficile d’en changer librement la structure
      Maintenant, j’utilise un générateur composé de Python (900 lignes) + Pandoc Lua (700 lignes), dédié uniquement à mon site
      J’ai résumé l’évolution technique sur mon site
    • Je suis d’accord aussi. J’ai porté mon site taoofmac.com vers Hy, puis je l’ai réécrit en Python
      Maintenant, je le refais encore en TypeScript/Bun, et il reste toujours des éléments façon LISP
      Je cherche un dialecte LISP/Scheme léger, avec SQLite et parsing HTML intégrés, et compilable nativement
      J’ai rassemblé des infos à ce sujet ici
    • J’ai fait la même chose, en implémentant un générateur de site en Go
      Même après des années, je peux toujours builder le site complet en moins d’une seconde
      J’ai aussi ajouté moi-même les flux RSS et la coloration syntaxique, en utilisant Chroma et Blackfriday
      J’ai essayé Hugo, mais c’était trop complexe, donc je l’ai implémenté moi-même
    • Je me demande comment les commentaires sont gérés sur un blog statique

  • J’ai migré de svbtle vers Hugo il y a longtemps, et honnêtement je le regrette
    J’ai forké un thème, mais Hugo casse souvent et sa maintenance me prend beaucoup trop de temps
    Aujourd’hui, le site ne build même plus du tout
    Mon conseil : gardez aussi en contrôle de source la version binaire qui sert à builder le site

    • J’ai compris que certains logiciels n’ont pas besoin d’être mis à jour à tout prix
      Un générateur de site statique a très peu d’enjeux de sécurité, donc s’il ne vous manque aucune fonctionnalité, vous pouvez garder l’ancienne version telle quelle
      Tant que le système d’exploitation ou le CPU ne changent pas fortement, ça ne pose pas de problème
    • Il suffit de fixer la version dans la configuration CI
      J’ai fait pareil en m’inspirant de cette configuration
      Pour trouver une version qui fonctionne, une recherche dichotomique est efficace
    • Moi, j’ai réglé ça avec une image Docker personnalisée
      Comme j’utilise la même version de Hugo en local et en CI, il ne peut plus y avoir ce genre de problème
    • Quand on utilise un binaire off-the-shelf, on peut le mettre dans ${project}/bin/, l’ajouter à .gitignore, puis enregistrer son checksum dans un fichier SHA256SUMS
      C’est une sorte de version simplifiée de Git LFS
    • J’ai eu le même problème avec Jekyll
      Quand je passe sur un nouvel ordinateur, j’ai peur de réussir à réaligner les versions, et au final je suis en train de le porter en PHP, mais ce n’est pas encore terminé

  • Si on écrit ses articles en Markdown, passer à Hugo est un choix logique
    J’ai moi aussi migré plus de 500 posts Jekyll vers Hugo, et c’est la syntaxe des templates qui a été la plus pénible
    Mais globalement, ça valait le coup
    J’ai résumé le processus de migration et le script de conversion automatique dans un billet de blog

    • Je me demande pourquoi tu as migré de Jekyll vers Hugo. Je suis tout à fait satisfait de Jekyll

  • Les SSG sont bien pour les sites statiques, mais dès qu’il faut de l’interaction, il faut un serveur
    Puisqu’il faut de toute façon faire tourner un serveur, rendre le Markdown dynamiquement est plus simple
    Au final, les SSG ne font qu’ajouter des dépendances et des points de casse
    J’ai l’impression que Jeff regrettera plus tard s’il veut ajouter des fonctionnalités comme les commentaires
    Personnellement, je pense qu’un serveur simple basé sur le SSR est une solution plus réaliste

    • Mais s’il y a beaucoup de visiteurs ou de bots, le serveur peut aussi tomber
      Les pages statiques n’ont pas ce risque, et la majorité du trafic est en lecture seule
      Jeff semble aussi vouloir implémenter lui-même les commentaires dans une issue
    • Moi aussi, j’auto-héberge mes outils d’analyse et mon système de commentaires
      Le volume de code est bien plus faible et plus simple qu’à l’époque de Drupal
    • Les générateurs de site statique vont plutôt dans le sens d’une réduction des dépendances
    • Pour ma part, les pages statiques sont gérées par un SSG et les commentaires par un serveur Common Lisp + Hunchentoot
    • J’ai moi aussi converti mon site vers un SSG, et je ne le regrette pas du tout. Plus c’est simple, mieux c’est

  • Je suis curieux du processus de décision au moment de choisir un SSG
    Il existe beaucoup d’outils majeurs comme Hugo, Eleventy ou Jekyll, et Hugo en particulier casse souvent la compatibilité
    Pour un projet ancien, je pense qu’on devrait désormais garantir la stabilité

    • En effet, Hugo a entièrement remanié son système de templates dans la v0.146
      Résultat, le build de mon blog a cassé, et la documentation n’est toujours pas complètement mise à jour
      Le changement en lui-même est acceptable, mais le vrai problème est que la documentation ne suit pas

  • Je me demande ce que vaut Pelican aujourd’hui. Dans l’écosystème Python, on dirait que Hugo et Pelican sont les deux grands noms
    L’intégration ActivityPub peut aussi sembler plus séduisante que le RSS

    • J’utilise Pelican et j’en suis satisfait
      Avant, j’utilisais Nikola, mais il avait trop de dépendances et des problèmes d’incohérence des builds incrémentaux
      J’aime bien le fait que Pelican reste simple
    • Moi aussi, j’utilise Pelican depuis plusieurs années
      On a l’impression que la documentation est terminée à 90 %, donc il manque des détails, mais si on se contente des fonctions de base, c’est excellent
    • J’utilise Pelican avec plusieurs plugins maison
      Il y a des commits tous les mois, donc le projet est bien vivant
    • Si vous connaissez Python, Pelican est le choix le plus naturel

  • En ce moment, je suis en train de migrer de Hugo vers Zola
    La configuration et les templates de Zola me paraissent bien plus intuitifs

    • Moi aussi, je suis passé de Jekyll à Zola, et je ne le regrette absolument pas
      J’automatise le build et le déploiement avec GitHub Actions
    • Si vos besoins ne sont pas très poussés, la combinaison Zola + gist est simple et fonctionne bien

  • J’utilise Hugo depuis 3 ans
    Ce que j’ai appris, c’est qu’il faut forker le thème et le gérer soi-même
    Mieux vaut éviter les sous-modules et faire les mises à jour lentement
    Les commentaires restent un sujet compliqué

    • Exactement. Au final, les thèmes sont différents pour chaque site
      J’ai moi aussi essayé de porter un thème Drupal avant d’abandonner
      Je pense qu’il vaut mieux l’inclure directement et ne surcharger que les parties nécessaires, plutôt que d’utiliser des sous-modules

  • J’ai lancé mon blog sur Hugo l’an dernier, et sur 18 posts, les trois quarts m’ont causé des erreurs de build
    J’ai trouvé ça trop instable, donc très décevant

    • Moi aussi, je suis passé de Hugo à un SSG Python fait maison
      Plutôt que de m’habituer à la façon de faire de Hugo, il m’a été bien plus simple de l’implémenter rapidement dans un langage que je connais

  • J’ai déjà développé moi-même un petit SSG, mais récemment je cherchais quelque chose de plus structuré et j’ai essayé 11ty
    Mais les templates Liquid étaient vraiment pénibles
    Je voulais utiliser des templates basés sur JSX, mais 11ty rend ça difficile
    Le SSG de NextJS est riche en fonctionnalités, mais trop complexe et un peu excessif pour ce besoin
    J’envisage aussi de construire un SSG personnalisé sur un framework comme Tempest

    • Eleventy prend aussi en charge des langages de templates classiques comme Mustache
      J’ai moi aussi migré un site basé sur Punch vers Eleventy, et tant que la vitesse de build tient la route, je trouve ça meilleur que Hugo
      Depuis, je l’ai refait avec Astro
    • Nous avons migré le site marketing de notre startup de NextJS vers Astro, et nous en sommes très satisfaits
      C’est centré sur le statique, mais on peut quand même utiliser de la logique backend si nécessaire
      NextJS était trop complexe pour un site aussi simple