{"id":303,"date":"2026-05-10T07:03:22","date_gmt":"2026-05-10T11:03:22","guid":{"rendered":"https:\/\/juredev.com\/blog\/?p=303"},"modified":"2026-05-10T09:35:44","modified_gmt":"2026-05-10T13:35:44","slug":"arquitectura-hibrida-2-0-como-automatice-la-inteligencia-de-mis-hubs-de-contenido","status":"publish","type":"post","link":"https:\/\/juredev.com\/blog\/2026\/05\/arquitectura-hibrida-2-0-como-automatice-la-inteligencia-de-mis-hubs-de-contenido\/","title":{"rendered":"Arquitectura H\u00edbrida 2.0: C\u00f3mo automatic\u00e9 la inteligencia de mis Hubs de contenido"},"content":{"rendered":"\n

En el art\u00edculo anterior<\/a> expliqu\u00e9 c\u00f3mo rescat\u00e9 mis mejores art\u00edculos del cementerio cronol\u00f3gico de WordPress usando Hugo para crear Hubs de conocimiento. El resultado fue una secci\u00f3n \/temas\/<\/code> r\u00e1pida, limpia y bien organizada.<\/p>\n\n\n\n

Pero hab\u00eda un problema que no mencion\u00e9: cada vez que publicaba un art\u00edculo nuevo, ten\u00eda que sentarme frente al ordenador, ejecutar el script manualmente y esperar a que Hugo compilara. Si estaba fuera de casa o solo con el m\u00f3vil, los Hubs se quedaban desactualizados.<\/p>\n\n\n\n

El contenido era din\u00e1mico. La arquitectura, demasiado est\u00e1tica.<\/p>\n\n\n\n

La pregunta correcta<\/h2>\n\n\n\n

Podr\u00eda haberlo resuelto con un webhook, con una GitHub Action o con cualquier servicio de CI\/CD. Pero el objetivo siempre ha sido el contrario: menos dependencias externas y m\u00e1s control propio.<\/p>\n\n\n\n

La pregunta no era \u00ab\u00bfqu\u00e9 servicio uso?\u00bb. \u00abEra \u00bfc\u00f3mo hago que el propio servidor sepa cu\u00e1ndo reconstruirse?\u00bb.<\/p>\n\n\n\n

El pegamento: Juredev Hubs Connector<\/h2>\n\n\n\n

Todo el sistema depende de un dato clave: saber a qu\u00e9 Hub pertenece cada art\u00edculo. Esa informaci\u00f3n no existe en WordPress por defecto, por lo que hay que crearla.<\/p>\n\n\n\n

El plugin Juredev Hubs Connector resuelve esto con tres hooks de WordPress. El primero a\u00f1ade un selector en el editor lateral de cada post. El segundo guarda la elecci\u00f3n como un metadato al publicar. El tercero inyecta autom\u00e1ticamente un banner al final del art\u00edculo con el enlace de vuelta al Hub.<\/p>\n\n\n\n

El selector<\/code> es un con los diez Hubs disponibles en el panel lateral del editor. Cuando guardo el post, el plugin escribe el slug elegido en wp_postmeta<\/code> bajo la clave _juredev_selected_hub<\/code>. Un dato minimalista que hace exactamente una sola cosa.<\/p>\n\n\n\n

El banner que aparece al final de cada art\u00edculo usa rel=\"tag\"<\/code> en el enlace, un detalle sem\u00e1ntico peque\u00f1o que refuerza la relaci\u00f3n entre el art\u00edculo y su Hub para los crawlers:<\/p>\n\n\n\n

$banner_html = '<p class=\"post-series\">\n    Tema Relacionado: <a href=\"' . esc_url( $hub_url ) . '\" rel=\"tag\">' . esc_html( $hub_name ) . '<\/a>\n<\/p>';<\/code><\/pre>\n\n\n\n
Vale la pena mencionar que el plugin verifica tres condiciones antes de inyectar el banner: que sea una p\u00e1gina de art\u00edculo individual, que est\u00e9 dentro del loop principal y que sea la query principal. Sin esas comprobaciones, el banner podr\u00eda aparecer en widgets, excerpts o cualquier otro lugar donde WordPress renderice contenido.<\/p>\n\n\n\n
El cerebro del sistema: una query SQL<\/h2>\n\n\n\n
Antes de pensar en automatizaci\u00f3n, tuve que resolver un problema m\u00e1s fundamental: \u00bfqu\u00e9 datos necesita Hugo exactamente?<\/p>\n\n\n\n
La respuesta est\u00e1 en SELECT-WP-POST.sql<\/code>, una consulta que hace varias cosas a la vez. Extrae t\u00edtulo, fecha, slug y resumen de cada art\u00edculo. Resuelve la imagen destacada navegando por la tabla de metadatos. Agrupa categor\u00edas y tags con GROUP_CONCAT<\/code>. Y hace algo espec\u00edfico de esta arquitectura: lee el campo _juredev_selected_hub<\/code>, el metadato que el plugin Juredev Hubs Connector escribe cuando asigno un art\u00edculo a un Hub desde el editor de WordPress.<\/p>\n\n\n\n
(SELECT meta_value FROM wp_postmeta \n WHERE post_id = p.ID \n AND meta_key = '_juredev_selected_hub') AS hub_slug,<\/code><\/pre>\n\n\n\n
Esa l\u00ednea es el puente entre los dos sistemas. Sin ella, Hugo no sabr\u00eda qu\u00e9 art\u00edculos pertenecen a qu\u00e9 Hub.<\/p>\n\n\n\n
Hay tambi\u00e9n un detalle de criterio editorial: los art\u00edculos etiquetados como Opini\u00f3n<\/code> est\u00e1n excluidos expl\u00edcitamente. Los Hubs son colecciones t\u00e9cnicas. Las opiniones tienen su propio espacio en el feed cronol\u00f3gico. La query lo refleja:<\/p>\n\n\n\n
AND p.ID NOT IN (\n    SELECT tr.object_id FROM wp_term_relationships tr\n    INNER JOIN wp_term_taxonomy tt ON tr.term_taxonomy_id = tt.term_taxonomy_id\n    INNER JOIN wp_terms t ON tt.term_id = t.term_id\n    WHERE tt.taxonomy = 'post_tag' AND t.name = 'Opini\u00f3n'\n)<\/code><\/pre>\n\n\n\n
El exportador: PHP hablando directamente con la base de datos<\/h2>\n\n\n\n
El script export-wp-to-hugo.php<\/code> no usa la API REST de WordPress. Se conecta directamente a la base de datos, ejecuta la query SQL y vuelca el resultado en data\/posts.json<\/code>, el archivo que Hugo usa para construir cada Hub.<\/p>\n\n\n\n
La raz\u00f3n de ir directo a la DB en lugar de usar la API es simple: velocidad y control. No hay overhead de HTTP, no hay autenticaci\u00f3n y no hay plugins que puedan interferir. El script lee, transforma y escribe:<\/p>\n\n\n\n
$row['categorias'] = explode(', ', $row['categorias']);\n$row['tags'] = explode(', ', $row['tags']);<\/code><\/pre>\n\n\n\n
Esas dos l\u00edneas convierten los strings de GROUP_CONCAT<\/code> en arrays reales, que es el formato que espera Hugo en sus templates.<\/p>\n\n\n\n
El vigilante: Bash + WP-CLI + Cron<\/h2>\n\n\n\n
Con el exportador listo, el siguiente paso fue hacer que el servidor decidiera cu\u00e1ndo ejecutarlo. La soluci\u00f3n es un script bash que act\u00faa como vigilante y corre cada 15 minutos v\u00eda cron:<\/p>\n\n\n\n
*\/15 * * * * \/bin\/bash \/home\/temasadmin\/auto-deploy-hugo.sh<\/code><\/pre>\n\n\n\n
La l\u00f3gica es deliberadamente simple. El script pregunta a WordPress cu\u00e1l es el ID del \u00faltimo art\u00edculo publicado:<\/p>\n\n\n\n
ID_ACTUAL=$(wp post list --post_type=post --post_status=publish \\\n  --posts_per_page=1 --field=ID \\\n  --path=$PATH_WP --skip-plugins --skip-themes --allow-root)<\/code><\/pre>\n\n\n\n
Lo compara con el \u00faltimo ID que registr\u00f3 en un archivo de texto plano. Si el n\u00famero creci\u00f3, hay contenido nuevo. Si no, no hace nada y el servidor queda en reposo. Sin polling innecesario, sin peticiones HTTP y sin dependencias externas.<\/p>\n\n\n\n
Cuando detecta un ID nuevo, ejecuta la cadena completa:<\/p>\n\n\n\n
\/usr\/bin\/php export-wp-to-hugo.php    # Actualiza el JSON desde la DB\n\/usr\/local\/bin\/hugo --gc --minify           # Recompila el sitio est\u00e1tico\n\/usr\/bin\/rsync -avzh --delete public\/ $WEB_DIR\/  # Sincroniza solo lo que cambi\u00f3\nchown -R www-data:www-data $WEB_DIR     # Ajusta permisos\necho $ID_ACTUAL > $LAST_ID_FILE         # Registra el nuevo ID<\/code><\/pre>\n\n\n\n
Todo queda registrado en un log con timestamp. Si algo falla, hay trazabilidad.<\/p>\n\n\n\n
El flujo completo queda as\u00ed:<\/p>\n\n\n\n