Remarque:
Ce billet en cours de d’écriture sous forme de dépêche sur le site linuxfr.org. Il a été édité en ligne et exporté en markdown.
Passer de Wordpress à Hugo c’est changer de paradigme, il faut savoir ce que l’on va gagner et ce que l’on va perdre et il faut retrousser ses manches, un jour viendra où cela se fera en un clic, mais ce n’est pas aujourd’hui !
Avec wordpress chaque page repose sur du php, un programme est exécuté qui peut faire de nombreuses actions, il y a une base de donnée. Wordpress est un des classique LAMP ( Linux Apache MySql Php ) et consors, il nécessite l’installation de multiples composants. Quand le contenu à délivrer doit s’adapter au contexte utilisateur et à d’autres facteurs, c’est approprié, pour un site de commerce ça l’est, s’il s’agit d’une vitrine statique, ça ne l’est pas. Entre les deux on trouve le blog, qui peut se balancer d’un côté ou de l’autre si l’on souhaite gérer des accès utilisateurs, suivre les pages ou ajouter des interactions.
Avec hugo, le site est généré une seule fois puis les pages sont délivrées, à l’ancienne dirait t’on. A la grande époque où l’on éditait le html à la main et on publiait son site via ftp. Sauf qu’avec hugo on manipule du markdown plutôt que du html. Le markdown est pratique, c’est l’héritage pragmatique de Aaron Schwartz duquel on peut encore trouver la trace dans le code php de génération. Le markdown lui même porte un étincelle de liberté. Et on utilise le programme hugo qui est un binaire fourni, ou bien compilé depuis du code go, pour générer des pages html. Le site généré peut être délivré en http par hugo ou bien par n’importe quel serveur web.
Sortir de wordpress c’est sortir d’une zone de confort et ce sera nécessairement perdre des fonctionalités, comme l’édition en ligne directe intégrée par exemple, le suivi de vues et les formulaires.
C’est aussi faire un choix simplificateur, économe et efficace. Beaucoup moins énergivore il est aussi beaucoup plus efficace et rapide. Il est aussi beaucoup plus facile à déployer qu’un wordpress puisque’en définitive ce n’est qu’un binaire et un thème. Un autre bonne raison de migrer est la sécurité, comme a pu le faire le projet xubuntu à la fin de l’année dernière suite à la compromission de leur site de téléchargement sous Wordpress
Mais pourquoi Hugo et pas une autre solution, par exemple jekyll?
Hugo est la version la plus efficace, écrit en go et compilé les performances se rapprochent sans les égaler de celles de rust ou de c. Et il est maintenu, dispose d’une communauté qui maintient des thèmes permettant de facilement avoir un rendu à la mode. Jekyll est en Ruby qui n’est pas le plus performant des languages mais est très versatile. Jekyll est apparu avant Hugo ce qui explique sa notoriété. Ces deux logiciels ont popularisé la génération de sites statiques.
Dans mon cas je ne me suis pas posé la question puisque je réponds à une demande d’une personne qui a déjà fait son choix, il faut migrer !
Avant de me lancer dans l’aventure j’ai du me renseigner, parce que j’opère bien un site statique qui me sert de vitrine et celui-ci est en markdown sous git, mais tout est fait à la main et je ne connais pas Hugo. Je ne suis pas non plus un grand utilisateur de Wordpress, que j’ai toujours trouvé lourd, et d’ailleurs j’ai toujours eu un faible pour les challengers, et je m’étais penché sur Joomla qui a les même défauts. Utiliser ces CMS c’est déjà avoir appris une façon de penser, avec les pages et les posts, cela ne m’a jamais paru intuitif.
Donc j’étais absolument et résolument prêt pour cette migration !
Vous pouvez à ce moment me demander pourquoi donc l’ai je fait ?
Parce qu’un ami me l’a demandé, parce qu’il remunère pour cela et parce que je trouve que cela va dans le bon sens. Celui de l’éco responsabilité, une sobriété qui ne transige pas avec la qualité et un mouvement vers plus d’indépendance.
Donc je me renseigne.
C’est assez évident en fait il suffit de suivre ce que propose le projet hugo en matière de de migration vers hugo.
ça c’est ce que l’on souhaite et j’y ai presque cru.
Il n’y a pas de plugin Wordpress officiel pour exporter vers Hugo, mais il y en a pour exporter en Jekyll. Sachant que hugo sait importer du jekyll, cela semble évident.
Tout d’abord il faut importer le plugin sous Wordpress. Si cela semble évident quand le plugin est disponible dans le magasin des plugins wordpress, cela ne l’est plus quand il faut l’installer à la main.
Dans mon cas, et peut être dans le vôtre aussi vous n’avez pas installé le Wordpress, il vous a été fourni en tant que service hébergé, et c’est pourquoi vous êtes limités aux plugins officiels, quand encore, on vous y autorise.
Donc en suivant le lien de migration depuis wordpress je lis ( en anglais mais je vous offre gratuitement la traduction ) :
Un Plugin en un clic qui convertit tous les posts, pages, taxonomies, metadata, et settings en Markdown et YAML et déposable dans Huho. (Note: Si vous avez des difficulté avec ce plugin, vous pouvez exporter le site pour Jekyll et utiliser le convertisseur intégré à Hugo listé ci-dessus)
Oui mais non, je n’ai pas accès au backend.
Et pourquoi ne pas juste installer un plugin officiel comme celui dont wordpress-to-hugo-exporter dérive ? Le jekyll-exporter
Ce n’est pas échec, mais ça n’a pas marché.
Après l’installation du plugin et l’utilisation de l’export le site me réponds aec applomb : 500 Internal ERROR.
Plutôt que d’abandonner, je cherche sur le projet source s’il y a un bug en cours et effectivement : https://github.com/benbalter/wordpress-static-site-exporter/issues/400 . Sur ce, je rajoute mes informations sur le bug et j’attends une réponse.
Donc le ça fonctionne en un clic n’aura pas tenu bien longtemps, en attendant un correctif je me penche sur une alternative. Mais ne vous inquiétez pas, nous y reviendrons, si vous avez suivi le lien de l’issue vous le savez déjà !
Ce n’est pas bien grave, il y a d’autres outils …
blog2md Fonctionne sur l’xml exporté depuis le site gratuit votre VOTRE-DOMAIN.wordpress.com. Cela sauve aussi les commentaires approuvés sous forme YOUR-POST-NAME-comments.md à côté des posts.
Ce projet n’a pas évolué depuis quatre ans, je ne vais pas choisir cette option.
wordhugopress Un petit utilitaire écrit en Java qui exporte le site Worpress depuis la base de donnée et les resources (c’est à dire par exemple les images ) stoquées localement ou à distance. Ainsi la migration depuis des backups est possible. Support de multiples sites vers un seul site Hugo.
Je n’ai pas accès à la base de donnée où à l’export des backups, je ne vais pas choisir cette option non plus.
Celui-ci est un très bon candidat, sauf que je vends mon travail et la license de cet outil est Attribution-NonCommercial-ShareAlike 4.0 International, donc je ne vais pas choisir cette option. Si mon budget avait été très important j’aurais envisagé de contacter l’auteur pour négocier, mais ce n’est pas le cas.
Donc aucun des autres outils ne répond à mes besoins.
oui mais il n’y pas que site hugo de référence non plus.
Les forums et en particulier https://discourse.gohugo.io/t/wordpress-migration-url-rewriting/3827 , mais il a été écrit il y a presque dix ans.. Et dans mes pérégrinations hors des sentiers battus des scripts python émergent https://www.infinitescript.com/2024/01/migrate-from-wordpress-to-hugo/. Ce guide aussi m’a inspiré https://fr.benchwiseunderflow.in/blog/guide-complet-migration-wordpress-hugo/ ceci dit fournir les scripts python dans son blog sans l’indentation, ce n’est pas ce qui se fait de mieux.
Et j’ai trouvé cet outil :
J’exporte donc le site via la fonction standard d’export de site wordpress qui fourni un fichier xml.
Cet export contient tout sauf les images et les autres ressources, donc il faudra que l’outil puisse les rechercher, et donc que le site wordpress soit toujours activé. Ceci ne peut donc pas se faire sur une site indisponible ou bien même déjà arrêté.
Si tu ne souhaites pas utiliser de terminal, alors je serais d’avis de te déconseiller fortement de te lancer dans l’aventure hugo. Parce qu’hugo c’est du Web as code, très exactement l’inverse du WYSIWYG le PETALE Pris à l’écrit tel à l’écran. Tout se fait en markdown dans ton éditeur favori. Ce s’opère souvent via git et le fait de pousser le commit git vers le serveur regénére le contenu du site. S’il est possible de le faire via un vscodium, je reste sur mon emacs favori.
Et il faut un serveur, une vraie machine avec une adresse ip publique, un serveur web. Là où pour du Wordpress un hébergeur fourni la solution, en hugo le plus classique est tout de même de mettre en place son propre serveur. Avec tout ce qui va bien, et le certificat pour https.
Mais avant de faire le pas, cela s’installe en local sur une machine de développement avec docker, podman, incus ou bien même directement puisque ce n’est qu’un exécutable.
sur une machine linux :
sudo apt install hugoou
snap install hugoIl suffit de lancer hugo server dans le répertoire du
projet hugo et se connecter sur le localhost avec l’url qui a été
fournie dans le terminal.
Dans le cas d’une migration tu auras forcément à modifier de nombreuses pages de ton site qui comportent des problèmes de code markdown mal converti depuis le HTML. Et il te faudra utiliser des scripts, dans ton language préféré, mais dans tous les cas l’utilisation d’expressions régulières ser nécessaire. C’est à dire : il faut connaître un minimum de programmation.
Le contenu génré par l’outil de migration ayant été copié dans le
répertoire content du projet hugo, il suffit de lancer le
serveur hugo pour qu’il soit délivré sur le port indiqué en console. En
se conenctant avec un navigateur
firefox https://localhost:1313, le contenu apparait…
Ah j’oubliais, en hugo toute la présentation est contrôlée par le thème, ici le thème choisi est ananke, c’est celui proposé dans la documentation de démarrage rapide de hugo
Il y a du contenu, certes mais quand même il y a eu des dégâts colatéraux.
Cliquez sur l’image pour voir la vidéo.
Il s’agit d’une fonctionalité ajouté dans l’éditeur de Wordpress Gutemberg, la possiblité de créer des blocks réutilisables qui seront référencés dans d’autres pages ou bien même dans d’autres blocks
Pratiquement tous les outils d’export ne conservent pas les items qui ne sont ni de type page ni de type post et quand ils conservent les autres type, ils ne gèrent pas les blocks réutilisatbles.
Dans le fichier d’export .xml de wordpress on les retrouve ainsi :
`<item> ... <wp:post_id>610</wp:post_id> ... </item>
et sont utilisés par référence :
<!-- wp:block {"ref":610} /-->Dans mon cas pour l’outil wordpress-export-to-markdown, j’ai créé une demande de fonctionalité pour le support des blocks réutilisables.
En pratique les outils perdent complètement le contenu de ces blocks.
Une façon de résoudre le problème est d’utiliser la source html générée par wordpress directement et de la convertir en markdown.
hugo ne gère pas le tag <figure>, il faut
supprimer ces tags, sinon les images qu’ils contiennet n’apparaissent
juste pas. Or Wordpress génère souvent des blocks html avec des tags
figure.
Il est crucial que les pages migrées se retrouvent au même endroit après migration. C’est crucial car cela fait partie du seo, vorte réféencement, si vos pages changent de place, les moteurs de recherche vont vous perdres, tous comme les références depuis tout autre site.
En hugo c’est le champ urldans l’en tête front-matter
du fichier markdown qui sert à indiquer où la page est distinée être
délivrée. Cette url peut être totalement différente du répertoire dans
lequel le fichier se trouve, même s’il est conseillé de conserver la
mẽme hiérarchie, c’est une solution pratique.
Wordpress délivre toutes ses pages avec des url absolues dans le corps c’est à dire avec le le nom du site intégré dans l’url, ceci est un souci quand on souhaite déplacer le site, ou bien avec un site réplica lui aussi accessible en ligne mais sous une autre url.
Les expressions régulières sont là pour ça, il faut supprimer
http://monsite du début des toutes les url. Pour rappel, à
l’intérieur d’une page html un lien
href='/article/linxufr.html' est un référence relative dans
le site courant, si l’url du site est https://example.com
alors le lien avec l’url absolue est au lien
`href='https://example.com/article/linxufr.html'.
Si vous ne faites pas vous pourriez avoir la surprise lors de l’arrêt du site wordpress de ne plus avoir les images et autres ressources car elles étaient sur le site original et non sur le nouveau site migré !
Le menu a été perdu, c’est ballot ! Via l’export hugo il n’y a pas de
menu du tout, il est perdu. Dans wordpress le menu est supporté par du
css les classes wp-block-navigation… En hugo c’est le theme qui le gère,
ici avec ananke il faut rajouter des entrées de menu avec
menu.main, dans mon cas j’ai rajouté le menu globalmeent
dena le fichier de configuration hugo mais il y a plusieurs façons de
définir les menu en hugo.
Une autre approche est de considérer qu’un site wordpress c’est un site web comme un autre. Un navigateur n’a pas de code particulier pour visualiser un site wordpress, donc un site wordpress est juste un site web, certes avec beaucoup de javascript et css, mais un site web. Et un site web, ça se siphonne, et c’est facile, il suffit de regarder le projet internet archive, par exemple le site de linuxfr le 2 avril 2018 pour s’en convaincre, il est très facile de récupérer le contenu visible d’un site web, à condition de connaître tous les points d’entrée et en pratique il suffit de partir de la page principale. Puisque vous migrez un site que vous possédez, il n’y a pas de souci à utiliser un aspirateur de site.
Une fois le site récupéré, il y a des convertisseurs markown. Et le tour est joué ! Ou presque…