La Guía Definitiva: Comentarios en Jekyll y Migración Híbrida con Giscus
25 Jan, 2026 • 6 min de lectura
Una de las grandes “pérdidas” al migrar de WordPress a un sitio estático como Jekyll es el sistema de comentarios. Al no tener base de datos, no podemos simplemente hacer un INSERT en una tabla cuando alguien escribe.
Sin embargo, los comentarios son el alma de un blog personal. Perder los cientos de comentarios de los últimos 10 años no era una opción.
En este artículo explico cómo he resuelto este problema usando una Estrategia Híbrida: mantener los comentarios antiguos como archivos estáticos (inmortales) y delegar los nuevos debates a Giscus (GitHub Discussions).
Contenidos
El Problema: Sitios Estáticos vs Comentarios
En un sitio dinámico (WordPress), el servidor procesa el formulario y guarda el texto en MySQL. En un sitio estático (Jekyll), no hay servidor para procesar ese formulario.
Necesitamos un servicio externo que haga de intermediario.
Análisis de Opciones (Gratuitas)
Antes de decidirme, analicé las 5 mejores opciones compatibles con Jekyll y la importación de datos antiguos.
| Sistema | Importación WP | ¿Dónde vive? | Privacidad | Dificultad | Coste |
|---|---|---|---|---|---|
| Staticman | Sí (Script) | Tu Repo + Servidor | Excelente | Alta | Gratis |
| Giscus | Compleja | GitHub Discussions | Buena | Media | Gratis |
| Utterances | Compleja | GitHub Issues | Buena | Media | Gratis |
| JamComments | Nativa | Su Nube -> Build Time | Excelente | Baja | $5/mes |
| Disqus | Nativa | Su Nube (JS load) | Mala (Ads) | Baja | Gratis |
Por qué elegí Giscus
Descarté Disqus por la publicidad y el rastreo (no quiero vender los datos de mis lectores). Staticman es la opción ideal purista (guardar comentarios en el repo), pero requiere mantener un servidor Node.js externo, lo cual añade complejidad.
Giscus encontró el equilibrio perfecto:
- Sin Servidor: Usa la API de GitHub directamente desde el navegador.
- Sin Anuncios: Es Open Source puro.
- Moderno: Usa GitHub Discussions, que permite hilos y reacciones, a diferencia de Utterances que usaba Issues y ensuciaba la lista de bugs.
El Reto: Los Comentarios “Legacy”
El problema de Giscus es que requiere que el autor tenga cuenta de GitHub. ¿Qué pasa con los 1.000 comentarios que tenía en WordPress de “Pepe”, “María” o “Juan” que no son desarrolladores?
Si los importaba a Giscus vía API, todos aparecerían como creados por mí (o un bot), perdiendo su autoría original.
La Solución Híbrida
Decidí dividir el problema en dos:
-
Pasado (Legacy): Convertir los comentarios de WordPress a archivos estáticos YAML (
_data/comments/). - Futuro (Nuevos): Usar Giscus para los nuevos hilos.
De esta forma, los comentarios antiguos cargan instantáneamente como parte del HTML (sin peticiones externas) y conservan el nombre y fecha originales.
Paso 1: La Migración (Python Script)
Creé un script en Python para leer el volcado SQL de WordPress (database.sql) y generar archivos YAML.
El script hace lo siguiente:
- Lee
INSERT INTO wp_postspara mapear IDs con Slugs (URLs). - Lee
INSERT INTO wp_commentspara extraer autor, fecha y contenido. - Genera un archivo
.ymlpor cada post.
# _scripts/migrate_comments.py (Fragmento)
# ...
for slug, comms in grouped.items():
# sanitize slug for filename
safe_slug = re.sub(r'[^\w\-]', '_', slug)
path = os.path.join(OUTPUT_DIR, f"{safe_slug}.yml")
with open(path, 'w', encoding='utf-8') as outfile:
yaml.dump(comms, outfile, allow_unicode=True, default_flow_style=False)
El resultado son cientos de archivos en _data/comments/mi-articulo.yml:
- author: Paco Gomez
content: "Excelente artículo, me sirvió mucho para configurar Docker."
date: '2022-07-17 10:30:25'
id: '694'
Paso 2: Visualización en Jekyll
Creé un componente _includes/legacy_comments.html que lee estos datos y los pinta usando los estilos de DaisyUI (Chat Bubbles), para que se vean integrados.
<!-- _includes/legacy_comments.html -->
Paso 3: Integrando Giscus
Para los nuevos comentarios, simplemente añadí el script de configuración de Giscus debajo de los antiguos.
Un truco importante: Usar un repositorio separado.
Si tu blog es privado (como este repo), Giscus no funcionará bien. La solución es crear un repo público vacío (ej: becommerce-discussions) solo para alojar los comentarios.
<!-- _includes/giscus.html -->
<script src="https://giscus.app/client.js"
data-repo="raulbmole/becommerce-discussions"
data-repo-id="R_kgDORBog5w"
data-category="General"
data-mapping="pathname"
data-strict="1"
async>
</script>
Resultado Final
Ahora, al final de cada post, tengo lo mejor de los dos mundos:
- Historia preservada: Mis viejos comentarios están ahí, rápidos y con su autoría real.
- Futuro abierto: Los nuevos lectores pueden debatir usando las modernas herramientas de GitHub.
Si estás migrando a JAMStack, no sacrifiques tu historia. Esta aproximación híbrida requiere un poco más de trabajo inicial, pero el resultado vale la pena.
Te podría interesar
-
Depurando Race Conditions: Cuando DOMContentLoaded Falla
A veces, las mejoras de rendimiento traen efectos secundarios inesperados. Recientemente, al migrar Becommerce.es a una infraestructura más rápida, una funcionalidad crítica dejó de funcionar:...
-
Docker Swarm contenedor php-fpm infectado 100% CPU
Cómo Arreglar Docker Swarm Infectado con Malware PHP-FPM
-
Illuminate \ Database \ QueryException PHP SQLSTATE[HY000] [2002] No such file or directory select * from sessions where id = B9e limit 1
¡Arregla el error de Database No such file or directory select!
-
Problema comando: git Fetch --all regresa: error: cannot lock ref 'refs/remotes/origin/main: is at sd78f7u... but expected s9.... From https://GitHub.com/... (Unable to update local ref)
Problema al ejecutar git fetch --all
-
Como crear un PDF con documentación en formato .rst desde GitHub usando ibis-next, por ejemplo del repo symfony-docs - gratis
Cómo crear un PDF con documentación en formato rst desde GitHub usando Ibis-Next