Passer de WordPress à Jekyll

Cela fait un moment que j’en ai un peu marre de WordPress. Il est très difficile de faire un site WordPress réellement performant – surtout avec un hébérgement mutualisé à prix raisonnable. Quelques tests de blogs personnels avec l’outil de mesure des performances de Google me l’ont confirmé.

Problèmes de performance

Les fichiers JavaScript et CSS se ramassent à la pelle dans un thème WordPress classique sur une installation classique. Chaque plugin en ajoute et le navigateur doit donc effectuer plusieurs requêtes inutiles au serveur. Tout cela retarde l’affichage des pages. Les visiteurs ont peu de patience – notamment sur mobile.

Pour y remedier, il faut limiter drastiquement le nombre de plugin installé et installer un plugin de cache en combinaison avec un solide Content Delivery Network (CDN).

Avec leurs produits Accelerated Mobile Pages et Instant Articles, Google et Facebook offrent une solution au problème mais, dans le même temps, s’insèrent entre les éditeurs et leurs audiences en récoltant toutes les données générées par les visites.

Ces solutions propriétaires ou quasi-propriétaires contrôlées par ces deux grands acteurs du web ne sont pas strictement nécessaires. Et je répugne à encourager la main-mise de ces entreprises sur le web plus que nécessaire. Mettre en oeuvre ces technologies lourdes, coûteuses en temps et en énergie (et qui vont à l’encontre du web ouvert) pour un blog personnel est un peu absurde.

Le HTML et le CSS peuvent être très performants. Il suffit de ne pas allourdir les pages déliberemment.

Cahier des charges et choix d’un système de gestion.

Mon cahier des charges était assez simple.

  • Un site simple pour partager des textes et des images
  • Un site pas cher à consulter sur mobile
  • Le code source lisible pour les gens qui apprennent le HTML et le CSS
  • Un site amusant à éditer (comme en 1997) où on peut rapidement ajouter des fonctionnalités intéressantes.

J’ai examiné des solutions sans bases de donnée générant les pages HTML à la volée sur le serveur comme Grav ou Kirby et des programmes qui génèrent des fichiers HTMLs en local à partir de contenus en Markdown pouvant être ensuite transférés sur le serveur comme Hugo ou Jekyll.

J’ai fini par choisir Jekyll. Il génère des fichiers HTML sur ma machine. Il n’y a aucun programme à tenir à jour sur le serveur donc pas de failles potentielles à surveiller. La communauté est grande et active. La documentation est de très bonne qualité. Il est d’une grande souplesse. Et contrairement à Grav et Kirby, chaque page n’a pas forcément son propre dossier.

Je vais vous expliquer comment j’ai fait pour réaliser cette migration. On va partir du principe que Jekyll est installé, que vous avez installé un thème et que vous vous êtes déjà familiarisé avec ce petit programme pour nous concentrer sur la migration.

Exporter les contenus

Il faut se rendre dans l’administration de WordPress et faire un export complet du contenu dans le format ExtendedRSS. Sauvegardez aussi vos images et autres fichiers.

Ensuite, stockons ces sauvegardes dans un endroit sûr. Nous travaillerons sur des copies pour éviter tout accident.

Après, il convient d’installer ExitWP en clonant le dépôt ou en téléchargeant l’archive. Placez une copie de votre fichier d’exportation XML dans le dossier wordpress-xml puis lancez la commande python exitwp.py.

Cela devrait donner un dossier avec tous les billets au format Markdown et leurs métadonnées en Front Matter YAML dans le dossier build.

Maintenant, réservons une copie de ces fichiers dans un endroit sûr et faisons une copie de travail. Nous allons nous occuper de modifier les URLs des fichiers et des liens internes de notre blog.

URLs des images

Les URLs des images sont un problème car ExitWP ne les convertit pas. Mes URLs d’image avaient des formats variés car WordPress laisse énormément (trop?) de libertés dans ce domaine. J’avais donc des URLs d’image qui suivaient 4 schémas différents:

  • http://evrenkiefer.com/wordpress/wp-content/2013/03/…
  • https://evrenkiefer.com/wordpress/wp-content/2013/03/…
  • http://www.evrenkiefer.com/wordpress/wp-content/2013/03/…
  • https://www.evrenkiefer.com/wordpress/wp-content/2013/03/…

Pour me débarasser du problème, j’ai converti tous mes liens vers des images en liens relatifs. Je voulais stocker les images de mon site dans un dossier images à la racine.

Pour ce faire, j’ai utilisé la fonction “rechercher et remplacer” de Sublime Text avec REGEXP. Il m’aura suffit de remplacer:

]\(https://www.evrenkiefer.com/wordpress/wp-content/uploads/[0-9]+/[0-9]+/

par

](./images/

Je suis passé par toutes les permutations de mes URLs avec http, https et www. ou sans www manuellement. Ce n’est pas la solution la plus élégante sans doute mais cela n’a pas pris beaucoup de temps.

Liens internes

Pour les liens internes de billet à d’autres billets, j’ai suivi la même méthode que pour les images. J’en ai aussi profité pour passer les liens en liens relatifs et pour simplifier mes permaliens.

Tous mes billets sont des fichiers HTML simples stockés dans un dossier posts à la racine. Le nom du fichier commence par la date, suivie du titre du billet. Il suffit donc de remplacer les / de l’URL WordPress par des - et d’ajouter ./posts/ au début et .html à la fin.

Il faut parfois faire quelques essais surtout si on est pas sûr de la structure des liens que l’on souhaite.

Malheureusement, les images mise en avant ou featured ne sont pas prises en compte par ExitWP. Il s’agit donc d’informations qui ont été perdues.

Des personnes plus motivée et habituée à Python pourront certainement modifier ExitWP pour que ces informations perdurent. Pour ma part, j’étais pressé par le temps, je voulais m’offrir un nouveau site rapide et simple avant Noël.

Captions et autres shortcodes

Les billets WordPress ont tendance à contenir des shortcodes notamment [caption] … [/caption]pour les légendes d’images. Jekyll a une équivalent des shortcodes: les tags Liquid. On peut placer des codes comme {% ceci %} dans les contenus. Il existe des plugins à installer et des filtres que l’on peut programmer pour modifier la sortie Markdown de Jekyll en fonction de ces codes. J’ai choisi de ne pas y faire appel pour les légendes des images – mon blog comportait peu de photos et encore moins de légendes.

Inclusion de tweets et de vidéos YouTube

Par contre, j’ai fait le choix de faire appel aux tags Liquid pour remplacer les embed dynamiques de WordPress où il suffit de mettre l’URL d’un tweet ou d’une vidéo YouTube pour la voir apparaître dans le billet. J’utilise cette fonction constamment car je vis sur Twitter.

Twitter

Les plugins Jekyll sont très simples à installer: il suffit de les mettre dans le bon dossier et d’utiliser les bons codes dans les billets. Il existe un très bon plugin Jekyll pour Twitter par Rob Murray.

Il m’a suffit de rechercher et remplacer les URLs de tweets qui sont sur leur propre ligne par cette syntaxe:

{% twitter https://twitter.com/rubygems/status/518821243320287232 %}

YouTube

Même chose pour YouTube par un autre auteur.

Redirections

J’ai fait un fichier .htaccess dans lequel je fais une redirection permanente de mes anciennes URLs de billets vers les nouvelles. Il est aisé de sortir la liste des URLs originales du fichier d’export de WordPress. Ensuite, en utilisant la fonction rechercher et remplacer intelligemment, il est aisé d’arriver à des lignes qui ressemblent à:

Redirect 301 /2017/11/16/news-and-links-in-bulk-16-11-2017/  /posts/2017-11-16-news-and-links-in-bulk-16-11-2017.html

Et voilà… Une bonne base de départ.