Migration de WordPress vers Jamstack

La grande migration : Migrer WordPress vers Jamstack

Si vous développez, éditez ou écrivez sur l'internet, vous avez probablement entendu parler de WordPress. Dire qu'il est prolifique est un euphémisme.

Chaque fois que nous parlons de la part de marché des différents frameworks, quelqu'un sort un nouveau chiffre de l'air pour WordPress. Sarah Drasner dans son article sur le passage de WordPress à Preact/Hugo par Smashing Magazine est passé de WordPress à Preact/Hugo au début de cette année.

Je n'ai pas caché mes problèmes avec WordPress - sécurité/vitesse/bloat/UX. Je ne veux rien enlever aux développeurs de WordPress, ni aux personnes qui le maintiennent, mais pour une organisation comme la nôtre - avec des ingénieurs, des rédacteurs et des professionnels de l'expérience utilisateur disponibles pour intervenir - vivre avec une plateforme qui est largement acceptée comme étant lourde et maladroite au profit d'un bon backend m'a toujours semblé un peu contre-intuitif.

Ainsi, à l'instar de l'article de Sarah, je vais explorer le pourquoi et le comment de ce voyage, depuis notre rencontre à Miami, au début de l'année 2020, avant que le monde ne semble se diriger vers, eh bien, le COVID.

Pourquoi ?

Nous étions en train de changer de marque, et le moment était parfait pour nous. Pourquoi investir dans une agence pour relooker notre site WordPress alors que nous pouvions produire un nouveau site basé sur notre marque à partir de zéro ?

Notre processus de création de contenu était également réparti sur trois plateformes. Notre contenu était édité et revu en Markdown, transféré sur WordPress et suivi sur JIRA.

Comme je l'ai mentionné plus haut, nous étions bien conscients des préoccupations générales concernant la vitesse et la sécurité de WordPress.

De plus, ce site WordPress représentait une partie de notre infrastructure inconnue de la quasi-totalité de notre équipe d'exploitation. Vonage continue de travailler à la consolidation de l'infrastructure des entreprises API qu'elle a acquises ces dernières années, et notre plateforme Wordpress était un vestige inutile de cet héritage.

Fiabilité

Notre équipe de formation des développeurs fait partie des relations avec les développeurs, qui elles-mêmes font partie de l'organisation des produits. Nous ne sommes donc pas des ingénieurs à plein temps et nous ne possédons pas de grandes quantités d'infrastructure.

Netlify nous permet de mettre à jour et d'oublier notre contenu. Nous pouvons nous affranchir de la complexité, de la maintenance, de la sécurité et des problèmes de fiabilité liés à WordPress. Avec Netlify, tant que notre site peut être construit, il peut être déployé.

Flux de travail

Comme je l'ai déjà mentionné, notre flux de travail était réparti sur trois plateformes. Cela pouvait être frustrant et inaccessible, en particulier pour les rédacteurs externes qui n'avaient pas accès à notre référentiel de contenu, comme ceux de notre programme programme Spotlight.

L'un des objectifs de ce projet était de trouver un moyen de simplifier notre flux de travail, en espérant que cela ait le moins d'impact possible sur nous. Netlify CMS nous a permis de le faire.

Le flux de travail éditorial fourni par Netlify CMS reflétait assez fidèlement notre flux de travail JIRA existant, ce qui me donnait l'espoir d'une automatisation (ou d'une nouvelle occasion de moins me connecter à JIRA). En même temps, le stockage basé sur git de Netlify CMS reflétait également notre processus de révision existant.

L'utilisation de Netlify CMS a permis de consolider une grande partie du processus.

La migration du contenu de WordPress s'est avérée être l'obstacle le plus important auquel nous devions faire face. Nous disposions de l'API REST de WP, alors je me suis mis à passer appel après appel à l'API pour essayer d'identifier la meilleure façon d'extraire notre contenu de WordPress. Nous modifions le contenu de WordPress en Markdown, il doit donc le stocker de la même manière ? Je commençais à m'enthousiasmer à l'idée de pouvoir faire des appels API pour récupérer notre Markdown et le sauvegarder en tant que fichier Markdown.

Mais était-il stocké en tant que Markdown ? En raison de la nature des plugins non maintenus par la communauté, rien n'a été aussi simple.

Nos articles stockés dans WordPress s'affichaient en HTML. Crayon, le vieux plugin de surlignage syntaxique abandonné, semblait conserver le code dans des tableaux, avec des colonnes pour les numéros de ligne et des lignes pour les lignes de code. La dernière version de Crayon, avant son abandon, proposait de stocker le code dans des balises <pre><code> à l'instar d'autres surligneurs syntaxiques. L'objectif de la dernière mise à jour était de rendre cette évolution plus facile à gérer, car elle serait compatible avec des convertisseurs ou même d'autres surligneurs. Malheureusement, le plugin était si vieux et le site si mal entretenu que nous étions confrontés à un obstacle irréaliste : tout mettre à jour pour sortir le contenu.

L'incroyable ironie de Crayon est que le mainteneur en avait également assez de WordPress et qu'il a décidé de déplacer son site et de se concentrer sur Jekyll, une plateforme Jamstack.

Nous avons décidé de passer en revue tout notre contenu manuellement. Nous n'avons pas les milliers d'articles de Smashing Magazine, mais nous avons plus de 500 éléments de contenu. J'ai parlé plus haut de la refonte de l'image de marque. Cette décision nous a permis de réexaminer chaque élément de contenu pour mettre à jour la marque, actualiser les versions du SDK, demander de nouvelles illustrations et les amener en 2020 (les pauvres).

Mais comment planifier la production de nouveaux contenus ET la révision de tous les contenus en l'espace de quelques semaines ? Eh bien, ce n'est pas le cas. Le plan consiste à réviser le contenu sur plusieurs mois.

Le plan

En utilisant des règles de réécriture, nous empêcherions les gens d'accéder à l'ancien site. Ils seraient redirigés vers le même article sur le nouveau domaineoù les métadonnées seraient importées sous forme de fichiers markdown.

L'ancien site serait déplacé vers un nouveau domaine "legacy", avec un lien vers celui-ci dans chaque article que nous importons.

Le nouveau site afficherait alors une note agréable du type "Nous continuons à migrer ce contenu", avec un compte à rebours pour rediriger les utilisateurs vers l'ancien lien.

Lors de la migration du contenu, nous modifions le fichier markdown que nous avons déjà importé, en supprimant l'ancien lien et en ajoutant le contenu migré, en insérant le contenu au milieu de l'expérience de l'utilisateur. L'objectif est de limiter l'impact sur l'utilisateur et de réduire la pression sur l'équipe pour migrer rapidement tout notre contenu.

Pour limiter encore l'impact, nous avons donné la priorité à la migration de nos contenus les plus lus et les plus récents, et nous avons migré la plupart d'entre eux avant la mise en service.

Choix du cadre

J'avais déjà eu l'occasion de travailler avec Jekyll et un flux de travail similaire dans le passé. Jekyll, configuré correctement, est extrêmement rapide à rendre. Je pense qu'il est toujours en tête de liste pour la vitesse de construction par rapport aux autres plateformes Jamstack. Il m'a semblé bon de commencer par là, avec quelque chose dont je savais qu'il fonctionnait.

J'ai également expérimenté Nuxt.js, parce que Vue.js est formidable et que je suis un grand fan de Jamstack en général. En combinant mes deux choses préférées (Vumstack ? Jamue ?), j'ai trouvé Nuxt.js ! Vonage disposait également d'un système de conception appelé Volta, basé sur Bootstrap, qui appliquait toutes nos directives de marque et était disponible sous la forme d'une bibliothèque Vue.js.

J'ai donc construit deux preuves de concept, l'une en Jekyll et l'autre en Nuxt.js. Bien que les modèles liquides soient généralement beaucoup plus faciles à utiliser, je me suis retrouvé à prototyper Nuxt.js beaucoup plus rapidement grâce à Volta. Avec un frontend qui s'accordait déjà très bien avec notre image de marque et un rendu côté serveur pour rendre le site rapide comme l'éclair, nous étions très enthousiastes à propos de ce prototype Nuxt.js. Après quelques semaines d'ajustements et d'application des commentaires, nous avons obtenu quelque chose de proche de ce que nous avons aujourd'hui.

Nuxt.js était la solution !

Deux semaines après la fin de notre preuve de concept, Volta a été déprécié par l'équipe de conception ! Nous l'avons remplacé par TailwindCSS, qui nous a permis d'atteindre la parité de conception avec Volta, mais avec des points d'arrêt plus prévisibles et un plus grand nombre d'utilitaires pour les sites responsives.

Conclusion

Pour nous, le résultat a été transformateur. Nous allons pouvoir fournir davantage de types de contenus, plus rapidement et de manière plus fiable. Nous disposons désormais d'une plateforme qui prend en charge tous nos objectifs immédiats pour 2021 et l'avenir. De plus, elle a une allure incroyable, si je puis dire.

La migration se poursuit, mais le jour de la mise en service n'a pas connu d'accrocs. Nous avons assuré une transition en douceur vers la nouvelle plateforme, en mettant en place des redirections vers l'ancienne plateforme si nécessaire.

Grâce à l'analyse côté serveur, le suivi est plus précis qu'auparavant et nous avons accès à des données beaucoup plus granulaires qui nous permettent d'orienter nos objectifs d'écriture pour l'avenir.