Migración de WordPress a Jamstack

La gran migración: Migración de WordPress a Jamstack

Si te dedicas al desarrollo, la edición o la escritura en Internet, probablemente hayas oído hablar de WordPress. Decir que es prolífico es quedarse corto.

Cada vez que hablamos de la cuota de mercado de los distintos frameworks, alguien se saca de la manga una nueva cifra para WordPress. Sarah Drasner cuando escribió sobre cuando Smashing Magazine se mudó de WordPress a Preact/Hugo a principios de este año.

He sido bastante público acerca de mis problemas con WordPress-seguridad/velocidad/bloat/UX. No es por desmerecer a los desarrolladores de WordPress ni a la gente que lo mantiene, pero para una organización como la nuestra -con ingenieros, redactores y profesionales de la experiencia de usuario disponibles para colaborar-, vivir con una plataforma que es ampliamente aceptada como torpe y pesada en beneficio de un buen backend siempre me ha parecido un poco contraintuitivo.

Así que, de forma similar al post de Sarah, voy a explorar los qué/por qué/qué de este viaje, desde aquel encuentro que tuvimos en Miami, a principios de 2020, antes de que el mundo pareciera ir a, bueno, COVID.

¿Por qué?

Estábamos cambiando de marca y el momento era perfecto para nosotros. Por qué invertir en una agencia para renombrar nuestro sitio de WordPress cuando podíamos producir un nuevo sitio basado en nuestra marca desde cero?

También teníamos nuestro proceso de creación de contenidos dividido en tres plataformas. Nuestro contenido se editaba y revisaba en Markdown, se trasladaba a WordPress y se controlaba en JIRA.

Como he mencionado antes, éramos conscientes de la preocupación general por la velocidad y la seguridad de WordPress.

Además, este sitio de WordPress representaba una parte de nuestra infraestructura desconocida para casi todo nuestro equipo de operaciones. Vonage sigue trabajando para consolidar la infraestructura de las empresas de API que ha adquirido en los últimos años, y nuestra plataforma Wordpress era un vestigio innecesario de ese legado.

Fiabilidad

Nuestro equipo de formación de desarrolladores está dentro de Relaciones con los Desarrolladores, que a su vez forma parte de la organización de Producto. Por lo tanto, no somos ingenieros a tiempo completo ni poseemos grandes cantidades de infraestructura.

Netlify nos permite despedirnos y olvidarnos de nuestro contenido. Podemos olvidarnos de la complejidad, el mantenimiento, la seguridad y la fiabilidad que conlleva WordPress. Con Netlify, siempre que nuestro sitio pueda construir, puede desplegar.

Flujo de trabajo

Como ya he mencionado, teníamos un flujo de trabajo dividido en tres plataformas. Podía resultar frustrante e inaccesible, sobre todo para los redactores externos que no tenían acceso a nuestro repositorio de contenidos, como los de nuestro programa programa Spotlight.

Uno de los objetivos de este proyecto era encontrar una forma de simplificar nuestro flujo de trabajo, con la esperanza de que nos afectara lo menos posible. Netlify CMS nos permitió hacerlo.

El flujo de trabajo editorial que ofrecía Netlify CMS reflejaba bastante nuestro flujo de trabajo existente en JIRA, dándome esperanzas de automatización (o, otra oportunidad para entrar menos en JIRA). Al mismo tiempo, el almacenamiento basado en git de Netlify CMS también reflejaba nuestro proceso de revisión existente.

El uso de Netlify CMS permitió consolidar una parte importante del proceso.

Migrar el contenido de WordPress acabó siendo el obstáculo más importante al que nos enfrentamos. Teníamos disponible la API REST de WP, así que me puse a hacer una llamada tras otra a la API para intentar identificar la mejor forma de extraer nuestro contenido de WordPress. Editamos el contenido en WordPress como Markdown, así que debe almacenarlo como tal? Me estaba emocionando al pensar que podría hacer algunas llamadas a la API para recuperar nuestro Markdown y guardarlo como archivos Markdown.

Pero, ¿se almacenaba como Markdown? Debido a la naturaleza de los plugins no mantenidos impulsados por la comunidad, nada acabó siendo tan sencillo.

Nuestras entradas almacenadas en WordPress se renderizaban como HTML. Crayon, el antiguo y abandonado plugin resaltador de sintaxis, parecía mantener el código en tablas, con columnas para los números de línea y filas por líneas de código. La última versión de Crayon antes de la desaprobación citó pasar a almacenar el código en <pre><code> al igual que otros resaltadores sintácticos. El objetivo de la última actualización era hacer el cambio más manejable, ya que sería compatible con conversores o incluso con otros resaltadores. Pero lamentablemente, el plugin era tan viejo, y el sitio tan severamente sin mantenimiento que nos enfrentamos a un obstáculo poco realista actualización de todo para sacar el contenido.

La increíble ironía de Crayon es que su mantenedor también se había hartado de WordPress y decidió trasladar su sitio y centrarse en Jekyll, una plataforma de Jamstack.

Decidimos revisar todo nuestro contenido manualmente. No tenemos los miles de artículos de Smashing Magazine, pero sí más de 500 contenidos. Antes he mencionado el cambio de marca. La decisión nos permitió revisar cada pieza de contenido para actualizar la marca, actualizar las versiones del SDK, solicitar nuevas ilustraciones y llevarlas a 2020 (pobrecitas).

Pero, ¿cómo planificar la producción de nuevos contenidos Y la revisión de todos los contenidos en cuestión de semanas? Pues no. El plan sería hacer la revisión de contenidos a lo largo de unos meses.

El Plan

Utilizando reglas de reescritura, impediríamos que la gente accediera al sitio antiguo. Serían redirigidos a la misma entrada en el nuevo dominiodonde los metadatos serían importados como archivos markdown.

El sitio antiguo se trasladaría a un nuevo dominio "heredado", con un enlace a él en cada entrada que importásemos.

El nuevo sitio ofrecería entonces una bonita nota del tipo "Todavía estamos migrando este contenido", con una cuenta atrás para redirigirles al enlace heredado.

A medida que migramos contenido, editamos el archivo markdown que ya hemos importado, eliminando el enlace heredado y añadiendo el contenido migrado, encajando el contenido en medio de la experiencia del usuario. El objetivo es limitar el impacto en el usuario y reducir el esfuerzo del equipo para migrar todo nuestro contenido rápidamente.

Para limitar aún más el impacto, dimos prioridad a la migración de nuestros contenidos más leídos y recientes, y migramos la mayoría de ellos antes de salir al mercado.

Marco de opciones

Había tenido alguna experiencia trabajando con Jekyll y un flujo de trabajo similar en el pasado. Jekyll, configurado correctamente, es increíblemente rápido de renderizar. Yo diría que es todavía a la derecha en la parte superior de la velocidad de construcción en comparación con otras plataformas Jamstack. Me pareció bien empezar por ahí, con algo que sabía que funcionaba.

También había estado experimentando con Nuxt.js, porque Vue.js es estupendo y soy un gran fan de Jamstack en general. Combinando mis dos cosas favoritas (¿Vumstack? ¿Jamue?), ¡encontré Nuxt.js! Vonage también tenía un sistema de diseño llamado Volta, basado en Bootstrap, que aplicaba todas nuestras directrices de marca, y estaba disponible como biblioteca Vue.js.

Así que construí dos pruebas de concepto, una en Jekyll y otra en Nuxt.js. A pesar de las plantillas líquidas son mucho más fáciles de trabajar en general, me encontré a mí mismo prototipos Nuxt.js mucho más rápido debido a Volta. Con un frontend que ya tenía un aspecto estupendo con nuestra marca y un renderizado del lado del servidor para que el sitio fuera rápido como un rayo, estábamos muy entusiasmados con este prototipo Nuxt.js. Después de unas semanas de ajustes y comentarios, teníamos algo parecido a lo que tenemos hoy.

Nuxt.js era el camino a seguir.

Dos semanas después de terminar nuestra prueba de concepto, el equipo de diseño dejó de utilizar Volta. Lo sustituimos por TailwindCSS, que nos permitió alcanzar la paridad de diseño con Volta, pero con puntos de ruptura más predecibles y un mayor número de utilidades para sitios responsivos.

Conclusión

El resultado para nosotros ha sido transformador. Vamos a poder ofrecer más tipos de contenidos, con mayor rapidez y fiabilidad. Ahora tenemos una plataforma que respalda todos nuestros objetivos inmediatos para 2021 y el futuro. Además, tiene una pinta INCREÍBLE, si me permiten decirlo.

La migración continúa, pero el día de la puesta en marcha no hubo contratiempos. La transición a la nueva plataforma se realizó sin problemas, con redireccionamientos a la antigua si era necesario.

Gracias a los análisis del servidor, el seguimiento es más preciso que antes y tenemos acceso a datos mucho más detallados que nos permiten definir nuestros objetivos de redacción para el futuro.