GuiGui's Show

En 2015, plusieurs personnes ont fait du lobbying ( :D ) pour que je migre mon blog, un WordPress, vers un générateur de sites web statiques. Je m'étais mis ça de côté dans ma TODO. Je viens de prendre le temps de m'intéresser à la question.

Pourquoi migrer ?

• WordPress est un CMS complet, avec des tonnes de fonctionnalités dont je ne me sers pas. C'est relou de mettre à jour un truc dont je ne me sers pas pour avoir des nouvelles fonctionnalités dont je ne me servirai pas. Dans le mois qui suit la sortie d'une nouvelle version, il y a une faille de sécurité qui touche toutes les anciennes versions… Pleaaaase. Notons que depuis 2015, j'ai stocké l'enchaînement de commandes que j'utilise pour mettre à jour dans un fichier texte et je pourrais envisager de créer un script sans trop de problèmes. Quoi qu'il en soit, le temps nécessaire pour mettre à jour mon WordPress a diminué ces derniers temps.
  
  
• En 2015, je trouvais l'idée séduisante car les commentaires de mon blog étaient alors envahis par le spam. Genre mon anti-spam (Spam Karma) laissait quasiment tout passer et je devais nettoyer les commentaires très régulièrement pour ne pas avoir de merde publiée sur mon blog et ne pas voir la taille de ma sauvegarde de la base de données grossir démesurément. En avril 2016, je me rendais compte que cette inefficacité était dû au passage à PHP 5.6.X dans Debian Jessie qui met l'extension MySQL au placard au profit de PDO, ce qui fait que la fonction mysql_real_escape_string(), utilisée par mon antispam, n'est plus disponible. Voir http://shaarli.guiguishow.info/?1_-YHw

Contrainte

La seule contrainte que je me suis fixée est la suivante : toutes les URL existantes doivent fonctionner après la migration. Toutes. Simplement parce que les URL cools / sympas ne changent jamais. Pérennité de l'information et du moyen d'y accéder, tout ça.

Évidemment, je souhaiterai aussi que les liens de mes tables des matières, qui pointent sur les sous-titres de mes billets, continuent aussi à fonctionner. Si ce n'est pas le cas, c'est ennuyeux mais ce n'est pas dramatique : l'utilisateur-rice atterrira quand même sur la bonne page web, juste il-elle ne sera pas propulsé-e au bon endroit dans le contenu de la page, c'est moins grave.

Continuer à publier sur mon blog ?

Cette question est importante. Si je décide que je ne veux plus publier sur mon blog, alors c'est simple : je dégaine wget ou httrack et je crée une copie statique de mon blog et c'est cette copie que je publie. Pas besoin d'un nouveau moteur de blog, même statique. Si je veux pouvoir ajouter des articles sur mon blog, alors oui, une migration vers un autre outil semble plus appropriée.

Je souhaite publier occasionnellement des articles sur mon blog. Le format shaarli + markdown n'est pas forcément le plus adapté. L'audience n'est pas non plus la même.

Quel générateur de site statique utiliser ?

Des générateurs de sites statiques, il en existe plusieurs centaines.

Mes critères de choix (liste ordonnée) : logiciel libre, pas écrit dans un langage de kikoo / inadapté (JavaScript / Node.js, Java, Go, Erlang, C/C++, Haskell, etc.), importation possible depuis WordPress, une bonne documentation et une communauté d'utilisateur-rice-s.

Avec ces critères, les logiciels suivants émergent du lot : Jekyll (Ruby), Octopress (basé sur Jekyll) et Pelican (Python). Je note aussi Lektor qui propose une interface d'admin en Node.js pour créer / modifier / supprimer les pages. Je connaissais aussi ikiwiki, codé en Perl, plus adapté pour les wikis, comme son nom l'indique.

J'ai choisi Pelican. Parce que je sais coder en Python et que je connais (un peu) Jinja2 (moteur de template) depuis que j'utilise ansible. Au cas où j'aurais besoin de mettre les mains dans le cambouis. Et un peu aussi parce que 2 des 3 lobbyistes qui m'ont invité à migrer mon blog utilisent Pelican (oui, effet de prescription, oui, je suis un mouton).

Pourquoi ne pas migrer ?

Avant de migrer, j'ai voulu me faire une liste de tout ce qui pourrait foirer. J'imagine que ça pourra servir à d'autres donc voici une petite liste non-exhaustive des problèmes potentiels que j'ai identifiés (liste ordonnée, du moins relou / problématique au plus problématique) :

• Est-ce qu'une migration vers Pelican me permet de virer des softs ? Non, j'ai toujours besoin de PHP pour shaarli et j'ai toujours besoin de MySQL pour Tiny Tiny RSS. J'ai testé beaucoup d'agrégateurs RSS (voir http://www.guiguishow.info/2011/08/07/agregateur-rss/ et http://www.guiguishow.info/2013/03/18/passer-de-newsfox-a-kriss-feed/ ) avant d'en trouver un qui fait le job que j'attends de lui donc il est exclu que j'en change. Shaarli me convient très bien donc il ne dégagera pas. Bon, virer WordPress permet déjà d'avoir moins de code sur le serveur donc ça restreint fortement la surface d'attaque.
  
  
• Est-ce que ça me débarrasse de WordPress ? Hé bah non, car j'administre d'autres WordPress. Genre association, tout ça. Bon, OK, ça ne sera bientôt plus le cas mais still…
  
  
• Pelican prend en charge trois formats pour rédiger le contenu : asciiDoc, reStructuredText et markdown. Je suis habitué à utiliser markdown pour créer mes slides Beamer et pour mettre en forme mes shaarlis. Donc ça va, il n'y a pas une barrière supplémentaire à l'entrée.
  
  

• Ma plus grande crainte était d'avoir des URL différentes. Mais en fait, non. Genre, pour avoir le même format « /année/mois/jour/titre/ » que mon WordPress, ça se dit comme cela dans pelicanconf.py ( voir http://docs.getpelican.com/en/3.6.3/settings.html ) :

  ARTICLE_URL = '{date:%Y}/{date:%m}/{date:%d}/{slug}/'
  ARTICLE_SAVE_AS = '{date:%Y}/{date:%m}/{date:%d}/{slug}/index.html'

Même chose pour les pages, les archives, les catégories, etc.

• L'absence de PHP signifie l'absence de commentaires. Pourtant, des personnes ont écrit d'excellents commentaires sur mon blog. Je trouve que supprimer (ne pas importer) les commentaires, c'est un manque d'éthique ou de politesse ou de je ne sais quoi : ces personnes ont fait l'effort d'écrire et m'ont appris des trucs. Bien sûr, dans les articles correspondant, j'ai mentionné les commentaires intéressants mais je n'ai pas forcément intégré lesdits commentaires au billet. Des infos intéressantes seraient donc perdues dans la migration. Je trouve ça dommage. Évidement, il est hors de question que j'utilise un service externe genre Disqus. Visiblement, il existe des solutions. Soit en utilisant une base sqlite (lol, site statique, tout çà) comme isso et d'autres. Soit avec du mail dedans ( https://github.com/getpelican/pelican-plugins/tree/master/pelican_comment_system ). Ce deuxième système a la classe. \o/ Pour importer les commentaires WordPress dedans : https://gist.github.com/tiramiseb/048db9c21c3fac8a44fd76cddaa17834 .
  
  
• Il faut que je retrouve un thème sombre, extensible et qui utilise un maximum la place qu'on a sur nos écrans (pas centré sur 400 pixels comme mon blog actuel, car c'est ridicule). Et rien que ça, ça va être une plaie. Et comme l'existant ne me conviendra pas, il faudra forcément que je le modifie. J'ai autre chose à faire, sérieux. :-
  
  
• Mon blog et mon shaarli sont entremêlés : des contenus pointés par mon shaarli sont stockés dans mon /wp-content/uploads. Oui, on évite de lier deux machines ou deux logiciels entre eux, règle de base. De la même manière, du contenu hébergé dans /wp-content/uploads n'a pas vraiment de lien, ni avec mon blog, ni sur ce shaarli. Exemple : les vidéos des journées FédéRez 2013. Là encore, cette organisation est stupide : j'aurai dû créer un autre virtualhost avec un autre domaine (genre datalove.guiguishow). Rien d'irréparable, juste il faut faire le ménage et écrire les redirections qui vont bien sachant que, puisqu'on est entre virtualhosts, il faut gérer http/https et ne pas rediriger bêtement tout en http ou tout en https.
  
  
• L'absence de PHP signifie l'absence d'un champ de recherche. Or, c'est clairement la fonctionnalité que j'utilise le plus pour retrouver ce que j'ai écrit, pour retrouver des commandes, etc. Hors de question d'être dépendant d'un service externe et encore moins de Google. Visiblement, il existe un plugin avec du JSON et du jQuery dedans pour faie le job : http://moparx.com/2014/04/adding-search-capabilities-within-your-pelican-powered-site-using-tipue-search/ . Remplacer PHP par une bouse bien lourde en JavaScript, j'aime le concept… Ou pas. Utiliser YaCy ?
  
  

• L'import depuis WordPress ne sera pas parfait, il suffit de lire des témoignages pour le vérifier : http://jonathan.michalon.eu/passage-a-pelican.html ou http://blog.jasonantman.com/2014/02/converting-wordpress-posts-to-pelican-markdown/ . J'ai testé et j'ai constaté les problèmes suivants :

  • Le nom d'auteur importé est le login dans WordPress, pas le nom de plume (oui, WordPress peut séparer les deux). Un coup de sed peut être nécessaire ;
    
    
  • Certains caractères comme « < », « > » sont échappés dans le markdown, lors de l'import. Il n'y a rien dans l'export XML WordPress, c'est vraiment Pandoc qui ajoute l'échappement durant l'import. Il faut les identifier et les sed ;
    
    
  • Sur mon WordPress, la table des matières de chaque article est créee dynamiquement par une extension (Table of Contents Generator codée par Scott Yang). Donc forcément, les tables des matières ne sont pas exportées par WordPress. Il faut donc les refaire à la mimine ou prévoir de se coder un script. ÉDIT DU 25/09/2016 À 21H05 : ou utiliser https://github.com/getpelican/pelican-plugins/tree/master/extract_toc FIN DE L'ÉDIT ;
    
    
  • Il faut importer soi-même les images car l'importateur se contente de faire un lien vers l'existant. De même, les légendes sont importées avec leur style CSS qui, du coup, fait partie de la nouvelle légence (genre « [caption id="attachment_36' class="aligncenter" width="300" caption="ma légende"] ». Pour corriger les légendes, il faudra forcément utiliser des regex look-behind. Pour l'import des images, c'est tout à la mimine. Dans mon cas, on parle d'environ 300 images, hein ;
    
    
  • Tous les liens sur des images (afin de les voir en grand) sont en http uniquement et sont des liens absolus… C'est comme cela que WordPress les stocke. Sur mon blog, j'ai un plugin pour réécrire les liens en https quand l'utilisateur se ramène en https : Content over SSL. Avec Pelican, j'imagine qu'il doit y avoir une syntaxe Apache pour arriver au même résultat ;
    
    
  • De la même manière, il faut corriger les liens internes genre ceux qui pointent vers wp-content/uploads puisque ce dossier a vocation à disparaître après la migration ;
    
    
  • Pelican ne supporte pas le multi-catégories : chaque article a une seule catégorie et des tags. Voir https://github.com/getpelican/pelican/issues/350 . Du coup, l'importateur fusionne toutes les catégories d'un même article en une seule genre un article dans les catégories nommées « divers » et « humeur » se retrouve dans une catégorie nommée « divers-humeur ». Forcément, cela fait exploser le nombre de catégories et ruine l'effet même des catégories puisque chaque article se retrouve dans une catégorie au lieu d'une union de catégories.
    
    
  • Sur mon WordPress, pour mettre en valeur les bouts de code et les commandes et pour faire de la coloration syntaxique, j'utilise l'extension wp-syntax. Sauf que cette extension prend un temps colossal à parser dynamiquement les articles. Du coup, pour chaque nouveau billet, je copie le code html qu'elle génère (« <div class="wp_syntax"><pre lang="langage">mon merveilleux code ici</pre></div> ») directement dans le billet puis je désactive l'extension. Forcément, ça ne marche plus suite à l'importation : le code est isolé dans le markdown. Il faut jouer avec des regex (et des regex capturantes) pour corriger tout ça et positionner les délimiteurs attendus ( voir http://docs.getpelican.com/en/3.6.3/content.html#syntax-highlighting ). Bref, y'a de quoi bien se prendre la tête. :S
    
    
  • Sans compter d'autres mauvaises surprises. Relire 138 articles dont la plupart sont des pavés, ça prendra forcément beaucoup de temps.

Vu tous ces points, on se rend compte que la migration depuis WordPress va nécessiter beaucoup de travail, notamment l'import depuis WP, la personnalisation du thème et l'installation d'un moteur de recherche. Une mise à jour de WordPress me prend 5 minutes montre en main (+ 5 minutes supplémentaires le temps de basher WordPress sur IRC :P ). Une faille de sécurité WordPress est tombée en moyenne tous les 2 mois sur la dernière année. Il me faut donc 5 minutes tous les 2 mois soit 30 minutes par an. La question devient donc : combien de mises à jour de WordPress faudrait-il avant que le passage à Pelican soit rentabilisé ? On sent bien qu'on est sur plusieurs années d'équivalence.

Notes diverses sur Pelican

• ÉDIT DU 25/09/2016 À 21H10 : y'a un article sympa sur Pelican dans GNU/Linux magazine France numéro 184. FIN DE L'ÉDIT.
  
  
• Avec jessie-backports, l'installation se résume à : apt-get installl python-ps4 python-lxml pandoc pelican
  
  
• Importer depuis Wordpress au format markdown :
  • Dans l'interface d'admin WordPress : « Outils » -> « Exporter », laisser cocher « Tout le contenu » -> « Télécharger le fichier d'export ». Source : http://marieguillaumet.com/exporter-et-importer-wordpress-quelques-astuces/
    
    
  • pelican-quickstart puis cd dans le dossier de votre nouveau blog puis pelican-import --wpfile ../export.xml -m markdown -o content [--dir-page --dir-cat] . Attention : si votre blog contient de bon gros pavés, il faudra pas mal de RAM pour effectuer la conversion. Genre 512M de RAM ne suffisent pas pour convertir mon blog, pandoc se fait tuer par l'OOM-killer de Linux.
    
    
  • make html pour générer localement votre blog. make serve pour lancer un serveur web minimaliste local et accéder à votre blog via localhost:8000 . Il est tout à fait possible de make html pendant qu'un make serve est en cours de fonctionnement.
    
    
  • pelicanconf.py : définir les paramètres à utiliser pour générer la copie locale, votre site web de dev'. publishconf.py : la même mais pour le site web de prod'.

En résumé, j'ai creusé (un peu) le monde des générateurs de sites web statiques et j'ai approfondi Pelican. Mais, je ne migrerai pas mon blog existant car cela représente trop de travail pour assurer la qualité de l'import.