Pourquoi et comment migrer de Wordpress à Hexo
Agence web » Actualités du digital » Pourquoi et comment migrer de WordPress à Hexo

Pourquoi et comment migrer de WordPress à Hexo

Depuis 2 ans environ, j’écrivais mes retours d’expériences sur un bon vieux WordPress. WordPress un outil universel, connu et utilisé par tout le monde, s’installant facilement et permettant avec un faible investissement, de créer des thèmes, des extensions…
Oui mais aujourd’hui, voilà pourquoi je me suis décidé à quitter WordPress :

  • J’utilise WordPress pour créer des contenus statiques et par conséquent, je n’ai pas de réel intérêt de générer une page dynamiquement à chaque fois.
  • WordPress est lent et malgré mon investissement, rien n’y fait, 1 seconde pour toujours ressortir le même contenu, c’est trop.
  • Je suis développeur PHP, et PHP est langage de « templating » mais je ne supporte pas de voir des mélanges de templates et de code métier…
  • … Par conséquent, je n’ai jamais pris le temps de customiser mon thème. J’utilisais le thème officiel de WordPress qui était chargé, ne prennait pas toute la largeur de l’écran et formattait l’essentiel de mon travail dans une colonne de plus ou moins 350px… !

Introduction

Oui, mais quels sont les inconvénients ?

D’une manière plus générale, les générateurs statiques comme Hexo ou Jekyll génère du contenu… statique et ne laisse donc pas la place au contenu nécessitant des traitements comme des commentaires. Ce problème m’a longtemps embêté et j’ai finalement tranché en faveur de Disqus. Avant de me décider j’ai quand même étudié un peu les projets et voici ce que j’en ai retenu.

  • Disqus (ou tout autre SaaS) décentralise votre contenu. Les commentaires ne sont pu votre propriété. Il existe un importeur et un exporteur. Malgré ça, aucune maintenance chez vous.
  • Des solutions comme Isso ou Discours vous permettent d’avoir un sysème similaire chez vous mais cela implique de backuper le contenu (problème que nous avions déjà avec WordPress), mais également de vous assurer du bon fonctionnement de votre SMTP (problématique déjà connu)…
  • Déporter les commentaires vous permet également d’héberger votre blog sur GitHub par exemple.

Isso

Isso est une super alternative qui ressemble fortemement à Disqus mais pêche sur quelques détails.

  • Pas de Back-end pour administrer les commentaires.
  • Dans mes tests, j’avais lu qu’on pouvait modérer les commentaires via un lien disponible dans un mail ou dans les logs. Je n’ai jamais vu ces liens et j’aurai donc dû effectuer des requêtes en BDD.

En dehors de cela, Isso était LE produit idéale. Je ne doute pas qu’il continue de grandir et que bientôt j’écrirai un article pour migrer de Disqus à celui-ci.

Discourse

Discourse était la seconde alternative mais je ne l’ai pas réellement testé. Celui-ci propose une version payante et ces pré-requis techniques m’ont rapidement arrêté.

Pourquoi Hexo et pas Jekyll

La réponse est simple. Jekyll est en Ruby alors que Hexo est en JavaScript (Node.js). J’aime la syntaxe JS et par conséquent il était plus simple pour le customiser, comprendre, …

Comment ça marche ?

1
2
3
4
$ # Installer Hexo
$ npm install -g hexo-cli
$ # Créer un blog
$ hexo init my-blog && cd my-blog

Et voilà, votre projet est prêt. Vous pouvez le versionner.

Comment générer le contenu

1
$ hexo generate

Comment voir le contenu écrit en Markdown sans regénérer tout le contenu

1
$ hexo server

Avec cette simple commande, vous pouvez accéder à un serveur Node.js qui vous fait le rendu en temps réel. L’adresse est généralement http://localhost:4000.

Comment migrer mes articles de WordPress

Hexo a mis en place de nombreux outils pour migrer vos contenus. Pour WordPress, cela est très simple.

1
2
3
$ npm install hexo-migrator-wordpress –save
$ # Allez dans le backoffice de votre WordPress, et [exporter le contenu de votre blog](https://en.support.wordpress.com/export/).
$ hexo migrate wordpress /path/to/file_exported.xml

Pour migrer le contenu, vous n’avez besoin de rien de plus. La difficulté réside à migrer les attachments (comme les images). Dans le dossier source/_posts vous devez créer un dossier portant le même nom que le fichier de votre article.

Exemple, pour le article dessine-moi-un-mouton.md vous devez créer un dossier dessine-moi-un-mouton.

Dans ces dossiers, vous copierez les images de votre WordPress. Vous devrez ensuite re-passer sur vos articles et changer la source. Dans mon cas, les images chargées sont restées sur la souce initiale.

Exemple:

1
2
3
4
5
6
7
# Avant
![Mon image](https://mon-blog/wp-content/mon-image.png)
# OU
<img src=« https://mon-blog/wp-content/mon-image.png » />
# Après
![Mon image](/dessine-moi-un-mouton/mon-image.png)

Pourquoi spécifier le nom du dossier dans le chemin de mon image ?

Vous pourriez tout à fait charger l’image de cette manière.

1
![Mon image](mon-image.png)

Cela pose rapidement un problème. Sur la page de l’article, l’image sera bien chargée car elle est relative à la page en cours, mais sur votre homepage, l’image sera chargée par rapport à la page d’accueil et vous verrez alors une 404 Not Found.

La configuration

Pour copier les images, vous devrez mettre cette configuration dans votre _config.yml.

1
2
# _config.yml
post_asset_folder: true

Comment mettre en place les redirections

Le principal problème une fois le contenu migré est de ne pas perdre le référencement naturel. Il s’agit du nerf de la guerre et j’ai contourné le problème assez facilement.

Les articles

Initialement, les articles ont pour URL :year/:month/:day/:title. Dans WordPress, il n’y généralement que le titre. Mettez dans votre _config.yml cette valeur.

1
2
# _config.yml
permalink: :title/

Les catégories

Avec les catégories, c’est un peu la même histoire. Cette fois le chemin est quasiment le même. Dans WordPress, c’est category/ et dans hexo categories/ (par défaut). Voici comment le changer.

1
2
# _config.yml
category_dir: category

Les tags

Avec les tags, c’est toujours la même histoire. Dans WordPress, c’est tag/ et dans hexo tags/ (par défaut). Voici comment le changer.

1
2
# _config.yml
tag_dir: tag

Les archives

C’est la partie la plus technique et la plus simple à la fois. Dans WordPress, les archives se trouvent dans year/month/ et dans hexo c’est archives/year/month/. Dans mon cas, je ne voulais pas changer le path dans hexo et je voulais garder cette nouvelle façon de faire.
Voici la redirection Nginx à mettre en place.

1
2
3
4
5
6
7
server {
location / {
rewrite ^/(d{4})/(01|02|03|04|05|06|07|08|09|10|11|12)/ /archives/$1/$2/ permanent;
}
}

Cette regex est loin d’être la plus parfaite mais elle sera redoutable.

Autre

Concernant, les attachements vous devez faire une petite redirection mais dans tous les cas, la perte de référencement sera moins préjudiciable.

Voici comment faire une redirection avec Nginx.

1
2
3
4
5
6
7
server {
location / {
rewrite ^/dessine-moi-un-mouton/mon-image/$ /dessine-moi-un-mouton/mon-image.png permanent;
}
}

Et si Google voit une redirection vers une 404 ?

Pas de soucis, avec cette condition dans Nginx, aucun problème. On redirige toutes les 404 vers la homepage.

1
2
3
4
5
6
7
8
9
server {
error_page 404 @fallback;
location @fallback {
rewrite ^/ / permanent;
}
}

Migrer les commentaires

Via Disqus, voici le lien qui vous permettra de facilement importer vos commentaires WordPress.

Sitemap

Il existe un projet permettant de facilement générer un sitemap avec Hexo. En bref, voici comment faire.

1
$ npm install hexo-generator-sitemap –save
1
2
3
# _config.yml
sitemap:
path: sitemap.xml

Conclusion

Avec un petit investissement, on migre facilement son contenu. Une petit passe pour vérifier que les articles ont correctement été migré et c’est emballé. Dans mon cas, je n’ai que 23 règles de redirection pour tout mon site. Easy ?

★★★★★