Journal Static Site Generator

Posté par  . Licence CC By‑SA.
Étiquettes :
18
28
juil.
2022

Bonjour'nal
Il y a quelques temps je me suis décidé a monter un blog perso pour raconter quelques idées que j'ai en tête. Je me suis donc mis en quête d'un outil qui me conviendrait.

Je ne voulais pas d'un mastodonte lié à une BDD, mes besoins étant modeste je voulais quelque chose de léger et hébergable facilement. Donc j'ai assez rapidement exclu les Wordpress, DotClear et autre supertanker du domaine.

J'ai jeté un œil aux «Flat file CMS», tel que Grav. Ils sont sympa avec une jolie interface mais requière PHP pour fonctionner. Pas insurmontable pour l'hébergement, mais je voulais quelque chose d'encore plus simple.

C'est aussi à ce moment que je me suis posé des questions sur la pérennité de ce que j'allais produire. C'est à dire sous quel format ma production allait être stocké. Mes besoin n'étant pas immense du Markdown me paraissait tout à fait suffisant, mais en grattant un peu j'ai découvert «ReStructuredText» qui semble plus poussé et un peu mieux normalisé. Cette deuxième possibilité entrait en ligne de compte sans être discriminatoire.

Enfin j'arrête mon choix sur un «Static Site Generator», tout se passe en fichier plat avec une phase de construction pour obtenir du pur HTML. Avantage non négligeable, pas de sécurité a prendre en compte, ce qui m'allait bien. En plus avec les «worker» Git[lab|hub] et leur possibilité de «pages», il est possible avec un commit sur un dépôt d'automatisé la génération et publication, TOP !

Passons aux choses sérieuses, quel produit prendre. Je vous passe les heures de recherche (merci Jamstack pour finalement opter pour «Pelican». Pourquoi ? Parce que je suis plus a l'aise avec du Python que du Go. Donc même si Hugo a le vent en poupe avec des performance largement supérieur, mes petits besoins n'ont pas besoin de grosse perfs.

Et me voilà partis a essayer de monter tout ça. Je passe un temps certains a me battre avec l'automatisation sous Gitlab (le modèle proposé faisait des choix «étrange», heureusement corrigé maintenant) et je regarde les thèmes proposés.
Première déception : ils sont datés, et pas qu'un peu pour certains, sans compter ceux qui ne sont même plus fonctionnel :-(
J'arrive tout de même a en trouver un a mon goût et le test, malheureusement il n'est qu'a moitié fait et remonte des erreurs. Je me dit que je vais pouvoir ajouter ma pierre a l'édifice en corrigeant ça et terminant le travail. La correction est finalement assez trivial et j'en profite pour faire quelques retouches. Je découvre aussi la source du thème et voie qu'il y a mieux. Donc je me dit que je pourrais repartir de zéro sur un thème encore plus joli !

Je monte donc un environnement pour faire tout ça, récupère tout ce qu'il faut et commence à m'atteler à la tâche. Je découvre un peu plus Jinja pour le templating, que je trouve assez bien fait et intuitif. En dédupliquant le code HTML, j'arrive rapidement a vouloir utiliser l'héritage de Jinja. Et là c'est la catastrophe :-( je n'arrive pas a comprendre pourquoi ça fonctionne avec certains block déjà présent et pas le nouveau que j'essaye de faire. Je retourne le soucis dans tous les sens pour finalement comprendre que le soucis ne viens pas de moi.

Deuxième déception : en lisant cette demande de changement et relisant attentivement la doc, sans la survoler et comprendre ce qu'il veulent vraiment dire) je comprend que Pelican souffre d'un soucis de chargement des ressources lors de la processus de Jinja. Donc soit on se base sur leur thème «simple» pour avoir un bout d'héritage, soit on duplique le code dans tous les coins :-(
Au vu de l'ancienneté du bug remonté (2013) il est peu probable que ça se débloque. Il y avait un petit espoirs avec cet autre bugmais fermé automatiquement par manque d'activité :-( il semble tout de même y avoir une voie de contournement mais pas super propre.

Bon dans tout ça je me dit que je devrais peut être changer d'outil, tel que MkDocs qui a l'air d'avoir une bonne popularité mais est plus orienté documentation technique …

Bref, qu'es-ce que tu utilise toi ?

  • # Mkdocs

    Posté par  (Mastodon) . Évalué à 6.

    Bref, qu'es-ce que tu utilise toi ?

    Rien mais j'utilises indirectement mkdocs pour les techdocs de Backstage et bien que voué à la documentation, je ne vois pas en quoi il ne pourrais pas faire l'affaire pour un petit site/blog.

  • # Sphinx

    Posté par  . Évalué à 8.

    J'utilisais pelican également et j'ai migré sur sphinx (à jour, plus de thèmes), tu peux voir le site ici (construction et déploiement sont automatisés).

    Une autre possibilité est de rester sur du reST (que j'apprécie également pour son "formalisme"), puis de le convertir vers le format de son choix avec pandoc. Ainsi, si tu veux un jour migrer de générateur, que celui ci n'accepte que du markdown/asciidoc ou autre, tu pourras facilement ajouter la conversion (à la volée) dans un script. Grâce à cela, ce que tu feras sera "future-proof", et ça… j'aime bien :).

  • # Make + m4 + sh + …

    Posté par  . Évalué à 7.

    Bref, qu'es-ce que tu utilise toi ?

    Un bidouillage perso dont je devrais probablement avoir honte.

    Essentiellement basé sur un Makefile, beaucoup de macros m4,¹ et des scripts divers.

    La plupart des pages sont écrites directement en HTML, avec les macros m4 pour insérer les boilerplates communs à toutes les pages et automatiser quelques trucs (genre une macro DOWNLOAD(file.tar.gz) qui se développe en

    <a href="file.tar.gz">file.tar.gz</a> (application/gzip, 170K, <a href="file.tar.gz.asc">signature</a>)

    ).

    Quelques pages sont générés à partir d’autres sources que du HTML m4-ifié :

    • des fichiers texte en Markdown ou en reStructuredText ;
    • des documents DocBook ;
    • des carnets Jupyter.

    La possibilité d’utiliser plusieurs formats sources indifféremment (HTML, Markdown, RST, DocBook, etc.) est une des principales raisons qui m’ont fait commettre ce bidouillage. Je n’ai pas re-vérifié depuis, mais à l’époque où j’ai commencé (il y a plus de dix ans) je n’avais pas trouvé de générateur de site statique qui permette ça, chacun ne supportait qu’un seul format source, sans mécanisme pour injecter des pages générées différemment.

    ¹ Le manuel de m4 contient l’avertissement suivant :

    Some people find m4 to be fairly addictive. They first use m4 for simple problems, then take bigger and bigger challenges, learning how to write complex sets of m4 macros along the way. Once really addicted, users pursue writing of sophisticated m4 applications even to solve simple problems, devoting more time debugging their m4 scripts than doing real work. Beware that m4 may be dangerous for the health of compulsive programmers.

    J’aurais probablement dû le prendre plus au sérieux. Hélas, c’est trop tard pour moi désormais. Je témoigne pour que d’autres programmeurs ne tombent pas dans le piège. Dites non à m4 !

    • [^] # Re: Make + m4 + sh + …

      Posté par  . Évalué à 4.

      je n’avais pas trouvé de générateur de site statique qui permette ça, chacun ne supportait qu’un seul format source, sans mécanisme pour injecter des pages générées différemment.

      Très bêtement j'utilise rst2html. J'ai singé une directive 'graph' avec un préprocesseur qui exécute dot. Ça m'insère une directive 'raw' avec du svg. En sortie j'ai mon graphe inline.

      Mort aux cons !

    • [^] # Re: Make + m4 + sh + …

      Posté par  . Évalué à 4.

      Pour ma part, je bricole un générateur à base de Makefile également, mais j'utilise Pandoc et quelques templates html pour construire le site avec des sources Markdown. :)

      C'est du WIP, mais les sources sont là pour ceux que ça intéresse : https://gitlab.com/guillaumeroche/blouk.

  • # HTMLy

    Posté par  (site web personnel, Mastodon) . Évalué à 8.

    https://www.htmly.com/

    C'est ce qui m'a semblé le plus facile à utiliser en migrant depuis un antique compte Overblog.
    C'est du PHP, mais ensuite tout est stocké en flat file à partir de Markdown. Ça intègre quand même un petit moteur de recherche simpliste pour le côté dynamique.

    J'ai testé pas mal d'alternatives avant d'opter pour celui-là, mais dans le fond ça reste un choix très subjectif.

  • # pelican

    Posté par  (site web personnel) . Évalué à 7.

    Je suis convaincu par le format RST et son expressivité, et je suis sur Pelican depuis… longtemps maintenant. J’utilise le theme Flex que j’ai customisé à ma sauce en surchargeant les éléments qui m’intéressaient. Tu peux donc y trouver un exemple pour voir comment modifier un thème par défaut pour l’enrichir de ton côté.

    L’idée pour ça est de construire le thème en y insérant des include qui correspondent à des sous-éléments que tu peux surcharger par ailleurs. Bien sûr, il est possible que le thème que tu utilises ais mis en place ces points de surcharge. (je suis pas allé voir sur le thème par défaut). La plupart des thèmes que j’ai vu correspondent à un thème que les gens ont pu construire peur eux, mais sans chercher à le rendre réutilisable par d’autres.

    L’avantage de pelican est que tu peux facilement cloner un blog existant pour le modifier à ta guise hors ligne :)

  • # Jekyll

    Posté par  . Évalué à 3.

    J'ai eu le même besoin il y a quelques temps déjà, je voulais le truc le plus bête et méchant possible, et je me suis arrêté sur Jekyll.

    J'ai vraiment pris le projet de base, foutu sur GitHub et j'écris mes pages en markdown.

    Il m'a fallu un peu creuser pour rajouter une pagination et une page de catégories, mais c'est tout : https://github.com/NoxInmortus/noxinmortus.github.io

    J'ai prévu de le migrer sur Gitlab, donc va falloir ressortir la pelle mais ça devrait pas être si laborieux.

    • [^] # Re: Jekyll

      Posté par  (site web personnel) . Évalué à 3.

      J'ai fait tourner mon blog peu actif sur jekyll pendant un moment et j'ai beaucoup souffert de l'écosystème et notamment "jekyll-assets" qui bloquait les mises à jours et avait des comportement bizarres qui m'ont fait perdre un temps fou…

      La migration sur hugo à été une délivrance

  • # Hugo

    Posté par  (site web personnel) . Évalué à 7.

    Dans le cadre d'un blog, je trouve qu'un générateur de site statique rempli bien son office. J'ai fait mes premiers essais de blog en utilisant Pelican, car comme toi je suis plus à l'aise en Python qu'en Go. C'était il y a quelques années.
    Aujourd'hui Pelican semble être de moins en moins utilisé. Tandis qu'Hugo continue d'être développé.
    J'ai testé Hugo récemment et j'en suis plutôt satisfait.
    Les fonctionnalités sont les mêmes que ce que propose Pelican. En tout cas dans mon approche simpliste d'un blog.
    Les thèmes sont assez variés et modernes. Suffisamment pour trouver quelque chose qui plaise. J'en ai testé quelques uns et je n'ai pas rencontré d'erreur à la génération des pages.
    Quant au Go avec lequel je ne suis pas familier, au final ce n'est pas un problème car je ne mets pas les mains dans la machinerie.

    • [^] # Re: Hugo

      Posté par  (site web personnel) . Évalué à 3.

      Oui je ne comprends pas pourquoi l'auteur du journal trouve pertinent de choisir un outil en fonction du langage qu'il maitrise ou affectionne.

      S'il est bien fait, tu n'as normalement pas besoin d'aller faire des modifs toi-même.

      On voit bien que dans son cas, le fait qu'il maitrise le langage n'a pas eu une fin plus heureuse… parce que le critère principal, c'est si le projet est encore maintenu ou pas.

      • [^] # Re: Hugo

        Posté par  (site web personnel) . Évalué à 4.

        Mais si tu dois faire des plugins, ça peut être important.

        J'ai du corriger le code ruby des collègues pour des plugins middleman, si j'avais eu plus d'expérience en ruby, ça aurait pu être moins relou (ou j'aurais crié plus, au choix).

      • [^] # Re: Hugo

        Posté par  (site web personnel) . Évalué à 5.

        Je comprends assez le principe. Je ne connais pas beaucoup d'outils où je ne finis pas par mettre les mains dans le cambouis, par conséquent lors du choix d'un outil, le langage utilisé a presque plus de poids que les fonctionnalités.

    • [^] # Re: Hugo

      Posté par  . Évalué à 5.

      Je trouvais étrange aussi de baser son choix sur le langage.
      Dans tous les cas, python/go c'est toujours vaguement bidouillable.
      Du coup je suis parti sur Hugo mais j'ai été rattrapé par l'âge des paquets go/Hugo sur debian.

      Au final, un déploiement qui aurait dû prendre 15 minutes, le temps d'un apt-get install, m'aura occupé mes soirées quelques jours.

      Je pense que je n'aurai pas eu le même problème avec python.

      Pour info, j'ai documenté les étapes de compilation de A à Z, c'est simple mais long (surtout pour mon vieux arm qui a plus de 10 ans) :

      http://stun.fdn.fr/tips/hugo-a-z/

  • # Hugo

    Posté par  (site web personnel) . Évalué à 5.

    Pour mon blog que je mets à jour 1 fois tout les 5 ans, j'ai opté pour Hugo. Mais j'ai eut beaucoup de mal à trouver un thème simple qui me plaise.

    • [^] # Re: Hugo

      Posté par  (site web personnel) . Évalué à 4.

      J'ai utilisé pendant un moment hugo, sympa. Je suis passé sur 11ty pour mon site perso. Y a des thèmes, et c'est en JS.

  • # Du html écrit à la main

    Posté par  (site web personnel) . Évalué à 10.

    Avec une CSS sans classe.

    Pour sauver la planète, les générations futures et mon temps libre, j'ai réduit mon empreinte digitale en passant de Drupal à un générateur de blog puis enfin un site "normal".

    Mes jeux tournent dans un brouteur au lieu de demander une installation et une JVM.

    Bref less is more.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Du html écrit à la main

      Posté par  . Évalué à 7.

      Pourquoi sans classe ? C'est quoi le problème des classes ?

      • [^] # Re: Du html écrit à la main

        Posté par  (site web personnel) . Évalué à 10.

        Ça a toujours entraîné des luttes ?

      • [^] # Re: Du html écrit à la main

        Posté par  (Mastodon) . Évalué à 10.

        C'est quoi le problème des classes ?

        Le problème des classes c'est que tu écris ton HTML pour un CSS précis puisque tu précises dans le HTML le nom des classes, et que chaque CSS a ses propres noms de classes.

        Le "sans classe" se contente de redéfinir les balises standard du HTML. Tu peux changer de CSS sans toucher un ligne de ton HTML (enfin si, le link du CSS :) ).

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Du html écrit à la main

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Des classes génériques à la µF peinent hélas à s'imposer

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Du html écrit à la main

            Posté par  (Mastodon) . Évalué à 5.

            Alors de ce que je comprends de ce microformat c'est plutôt pour créer des balises qui manquent. En effet on pourrait même imaginer qu'on puisse écrire <latitude>52.48</latitude>, au lieu de <span class="latitude">52.48</span>.

            Là je parle des CSS où tu dois écrire des trucs style <div class="d-flex flex-column flex-sm-row w-100 gap-2">, et au final tu écris dans la HTML les paramètres d'affichage.

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Du html écrit à la main

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Oui, je disais juste que s'il y avait des normes partagées et que tout le monde puisse mettre <span class="latitude">52.48</span> ce serait mieux que le fait que chacun ait sa sauce et qu'on se retrouve justement à dépendre d'une CSS spécifique (par exemple l'un qui te ferait mettre <span class="lat">52.48</span> et un autre qui te ferait mettre <span class="coord2">52.48</span> etc.) C'est vrai que c'est encore pire quand on met des classes et identifiants de structure (flex-column etc.)

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

              • [^] # Re: Du html écrit à la main

                Posté par  . Évalué à 4.

                Je ne comprends pas le principe. Une css et les classes sont faites pour modifier la présentation du contenu alors que les micro formats sont là pour formaliser du contenu. Ça n'a pas grand chose à voir.

                L'un sera très spécifique à un site qui choisi de présenter en vert ou rouge par exemple en fonction de divers critères, l'autre sert à l'échange et à la manipulation automatisée.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Du html écrit à la main

              Posté par  . Évalué à 4.

              Ça se ferait assez naturellement avec des extensions standards en XML mais c’est plus vraiment la mode.

    • [^] # Re: Du html écrit à la main

      Posté par  . Évalué à 3. Dernière modification le 01 août 2022 à 10:43.

      Je plussois à fond, le HTML devrait être enseigné à l'école avant le code. Ca fonctionne toujours très bien et la plupart des sites internets n'ont pas besoin d'une usine à gaz derrière.

      • [^] # Re: Du html écrit à la main

        Posté par  . Évalué à -1.

        Le HTML ça pue. C’est verbeux.

        C’est illisible pour un être humain normalement constitué.

        Ça prend de la place sur disque et durant le transfert (le résultat HTML compressé versus mes sources en Restrured non compressée…).

        Si les navigateurs web pouvaient se bouger le cul et réellement innover, plutôt que de chercher à gagner des pouillèmes de μs sur les requêtes réseau, ils feraient mieux d’implémenter des interpréteurs Rest et markdown en natif.

        On associe trop souvent le HTTP au HTML, alors qu’en fait, ça a juste rien à voir. Ce qu’on peut reprocher au web moderne est par ailleurs plus une conséquence du HTML que du HTTP.

        Mort aux cons !

  • # Mkdocs

    Posté par  . Évalué à 5.

    J'utilise Mkdocs pour faire une doc "glue" centralisée pour mon équipe au travail. J'y regroupe par activité une présentation générale de l'activité, les ressources-clés (documentaires, humaines, organisationnelles, informatiques…), les liens utiles vers ces diverses ressources au sein de l'entreprise et des commentaires sur leurs cas d'usages.

    L'idée est d'avoir un pense-bête en mode "source de vérité unique" (inspiré d'un journal récent sur gitlab), qui puisse aussi servir pour l'accueil de nouveaux arrivants.

    J'ai dû écrire un petit plugin privé pour pouvoir générer le site de manière à ce qu'il soit utilisable complètement hors ligne, l'option de base de mkdocks ne fonctionnant pas bien, et mon équipe ne disposant pas de solution d'hébergement web au travail. Au final ça marche très bien comme ça, j'ai aussi activé le plugin de recherche indexée hors ligne de mkdocs, avec l'index stocké dans un js, ce qui fait qu'on peut facilement trouver n'importe quelle info, même en hors ligne.

    Ce n'est pas vraiment ton cas d'usage cible, mais c'était l'occasion de faire un petit retour d'expérience sur cette utilisation possible de l'outil, qui est peut-être moins personalisable que d'autres, mais qui suffit pour ce qu'on en fait.

    Je compte aussi l'utiliser pour générer des petits tableaux de bord statiques mis à jour chaque matin et disponibles sur les espaces partagés réseau, avec des verbatims d'analyse simples générés automatiquement et une navigation intuitive entre les pages/onglets fournie par mkdocs. Ça évitera de contibuer à coller un peu plus de Power BI partout dans la boîte.

  • # templates et regexpes

    Posté par  (site web personnel) . Évalué à 5.

    Ce que j'ai fait c'est juste implémenter le générateur moi même avec un simple script qui remplace des expressions régulières dans les pages. Chaque entrée de blog est une page HTML et il y a des commentaires dedans pour les métadonnées que le script parse pour assembler le tout.

    Ma question par contre:
    Qu'utilisez vous pour les commentaires et les statistiques ?

    • [^] # Re: templates et regexpes

      Posté par  (Mastodon) . Évalué à 7. Dernière modification le 29 juillet 2022 à 14:29.

      Tu demandes aux gens de t'envoyer un patch ;-)

      De toute manière tout est tellement sujet au spam ou à de la haine en ligne qu'il vaut mieux avoir un système asynchrone ou seuls les commentaires utiles sont ajouté au billet par l'auteur.

    • [^] # Re: templates et regexpes

      Posté par  (site web personnel) . Évalué à 4.

      Qu'utilisez vous pour les commentaires et les statistiques ?

      Je suis antisocial, si j'ai des commentaires, je perds mon sang froid.

      Pour les stats, un truc qui regarde les logs apache (genre awstats).

      • [^] # Re: templates et regexpes

        Posté par  . Évalué à -8.

        jeu ne comprent que trop bihein le fais de perdre son sens froig (ce qui et une perte du con-troll des émoscionss, qui sont des donnais impor-tantes quoA).

        en temps queue non binair·x·e avec des conceptios fluides cheu trouf dificille de lire dé hautpinions tranché sur tous comme afec un couperai, est en prime du sarcasme èlitiste qui n'est pas inclusive, et des pinayeriz qui fon perdre bôcou baucou de tanT. Maleureuzemant c'est un conpportemmant très normative et connnoter masculinnne de tout commenté et de perdre du tant à parllé et chaté et crittiké, au lieu d'édè un autre person dant la direcssion qu'elle s'et choisY. On apaile ça du mansplaining en jargon, et sans doute ya oun grend diffèrance entre conprandre la daifiniscion d'un maux et intégrè réailemant en quoa il nouz conçairnE.

        have fun at -40 (par egzanplE). => vu sur linux.fr et vraimant tré tré tré tré ainclusivE ai ki va pas doux tout fér pairdr son sens frog à oun kidame.

        chais pa fu d'exkiouze sur ça maime aprais avoir relou 10 foâ.

  • # lektor

    Posté par  (site web personnel) . Évalué à 5.

    Parce que je parle que python et que j'ai réussi à écrire un petit plugin pour mes besoins. J'en ai pas testé d'autres… https://getlektor.com

  • # CMSimple_XH

    Posté par  . Évalué à 2.

    J'y vais aussi de ma contribution.
    Ce n'est pas du pur "HTML" puisque PHP mais ça utilise un fichier "plat" même pas en markdown.
    Le plus simple que j'ai pu mettre en place.
    https://www.cmsimple-xh.org/

  • # Zola / Gitea / Woodpecker

    Posté par  (site web personnel) . Évalué à 4.

    Bref, qu'es-ce que tu utilise toi ?

    J'utilise gitea + woodpecker + un plugin woodpecker maison qui détecte si le dépôt utilise zola ou hugo, qui compile le site et qui le copie vers le serveur via sftp en utilisant lftp (soit chez un hébergeur classique, soit chez moi).

    Le plugin woodpecker est un conteneur classique que je recompile via un job sur github qui mets à jour toute la stack chaque semaine (y compris la distro de base via un script qui incremente le Dockerfile).

    Ceci dit, j'ai découvert que le paquet Fedora tire golang depuis 15 jours (cf https://bugzilla.redhat.com/show_bug.cgi?id=2104346), donc le conteneur a multiplié sa taille par 3 (super content de remplir le /var grace à ça), peut être que je vais basculer sur "utiliser le binaire upstream", ce qui va m'éviter les discussions sur "avoir une dépendance faible ou avoir un sous paquet".

    Du coup, le temps entre "git push" et "le site est en prod" est de 10 secondes par environment (si je me plante pas), et je peux aussi mettre un job de CI pour vérifier les PR.

    J'ai plus utilisé zola que hugo, et j'ai eu une regression à la con que j'ai vu dans l'aprés midi, moitié parce que j'ai fait n'importe quoi avec les sections, moitié parce qu'un nom de variable a changé et que les changelogs sont pas terribles (et que j'ai pas trouvé le commit).

    Mais sinon, j'en suit pleinement satisfait, c'est rapide, ça fait juste le taf et y a juste ce qu'il faut d'extensibilité.

    À coté de ça, j'ai aussi des experiences avec jekyll et middleman pour le boulot, et c'est un peu l'horreur.

    La version de ruby est jamais la même partout sur les portables des admins et des devs webs, on doit réinstaller l'env à chaque build donc ça prends 5 à 10 minutes (vu que tu tires assez vite nokogiri qui patch libxml2 ou ce genre de choses, donc faut aussi avoir gcc, etc).

    Middleman est passé en version 4, et tout a sauté. Jekyll semble non maintenu.

    Ensuite, c'est sur que c'est plus souple et tu peux mettre des plugins complexes. Ensuite, faut les maintenir, et ça tombe sur moi, donc je préfère m'éviter ça avec zola/hugo.

  • # Pelican aussi

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    J'utilise Pelican aussi pour mon blog, mais j'ai par contre forké le thème que j'utilise (Brutalist, mon fork) pour y intégrer certains correctifs.

    Hormis ça, mes principales difficultées avec Pelican se sont faites lors de l'import de mon blog vers Pelican. Ce fut long et pénible, probablement car j'avais fait pas mal de manipulations diverses dans mon CMS précédent, Dotclear.

  • # Metalsmith

    Posté par  (site web personnel) . Évalué à 1.

    Après avoir écrit un outil personnel basé sur SGML il y a des lustres (http://dsoulayrol.free.fr/achille/), puis utilisé différents outils toujours en Python (Hide, Wok), j'ai découvert Metalsmith (https://metalsmith.io/) qui est en Javascript.

    Je gère ainsi une poignée de sites, tels que celui de https://ti-nuage.fr : les pages sont générées ou transformées depuis du Markdown, du HTML, voire avec Groff. J'utilise Nunjucks pour la mise en forme.

    Avantages : le logiciel est minimaliste et ne définit que la notion de sources et de chaîne de plugins. Chaque plugin fait ce qu'il veut sur les sources adéquates. Il existe une bonne collection de plugins, il est assez facile d'en écrire un.

    Inconvénients : Comme tout projet basé sur npm, ça peut facilement télécharger la moitié d'Internet pour fonctionner. À chacun de trouver l'équilibre entre l'utilité de tel plugin et le poids qu'il implique.

  • # 11ty

    Posté par  . Évalué à 2.

    Si tu recherches vraiment du jamstack pur et ultraléger 11ty est certainement la solution en vogue qu'il te faut.

    Juste une arborescence de fichiers avec des conventions simples, du markdown ou un autre langage de markup pour le en contenu, une CSS et des templates avec tous les langages de la planète JS supportés et un générateur qui parse tout ça en JS et qui te génère un site statique.

  • # [En cours de test] ikiwiki

    Posté par  . Évalué à 4.

    Bien que je fais des essais sur ikiwiki en ce moment pour s'en servir comme wiki utilisant du markdown avec les fonctionnalités avancées de pandoc (avec un plugin non-officiel) pour la génération de PDF, il est aussi pensé pour faire des sites statiques avec le versionnement des fichiers sources sur git.

    Ce que je peux dire en l'état actuel de la doc:
    - L'installation par paquet est supportée par défaut pour les distributions debian et ubuntu.
    - Il serait possible d'utiliser directement la syntaxe ReStructuredText par plugin avec quelques limitations.
    - Dans le cas où on veut coder son propre plugin avec autre chose que du Perl (le langage natif de ikiwiki), il faut passer par une API en XML RPC
    - Les options pour mettre des fichiers CSS moins austères et faire des modèles de page sont également disponibles.

  • # Hugo + Cloudflare Pages

    Posté par  (site web personnel) . Évalué à 2.

    Après avoir passé un moment à batailler avec jekyll + rouge + jekyll-assets et ne plus supporter les messages d'erreurs bizarres, les conflits et bloquages de versions de modules ruby et autres joyeusetées je suis passé sur Hugo

    J'en ai profité pour refaire le theme graphique à l'identique (ou presque) visuellement mais sans tout les "helpers" JS/CSS présent initialement et en basant la structure html au plus proche des best-practices html5 (ou du moins de ce que j'ai compris du html5 ) ie usage des tag articles, aside, nav, …

    Je n'ai plus sous la main les chiffres exacts mais la page nécessite 40Ko la ou la base utilisé pour le theme jekyll tapait plutôt dans les 800Ko.

    L'un des trucs les plus surprenant à été le bouton twitter d'ailleurs, qui rajoute discrètement 120/140Ko quand instancié via le js normal (pour au final 5/6 lignes de CSS ….)

    Le projet git est connecté à cloudflare pages pour rendre l'update aussi efficace que possible.

    https://github.com/bplessis/blog/
    https://blog.plessis.info/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.