- JeffGeerling.com, operado sobre Drupal desde 2009, fue migrado al generador de sitios estáticos (SSG) Hugo para mejorar la eficiencia del blog personal
- La principal razón del cambio fue la carga de actualizaciones y mantenimiento acumulada desde Drupal 6 hasta 10
- Hugo permite escribir con base en Markdown, lo que simplifica el complejo proceso de publicación anterior y hace posible publicar y desplegar con una sola línea de comando
- Durante la migración pueden surgir algunos problemas como errores en enlaces de imágenes y pérdida de URL, y las funciones de comentarios y búsqueda se restaurarán en una etapa posterior
- Es un caso que muestra las ventajas prácticas de migrar a un sitio estático, al ofrecer a desarrolladores individuales un flujo de trabajo más simple y mayor eficiencia de mantenimiento
Antecedentes del cambio de Drupal a Hugo
- El sitio comenzó en 2009 con Drupal 6 y pasó por actualizaciones graduales a 7, 8, 9 y 10
- Se había aplicado al blog personal el mismo CMS que se usó profesionalmente durante más de 10 años
- Después del complejo proceso de actualización de Drupal 7 a 8, se fue acumulando el cansancio de mantener en un blog personal una Digital Experience Platform (DXP) de nivel empresarial
- El blog se usa como proyecto personal y espacio de apoyo para contenido de YouTube, y se tomó la decisión de cambiar para enfocarse en escribir en lugar de mantener el CMS
Por qué se eligió Hugo
- Ya existía experiencia previa migrando sitios de hobby a hosting estático, y algunos se habían convertido a Jekyll o Hugo
- Jekyll es adecuado para GitHub Pages, pero como no es especialista en Ruby, se prefirió la configuración sencilla y la rapidez de Hugo
- Hugo ofrece soporte nativo para Markdown, lo que encaja de forma natural con la manera en que ya se escribía
Proceso de migración y problemas
- El trabajo de migración sigue en curso en GitHub issue #158
- Debido a los más de 3,500 artículos y 20 años de datos, pueden existir algunos problemas con imágenes, errores de enlaces y redirecciones faltantes
- Se está intentando conservar al máximo la estructura de URL existente o agregar redirecciones cuando sea necesario
Mejora del flujo de trabajo basado en Markdown
- Desde 2020, todos los artículos se escriben en Markdown
- Antes, se escribían en Markdown en Sublime Text, luego se convertían a HTML y se subían manualmente a Drupal
- En Drupal, publicar un artículo requería un proceso de varias etapas
- Pegar el contenido, subir e insertar imágenes por separado, ajustar la fecha de publicación, limpiar caché, etc.
- También incluía la gestión de caché de Cloudflare para responder a DDoS, lo que hacía el proceso más complejo
- En Hugo, después de escribir el archivo Markdown, se puede publicar de inmediato con el comando
hugo && git commit && git push
- Al desaparecer la carga de administrar Composer, Drush, PHP, MariaDB y Nginx, mejora la eficiencia de mantenimiento
Planes futuros (TODOs)
- La función de comentarios se restaurará en una segunda etapa con un sistema de comentarios estáticos autoalojado
- La búsqueda del sitio antes se basaba en Apache Solr, pero actualmente está desactivada
- Se está revisando cómo implementar la búsqueda dentro de Hugo en issue #168
- En la etapa inicial de la migración, los comentarios están desactivados, y la migración tomará tiempo
El significado del cambio
- Se deja atrás la compleja estructura de creación y gestión de contenido de Drupal para pasar a un modelo de operación de sitio estático más simple y eficiente
- Es un ejemplo práctico de cómo los desarrolladores individuales pueden reducir la carga de mantenimiento y concentrarse en crear
- La migración a Hugo se valora como un paso que mejora la sostenibilidad de operar un blog personal
1 comentarios
Comentarios de Hacker News
Hace unos años migré mi sitio web personal a un generador de sitios estáticos basado en Common Lisp que hice yo mismo.
Al principio tenía unas 850 líneas, pero ahora ha crecido a unas 1500, y renderiza estáticamente casi todo: posts del blog, libro de visitas, páginas de comentarios, feeds RSS por etiqueta y más.
Como escribo a mano todo el código, HTML y CSS, puedo mantener control estético total, y también agregar funciones nuevas rápidamente.
Por ejemplo, para añadir una página de “backlinks” me bastaron unas 40 líneas de código en CL y 15 minutos.
Ahora es muy estable, así que casi no tengo que tocarlo y puedo concentrarme solo en escribir.
Me gastaba todo el tiempo jugueteando con el motor del blog y al final no escribía nada.
Por eso volví deliberadamente a una solución de hosting con menos control. Ahora puedo concentrarme únicamente en escribir.
Antes mantenía un proyecto público llamado Tclssg, y gracias al feedback de usuarios terminé documentándolo y agregando muchas funciones.
Pero al ser un proyecto público, era difícil cambiar la estructura libremente.
Ahora uso un generador compuesto por Python (900 líneas) + Pandoc Lua (700 líneas) dedicado solo a mi sitio.
La evolución técnica está resumida en mi sitio.
Ahora lo estoy rehaciendo en TypeScript/Bun, y todavía conserva elementos tipo LISP.
Estoy buscando un dialecto ligero de LISP/Scheme que incluya SQLite y parsing de HTML, y que compile nativamente.
Reuní información relacionada aquí.
Incluso después de años, todavía puedo compilar el sitio completo en menos de un segundo.
También agregué por mi cuenta feeds RSS y resaltado de código, usando Chroma y Blackfriday.
Probé Hugo, pero me pareció demasiado complejo, así que lo implementé yo mismo.
Antes me pasé de svbtle a Hugo, y sinceramente me arrepiento.
Hice un fork del tema, pero Hugo se rompía seguido y el mantenimiento me consumía demasiado tiempo.
Ahora mismo el sitio ya ni siquiera compila.
Mi consejo sería guardar también en control de versiones la versión binaria con la que se construye el sitio.
Los generadores de sitios estáticos casi no tienen problemas de seguridad, así que si no te falta ninguna función, puedes seguir usando la versión vieja tal cual.
Mientras no cambien mucho el sistema operativo o el CPU, no debería haber problema.
Yo también fijé la versión tomando como referencia esta configuración.
Para encontrar una versión que funcione, lo más eficiente es usar búsqueda binaria.
Como tanto en local como en CI uso la misma versión de Hugo, ya no hay margen para que aparezcan esos problemas.
${project}/bin/, ignorarlos con.gitignorey registrar el checksum en un archivoSHA256SUMS.Es una especie de versión simplificada de Git LFS.
Me da miedo cuadrar las versiones cada vez que cambio de computadora, y al final estoy porteándolo a PHP, aunque todavía no lo termino.
Si eres de los que escriben en Markdown, cambiarse a Hugo tiene sentido.
Yo también migré más de 500 posts de Jekyll a Hugo, y lo más difícil fue la sintaxis de plantillas.
Aun así, en general valió la pena.
Documenté el proceso de migración y el script de conversión automática en un post del blog.
Los SSG son buenos para sitios estáticos, pero cuando hace falta interacción, necesitas un servidor.
Si de todos modos vas a tener un servidor corriendo, es más simple renderizar Markdown de forma dinámica.
Al final, un SSG solo aumenta las dependencias y las cosas que se pueden romper.
Creo que Jeff se va a arrepentir más adelante cuando quiera añadir funciones como comentarios.
Personalmente, me parece que una solución simple basada en SSR es más realista.
Las páginas estáticas no tienen ese riesgo, y la mayor parte del tráfico es solo de lectura.
Parece que Jeff también quiere implementar él mismo la función de comentarios en un issue.
El volumen de código es mucho menor y más simple que en la época en que usaba Drupal.
Me da curiosidad el proceso de decisión al elegir un SSG.
Hay muchas herramientas importantes como Hugo, Eleventy y Jekyll, y Hugo en particular rompe la compatibilidad con bastante frecuencia.
Si es un proyecto antiguo, creo que a estas alturas ya debería garantizar estabilidad.
Eso rompió la compilación de mi blog, y la documentación todavía no está actualizada del todo.
El cambio en sí está bien, pero el problema es que la documentación no lo acompaña.
Me pregunto cómo estará Pelican hoy en día.
En el ecosistema Python, Hugo y Pelican parecen ser los dos grandes.
Incluso la integración con ActivityPub se ve más atractiva que RSS.
Antes usaba Nikola, pero tenía demasiadas dependencias y problemas de inconsistencias en builds incrementales.
Me gusta que Pelican mantenga la simplicidad.
La documentación se siente como si estuviera 90% terminada, así que faltan detalles finos, pero si usas solo lo básico, funciona excelente.
Hay commits todos los meses, así que el proyecto sigue vivo.
Ahora mismo estoy tratando de migrar de Hugo a Zola.
La configuración y las plantillas de Zola me resultan mucho más intuitivas.
Automaticé build y despliegue con GitHub Actions.
Llevo 3 años usando Hugo.
Lo que aprendí es que hay que hacer fork del tema y mantenerlo uno mismo.
Conviene evitar submódulos y hacer actualizaciones con calma.
La función de comentarios sigue viéndose complicada.
Yo también intenté migrar un tema de Drupal y terminé abandonándolo.
Me parece mejor incluirlo directamente y sobrescribir solo las partes necesarias, en vez de usar submódulos.
El año pasado empecé un blog con Hugo, pero en 3/4 de mis 18 posts sufrí errores de compilación.
Me decepcionó mucho lo inestable que era.
En vez de adaptarme a la forma de trabajar de Hugo, me resultó mucho más cómodo implementarlo rápido en un lenguaje que ya conozco.
Hace tiempo hice por mi cuenta un SSG sencillo, y hace poco, buscando algo más estructurado, probé 11ty.
Pero las plantillas Liquid me resultaron muy incómodas.
Quería usar plantillas basadas en JSX, pero 11ty hace que eso sea difícil.
El SSG de NextJS tiene muchas funciones, pero es tan complejo que se siente excesivo.
También estoy considerando crear un SSG personalizado sobre un framework como Tempest.
Yo también migré un sitio basado en Punch a Eleventy, y si la velocidad de compilación te alcanza, me parece mejor que Hugo.
Ahora lo rehice en Astro.
Está centrado en lo estático, pero si hace falta también permite usar lógica de backend.
NextJS era demasiado complejo para un sitio tan simple.