Seb's blog
logo PassionGNU/Linux

Content de mon changement pour Pelican!

J’ai mis du temps avant de réussir à bien prendre en main Pelican, à avoir ce que je voulais avec lui, à comprendre pourquoi certaines choses n’allaient pas, mais aujourd’hui je suis bien content d’avoir fait le saut. Content déjà d’avoir été “poussé” par Devil505 sur du site statique, content de m’y être accroché alors que ça me faisait quitter mon confort et mes habitudes. Au delà de ça, je suis surtout content d’avoir continué à chercher ce qui n’allait pas avec Pelican car c’est bien lui qui me va le mieux et ce depuis le début de cette aventure.

J’ai testé pas mal de GSS (Générateurs de Sites Statiques), mais je me suis arrêté à trois GSS que sont Hugo (en GO), Jekyll (en Ruby) et Pelican (en Python). C’est une manière de faire un site en peu de temps, avec peu de ressources tout en étant bien plus rapide qu’un site dynamique. J’ai très vite annoncé que Pelican était celui qui me correspondait le mieux, malheureusement et ce malgré une superbe documentation, je n’arrivais pas à faire ce que je voulais contrairement à Jekyll et Hugo. Mais c’est pas plus mal, Jekyll m’ayant donné l’habitude de faire une nomination correcte et propre de mes fichiers, Hugo quand à lui me donnant plus d’assurance pour comprendre l’ensemble.

J’ai exactement ce que je veux depuis le passage à Pelican, oui je fais le contraire de beaucoup, je passe de Hugo à Jekyll pour revenir 2 ans plus tard à Hugo et puis au bout d’à peine 4 mois je rechange pour Pelican. Normalement on fait le contraire, les gars vont de Jekyll/Pelican vers Hugo pour sa simplicité et surtout sa rapidité, oui c’est vrai de ce point de vue j’ai perdu en route, Hugo est bien plus rapide, mettant 0,50s pour 500 billets. Je dois dire que je perds avec Pelican mais ça reste encore inférieur (de peu) à Jekyll, mais c’est pas important, le truc c’est que Jekyll ou Pelican mettaient 13/15 secondes pour “fabriquer” mon blog avec les 500 billets, là où Hugo en a mit 800ms (0.80) dans les jours les moins rapides sur l’ancienne machine, mais avec le changement de PC, ça change la donne. Bien sur que Hugo reste bien en dessous mais c’est moins marquant, car Jekyll sur cette machine met 6 secondes tandis que Pelican en met 1 ou 2 secondes. J’admets volontiers que le changement de Jekyll pour Hugo n’avait en rien à voir avec la vitesse de fabrication du site, non c’était dû surtout à la personnalisation par des thèmes et des plugins de Jekyll que j’ai jamais trouvé simple à faire. J’ai souvent testé et à chaque fois un soucis avec la version dans Debian, trop vieille, etc… C’était aussi dû au fait que je n’arrivais pas facilement à avoir ce que je voulais sans complication, je voulais de la pagination et bien ça ne marchait pas malgré l’ajout d’un plugin, je voulais mettre mes billets dans des dossiers qui serviraient de catégories et rien non plus… Mais la chose qui m’a poussé à changer, ce sont les messages d’erreurs de Jekyll, on n’y comprenait pas d’où ça venait.

Un exemple de mon actuelle site:

    jekyll build
    Configuration file: /home/sebastien/Systeme/sauvegarde-site/jekyll/_config.yml
            Source: /home/sebastien/Systeme/sauvegarde-site/jekyll
    Destination: /home/sebastien/Systeme/sauvegarde-site/jekyll/_site
    Incremental build: disabled. Enable with --incremental
    Generating... 
    Liquid Warning: Liquid syntax error (line 26): Expected end_of_string but found id in "{{texte en gras}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-09-pourquoi-dotclear-et-pas-spip-pluxml-ou-wordpress.md                                                                                  
    Liquid Warning: Liquid syntax error (line 38): Unexpected character { in "{{{intertitres}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-09-pourquoi-dotclear-et-pas-spip-pluxml-ou-wordpress.md                                                                                                
    Liquid Warning: Liquid syntax error (line 91): Expected end_of_string but found colon in "{{tpl:BlogCopyrightNotice}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-14-20160614creer-un-blog-avec-dotclear-6-configuration-avancee.md                                                           
    Liquid Warning: Liquid syntax error (line 99): Expected end_of_string but found id in "{{en gras}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-25-20160625spip-un-cms-pas-comme-les-autres-pourquoi-spip-et-pas-un-autre-partie-6-les-raccourcis-typographiques.md                            
    Liquid Warning: Liquid syntax error (line 105): Unexpected character { in "{{{Un titre de partie}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-25-20160625spip-un-cms-pas-comme-les-autres-pourquoi-spip-et-pas-un-autre-partie-6-les-raccourcis-typographiques.md                            
    Liquid Warning: Liquid syntax error (line 333): Unexpected character é in "{{Prénom}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-25-20160625spip-un-cms-pas-comme-les-autres-pourquoi-spip-et-pas-un-autre-partie-6-les-raccourcis-typographiques.md                                         
    Liquid Warning: Liquid syntax error (line 353): Expected end_of_string but found id in "{{date de naissance}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-25-20160625spip-un-cms-pas-comme-les-autres-pourquoi-spip-et-pas-un-autre-partie-6-les-raccourcis-typographiques.md
    Liquid Warning: Liquid syntax error (line 381): Expected end_of_string but found number in "{{Colonne 1}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-25-20160625spip-un-cms-pas-comme-les-autres-pourquoi-spip-et-pas-un-autre-partie-6-les-raccourcis-typographiques.md
    Liquid Warning: Liquid syntax error (line 381): Expected end_of_string but found number in "{{Colonne 2}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-25-20160625spip-un-cms-pas-comme-les-autres-pourquoi-spip-et-pas-un-autre-partie-6-les-raccourcis-typographiques.md
    Liquid Warning: Liquid syntax error (line 382): Expected end_of_string but found number in "{{Colonne 3}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2016-06-25-20160625spip-un-cms-pas-comme-les-autres-pourquoi-spip-et-pas-un-autre-partie-6-les-raccourcis-typographiques.md
    Liquid Warning: Liquid syntax error (line 7): Unexpected character % in "{{% youtube Tw3yT-qAbvc %}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2018-08-12-archive-une-journée-de-merde3.md
    Liquid Warning: Liquid syntax error (line 10): Unexpected character % in "{{% youtube UpjAIcXti9s %}}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2018-01-01-editeurs-markdown.md
    Liquid Warning: Liquid syntax error (line 31): Expected end_of_string but found string in "{{ replace .TranslationBaseName "-" " " | title }}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2018-01-01-je-              tenterais-bien-limportation-depuis-wordpress.md
        Liquid Warning: Liquid syntax error (line 32): [:dot, "."] is not a valid expression in "{{ .date }}" in /home/sebastien/Systeme/sauvegarde-site/jekyll/_posts/2018-01-01-je-tenterais-bien-limportation-depuis-wordpress.md
                    done in 3.531 seconds.
    Auto-regeneration: disabled. Use --watch to enable.

Des erreurs qui sont arrivées que depuis le passage à la nouvelle version de Buster. Bien sur que pour ceux-ci, je comprends d’où ça vient mais pourquoi on est passé d’un ancien Jekyll disant qu’il n’y avait rien de mal codé à un Jekyll qui râle pour rien? Et puis c’est du Ruby, si il y a un langage qui m’intéresse, j’avoue que ce n’est pas Ruby.

Hugo est pas mal non plus dans le flou de ses sorties de terminal, je crois même qu’il gagne haut la main, souvent j’ai cherché dans un billet ce qui n’allait pas, c’est con mais juste dire ce qui merde et à quelle ligne, c’est si dure de faire? Puis aussi le langage, c’est GO, c’est du Google, on sait comment Google réagit quand il n’a plus besoin de ce qu’il code, il le balance…

Pelican est tout le contraire, il est bavard et ne se laisse pas prier pour dire où ça merde exactement. Mais ça va au-delà, avec lui j’ai:

Vraiment, je suis content, je dis que j’ai une grosse possibilité de configuration et d’avoir ce que je veux juste en modifiant mon fichier de conf, ça parait absurde mais sous Pelican j’ai tout changé comme la façon que les fichiers s’enregistrent dans le site public, les URL, les flux RSS et ATOM, ajout de catégories et de tags,… Je suis, pour donner un exemple, passer d’un Pelican qui avait les billets de blog à la racine du site (ce qui fait un peu bordélique), à un site qui à ses billets de blog dans des sous-dossiers, j’ai même pendant un temps eu la même organisation que sous Jekyll /post/année/mois/jour/nom-du-post.

Un autre exemple est l’URL de mes billets, avant j’avais un truc finissant par*.html* et maintenant je ne l’ai plus, j’ai viré car je trouve ça sale…

C’est du markdown dans mes fichiers sources de mes billets, donc aucunes pertes puisque seules les entêtes des fichiers seront à modifier. Je ne changerais pour rien au monde, j’ai enfin trouvé ma façon de faire depuis deux ans, j’ai eu du mal aux débuts mais après une part de rodage, c’est bon. Markdown c’est un langage de balisage léger, qui n’a pour but que d’offrir une syntaxe facile à lire et à écrire. Un document balisé par Markdown peut être lu en l’état sans donner l’impression d’avoir été balisé ou formaté par du codage d’informaticien. Et puis j’aime cette simplicité, j’édite mon billet depuis un simple éditeur, vraiment c’est basique, c’est pas le programme qui requiert le plus de ressources pour se lancer, à la limite je mate un aperçu en live depuis mon navigateur avec pelican -lr (ce qui me lance un mini serveur http local de mon site), je compile mon site pour prendre en charge les changement avec un pelican, puis je le balance via SSH et RSYNC, c’est tout, simple, non?

Je trouve Hugo assez compliqué dans sa personnalisation, ça part dans tous les sens et la documentation n’est pas des plus grosses. Je cherchais pour faire des catégories via des sous-dossiers, je n’ai rien vu… Je regardais pour changer les URL de mon site, pour reprendre un peu ceux de Jekyll, je n’ai pas vu sauf des trucs parlant d’alias.

Je vois aussi quelques uns des utilisateurs de Jekyll/Pelican qui sont passés à Hugo faire marche arrière, comme quoi la vitesse ne fait pas tout.

Dernièrement, j’ai testé tout un tas de CMS classiques, alors soit je n’ai plus la patience, soit ma connexion est vraiment de la merde --possible vu que je suis avec une box 4G–, soit celle de mes parents qui sont pourtant fibrés est de la merde…, en tout cas aucun des CMS sauf le minimaliste PluXml, ne furent vivaces ni dans l’interface administrateur ni sur la partie public. Par exemple le CMS Grav m’a mit plusieurs secondes juste pour enregistrer un billet, sans parler de la lenteur ressentie du site.

J’aurai beaucoup de mal à repasser à un site dynamique, principalement pour deux raisons:

Sans parler de l’administration du site via son interface administrateur de son CMS, la navigation sur le site est bien plus lente, en cause un va-et-vient entre le code du site, le PHP, les bouts de codes et celui de la base de données. Pour un site dynamique propulsé par un CMS comme Wordpress:

Pour un site statique:

En effet, puisque toutes les pages sont pré-générées (déjà en html), le serveur n’a rien d’autre à faire que de les servir telles quelles. Aucun travail de traitement n’est effectué, pas d’interprétation de sa part, le serveur ne se pose pas de question et renvoie la page html, c’est rapide. Et ça peut être encore plus rapide grâce à la mise en place de cache très efficace car les ressources ne changent pas ou peu.

C’est pour ça que même en essayant des CMS de sites dynamiques, je n’ai rien trouvé approchant la vitesse d’affichage d’un site statique. Même les CMS Flat-Files sont loin de faire le taf aussi bien. J’ai essayé Grav, un CMS récent en flat-file, mais c’est bien moins vivace. Seul à la limite PluXml peut se vanter de faire presque aussi bien en terme de vitesse.

L’autre point primordial est la sécurité, c’est même le point le plus important pour moi. Si on prend un truc comme Wordpress, même si on a rien à écrire pendant plusieurs mois, on est obligé d’aller sur le site pour faire des mises-à-jour, car un site dynamique à tout un tas de failles, que ce soit sur le codePHP, les scripts, ou encore la base de données elle-même qui peut être corrompue…

Même sans parler de dangers imminents, Faut aussi voir la pérennité du projet, vu la complexité de passer d’un moteur à un autre (Wordpress vers PluXml par exemple), il faut bien choisir dès le début. Par exemple Wordpress on peut fermer les yeux mais Dotclear (excellent CMS) qui ne compte que sur un seul développeur, on peut légitimement se demander comment ça se passera le jour ou la personne arrêtera…

Du coté des GSS et je vais parler de Hugo pour ce coup, ce GSS est l’un des projets les plus actifs dans le milieu des moteurs de sites statiques, mensuellement on a une nouvelle version, mais rien n’oblige de changer de version aussitôt. En effet, les versions sont juste là pour améliorer les choses, ajouter des fonctions, pas pour résoudre des soucis d’ordre sécuritaires. Donc pour revenir sur celui que j’utilise aujourd’hui, Pelican n’est pas forcément des plus actifs, il se peut que pendant des mois (voir des années) il n’y ait pas de nouvelles versions. C’est pas pour autant que le code est mort, que le projet est mort, qu’il faut jeter le site, le moteur et tout ce qui est en découle, puisqu’au niveau sécuritaire on s’en fout. Et puis pour ceux qui tombent sur un bug alors que leur moteur parait bien mort en amont comme Hyde par exemple qui n’a pas eu de nouvelle version depuis 4 ans ni même d’activités depuis 2016…, il sera juste question de changer pour un autre. Rien de complexe, les fichiers étant juste du markdown, c’est relativement facile sans faire d’actions particulières.

Pour revenir dans mon optique, j’ai un peu de mal à passer deux secondes voir plus, à attendre que le site se pointe pendant que mon navigateur mouline, me donnant cette impression de lenteur. Pourtant il y a ce truc qu’on appel le cache, mais ça reste lourd. J’ai déjà attendu 12 secondes pour faire afficher une page d’un de mes contemporains linuxiens dont le site est sous Wordpress… Alors l’autre chose qui me chagrine, c’est les pages qui font un poids démesuré, je parle de page dépassant allégrement les 1 mo… C’est rien et beaucoup de sites ont au jour d’aujourd’hui de telles pages, ceci étant dû entre autre qu’on a juste après l’arrivée des forfaits internet illimités et pendant longtemps dit qu’un site devait en mettre plein les yeux. De nos jours, ouvrir sont navigateur sur une simple page demande des centaines de MO de RAM, ce qui fait le jeu des vendeurs de PC. Quand j’ai commencé sur internet, mon PC avait à peine 256 MO, internet à cette époque n’était pas celui qu’on connaît maintenant et pourtant il n’était pas moins intéressant.

Commencer la discussion: Venez écrire un commentaire dans le forum.