He decidido retomar este blog, tras casi 6 años desde que publiqué el último artículo. Para ello he optado por abandonar WordPress y probar con un generador de sitios estáticos.

Sin duda WordPress es una gran plataforma, potente y flexible, pero actualmente considero que es totalmente innecesario tanto despliegue para un simple blog.

Estas son algunas de las ventajas que puede suponer el cambio:

  • Seguridad: Ya no es necesario estar pendiente de las actualizaciones de WordPress, ni de los plugins y temas. Tampoco de la versión del servidor de base de datos o PHP, ya que no se utiliza ninguno de estos componentes.

  • Privacidad: Una vez has equipado tu WordPress con todos los plugins que necesitas, es muy complicado hacerlo funcionar sin cookies, incluso de terceros. Con un sitio estático es mucho más sencillo.

  • Comodidad: Si te gusta tener el control de lo que escribes, resulta mucho más práctico trabajar directamente sobre un fichero de texto (normalmente con formato Markdown), que con el editor de WordPress, que tantas vueltas ha dado. Además, el desarrollo mediante el servidor local incorporado (comentado más adelante) es muy cómodo.

  • Velocidad: Era un aspecto que no me llamaba mucho la atención, porque consideraba que mis páginas en WordPress cargaban aceptablemente rápido, pero la verdad es que visto el resultado, la diferencia es notable.

Tras indagar un poco sobre el tema, las dos propuestas más interesantes me parecieron Hugo y Jekyll. Me decanté directamente por la primera y, sin haber probado otra, os cuento mi experiencia.

¿Cómo funciona Hugo?

Hugo es una herramienta multiplataforma, publicada bajo licencia Apache 2.0, para ejecutar desde el terminal. En el caso de GNU/Linux está disponible en el repositorio de la mayoría de distribuciones.

No voy a entrar en detalles técnicos, ya que la documentación del proyecto es suficientemente clara, pero el ciclo de desarrollo con Hugo sería básicamente así:

  • Creación del nuevo sitio (hugo new): con esto creamos una estructura de carpetas y archivos para el nuevo proyecto.

  • Arranque del servidor de desarrollo (hugo server): este comando lanza un servidor HTTP en nuestra máquina, al que conectarnos localmente para ir comprobando el resultado final. Incorpora LiveReload, lo que significa que en el momento en que guardemos un cambio en cualquier archivo, la página que tengamos abierta se actualizará automáticamente en el navegador, si se viese afectada por este.

  • Configuración y apariencia: elegimos un tema de entre todos los disponibles, lo copiamos a la carpeta /themes, y configuramos lo necesario en el archivo config.toml.

  • Incorporación de contenido al sitio: creamos archivos con formato Markdown en la carpeta /content, que se convertirán en cada una de las páginas del sitio.

  • Despliegue (hugo): este comando genera los archivos definitivos en la carpeta /public, que deberemos subir a nuestro servidor web público.

Si antes comentaba las ventajas de un sistema de este tipo, tras haber probado Hugo puedo mencionar algunos inconvenientes, que también los tiene:

  • Pérdida de interacción con el visitante al no disponer de un sistema de comentarios, a menos que utilicemos un servicio externo. Hugo se integra nativamente con Disqus, y cuenta con otras opciones menos directas. En mi caso, y de momento, he descartado esta funcionalidad.

  • Imposibilidad de gestionar la web desde cualquier lugar. Necesitaremos siempre tener Hugo instalado, los archivos del proyecto, acceso al servidor web público, etc. Si es imprescindible, esto también se puede solventar con servicios como Netlify, pero en mi caso, para algo tan sencillo como un blog, no lo veo necesario.

Migración desde WordPress

Para migrar el contenido desde WordPress, he utilizado el plugin recomendado en la propia documentación de Hugo. Al ejecutarlo se obtienen todos los archivos con el contenido del sitio WordPress, para colocar directamente en la carpeta /content del proyecto Hugo. Así de fácil.

En realidad este plugin no convierte las páginas a Markdown, sino que extrae directamente el código HTML. Por ello, para que Hugo las muestre, debemos establecer lo siguiente en el archivo de configuración:

[markup.goldmark.renderer]
unsafe = true

El resultado de la migración ha sido realmente bueno, teniendo en cuenta la sencillez del proceso. Sólo algunos desajustes a nivel estético, la mayoría de los cuales he podido solventar mediante CSS.

Salvaguarda del sitio WordPress

Evidentemente, antes de eliminar completamente el sitio WordPress, he descargado todos los archivos y un export de la base de datos. Pero si en algún momento quisiera consultarlo de nuevo, me obligaría a crear/importar de nuevo la base de datos, además de subir los archivos al mismo dominio.

Para evitar todo eso, el plugin Simply Static permite exportar fácilmente todo el sitio, tal cual, a archivos estáticos y descargarlos. Posteriormente es suficiente con subir estos archivos a cualquier servidor web para volver a tener acceso a todas las páginas, tal como las dejamos en su momento, sin necesidad de base de datos.

Detalles adicionales

Para evitar que el servidor Apache muestre los archivos de las carpetas que no tienen una página por defecto, he creado un fichero .htaccess en la carpeta /static del proyecto (Hugo traslada el contenido de esta carpeta tal cual cuando genera la versión pública definitiva), con esta directiva:

Options All -Indexes

Por otro lado, para sincronizar mi carpeta /public con el servidor del alojamiento web, utilizo la herramienta lftp, cuya funcionalidad mirror es ideal para este cometido.

Conclusión

Teniendo en cuenta que llevo años utilizando WordPress, y que apenas acabo de conocer Hugo, me resulta difícil (y sería injusto) hacer una recomendación seria en un sentido u otro. Ahora mismo estoy contento con el cambio, pero sólo lo recomendaría para casos muy concretos y sencillos como el mío. Si profundizo más y lo veo de otro modo… el tiempo dirá.