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.
mysql_real_escape_string()
, utilisée par mon antispam, n'est plus disponible. Voir http://shaarli.guiguishow.info/?1_-YHwLa 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.
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.
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).
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) :
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'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 :
<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
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.
apt-get installl python-ps4 python-lxml pandoc pelican
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.
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.