# Intentando solucionar el retraso de 10 minutos
**URL:** https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254
**Category:** WordPress
**Created:** [7 Julio, 2025 21:36 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254 "2025-07-07T21:36:48Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [7 Julio, 2025 21:36 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/1 "2025-07-07T21:36:48Z")
Planeo usar el plugin wp-discourse en un [sitio web de pronóstico del tiempo](https://spacecityweather.com) de la costa del Golfo que normalmente tiene entre 10 y 20 mil visitas a páginas por día, pero que ocasionalmente, durante eventos climáticos severos, puede alcanzar entre 1.5 y 2 millones de visitas a páginas por día para aproximadamente 500-700 mil visitantes. El sitio y su estrategia de alojamiento han sido probados en batalla a través de varios eventos climáticos severos y las cosas funcionan muy bien bajo presión, principalmente gracias a un diseño cuidadoso y a la gran ayuda de Cloudflare.
Los usuarios del sitio están acostumbrados a una experiencia de comentarios de baja fricción a través de los comentarios nativos de WordPress, por lo que habrá un período de adaptación (como acostumbrarlos a hacer clic en el enlace “Continuar la discusión en…”) que el personal de cara al público está preparado para gestionar.
Sin embargo, lo que no tolerarán es el retraso variable de 10 minutos entre la publicación de los comentarios y su visualización en la página de la publicación diaria de WordPress. Querrán que los nuevos comentarios (hasta el límite configurado) aparezcan inmediatamente en la página de inicio al publicarlos, de manera similar a como los comentarios nativos de WP se muestran inmediatamente después de publicarlos.
Después de jugar con las opciones integradas para intentar que las publicaciones aparezcan inmediatamente sin la caché fastcgi de nginx, WordPress o la caché del navegador que interfieren con la aparición de nuevos comentarios al actualizar después de que se publican, he agregado los siguientes dos mu-plugins para mitigar esto y hacer que los comentarios recién publicados aparezcan en el lado de WordPress al actualizar:
[wp-discourse-transient-killer.php](https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt)
[wp-discourse-cache-header-fix.php](https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt)
Esto ha resuelto mi problema: las nuevas publicaciones en los hilos de Discourse creados por WordPress ahora aparecen debajo de las publicaciones de WordPress instantáneamente al actualizar.
Pero estoy al límite de mi competencia aquí: ¿qué estoy rompiendo/estropeando/socavando al hacer esto?
No me importa particularmente generar una carga adicional en mi proveedor de alojamiento web al tener el punto final de comentarios bombardeado por visitantes que consultan la página de pronóstico del tiempo diario (con sus comentarios de Discourse incrustados): ese es un problema que puedo resolver gastando dinero. Mi requisito principal es evitar que más de 20.000 usuarios me envíen correos electrónicos preguntando por qué sus comentarios no aparecen instantáneamente en la página de inicio cuando los publican.
¿Es este el enfoque correcto? ¿Es sensato lo que estoy haciendo? ¿Crea problemas de seguridad o rendimiento adicionales que no he anticipado? Básicamente, ¿estoy estropeando las cosas al hacer esto?
Gracias 🙂
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [7 Julio, 2025 22:55 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/2 "2025-07-07T22:55:39Z")
Hmm, estoy confundido por qué esto funciona, porque
> [@angus](#):
>
> La acción recibirá los ids de las publicaciones de Wordpress que han sido actualizadas por el webhook como argumento, es decir.
>
> `do_action( 'wpdc_after_webhook_post_update', $post_ids );`
Y tu plugin
```plaintext
add_action( 'wpdc_after_webhook_post_update', function( $topic_ids ) {
foreach ( (array)$topic_ids as $topic_id ) {
delete_transient( 'wpdc_comment_html_' . $topic_id );
}
}, 11 );
```
¿No estás mezclando los `$post_id`s (de Wordpress) pasados a la acción con el `topic_id` (de Discourse) que sirve como clave transitoria?
Esperaría que tu plugin se viera así:
```plaintext
add_action( 'wpdc_after_webhook_post_update', function( $post_ids) {
foreach ( (array)$post_ids as $post_id ) {
$topic_id = get_post_meta( $post_id, 'discourse_topic_id', true );
delete_transient( 'wpdc_comment_html_' . $topic_id );
}
}, 11 );
```
Por otro lado, ¿estás diciendo que esto funciona? 🤔
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [8 Julio, 2025 08:06 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/3 "2025-07-08T08:06:37Z")
Hola @Lee_Ars, ¿puedes confirmar primero que tienes configurado el webhook de comentarios?
> [@Configure WP Discourse Webhooks](https://meta.discourse.org/t/configure-wp-discourse-webhooks/311552#sync-comment-data-5):
>
> You can use webhooks to sync data between Discourse and WordPress, and enrich your integration. Reply to this topic if you have questions about how to setup the webhooks, or how they work. Setup WP Discourse First setup an endpoint in WP Discourse: Navigate to WP Discourse \> Webhooks in Wordpress admin. Select the endpoint(s) you want to enable (see below). Set a “Webhook Secret Key”, if it’s not already set. Click “Save Options”. Discourse Then create a new Webhook in Discourse (Go to /admi…
Eso funciona así:
1. Hay una nueva publicación en Discourse.
2. Se envía una carga útil de webhook a Wordpress.
3. [WP discourse](https://github.com/discourse/wp-discourse) actualiza el recuento de comentarios en la publicación y también establece un campo personalizado de publicación `wpdc_sync_post_comments`.
4. Si se establece `wpdc_sync_post_comments`, los comentarios de Discourse se sincronizarán cuando se cargue una publicación de Wordpress, independientemente del período de sincronización (es decir, el retraso de 10 minutos).
Antes de entrar en el tema del almacenamiento en caché, solo quiero asegurarme de que eso esté implementado primero. Si es así, quizás también activa los “Registros detallados de webhooks” y verifica que estás recibiendo solicitudes de webhook cuando se crea una nueva publicación en Discourse.
---
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [8 Julio, 2025 12:06 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/4 "2025-07-08T12:06:45Z")
> [@angus](#):
>
> Hola @Lee_Ars, ¿puedes confirmar primero que tienes configurado el webhook de comentarios?
¡Hola Angus! Eso es afirmativo, la opción de webhook “Sync Comment Data” está habilitada en el lado de WP, y creé el webhook en el lado de Discourse y los pings son exitosos. El registro del plugin de WP muestra mensajes `comment.INFO: sync_comments.success` en las marcas de tiempo correctas:
```plaintext
[2025-07-07 14:16:38] connection.INFO: check_connection_status.successful_connection
[2025-07-07 14:16:38] connection.INFO: check_connection_status.valid_scopes
[2025-07-07 20:11:31] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:25:03] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:32:14] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:44:15] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:00:39] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:01:42] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:15:40] comment.INFO: sync_comments.success {"post_id":786}
```
Es solo que, incluso con esos mensajes de éxito, los visitantes existentes (o al menos yo, probando repetidamente en Firefox/Safari/Chrome en un Mac, Firefox/Chrome/Edge en un PC con Win10 y Safari en iOS) siguen recibiendo un endpoint `/wp-json/wp-discourse/v1/discourse-comments` en caché, con encabezados `cache-control` establecidos en una cantidad distinta de cero. Si hago un ctrl-shift-f5 en Chrome (o el equivalente en otros navegadores) para forzar el bypass de la caché local al actualizar, todo funciona perfectamente y aparecen las nuevas publicaciones.
Con los mu-plugins en su lugar, ese endpoint muestra `cache-control` establecido en `no-store no-cache`, etc., y el comportamiento problemático no se manifiesta; simplemente visitar la publicación de WP o actualizarla con el botón de actualización normal muestra los nuevos comentarios incrustados.
He activado el registro detallado de webhooks y he publicado una publicación de prueba, y las cosas parecen estar bien cuando creo una nueva publicación:
```plaintext
webhook_topic.INFO: update_topic_content.update_post_metadata_success {"post_ids":"786"}
```
Todo _parece_ estar funcionando, pero todavía no entiendo realmente por qué se manifestó el comportamiento problemático original, o si surgió de algún problema pasado por alto de mi parte. (¡Muy posible!)
> [@RGJ](#):
>
> Hmm, estoy confundido de por qué esto funciona…
D’oh, lo siento, estoy seguro de que tienes razón en que lo arruiné, ayer fue un día largo y, como dije, estoy un poco al límite de mis capacidades aquí. Definitivamente estaba haciendo _algo_, aunque ahora me pregunto si el comportamiento “corregido” que estoy viendo es solo que está roto de una nueva manera. (¡He actualizado el plugin “transient killer” para usar el argumento correcto ahora, gracias!)
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [8 Julio, 2025 13:41 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/5 "2025-07-08T13:41:11Z")
Gracias, solo una cosa más para aclarar. ¿Está activada esta configuración de [WP Discourse](https://github.com/discourse/wp-discourse) (en “Comentar”)?
---
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [8 Julio, 2025 13:43 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/6 "2025-07-08T13:43:54Z")
He probado ambas opciones con la configuración `Cache Comment HTML` habilitada o deshabilitada y parece no tener ningún impacto en el comportamiento problemático. Actualmente la tengo deshabilitada, pero puedo configurarla como sea útil para la solución de problemas.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [8 Julio, 2025 14:56 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/7 "2025-07-08T14:56:31Z")
Si la configuración está desactivada, no notarás la confusión topic\_id / post\_id, ya que ese plugin no hace nada en ese caso. Sin caché → no importa si eliminas la caché incorrecta.
Si la configuración está activada, deberías notar que el plugin no funciona correctamente.
Es decir, si quieres solucionar problemas, deberías activar la configuración.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [8 Julio, 2025 15:56 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/8 "2025-07-08T15:56:58Z")
Ok, como primera medida para tu caso sugeriría:
1. mantener deshabilitado el HTML de comentarios de caché; y
2. eliminar el plugin `https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt` ya que actualmente no hace nada, como observa Richard.
Si eso no resuelve el problema, entonces el problema está relacionado con otra forma de caché. Las siguientes preguntas a responder son:
1. ¿Qué soluciones de caché utilizas tú (y/o tu proveedor de hosting) para Wordpress?
2. Si `https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt` soluciona el problema, ¿cómo invalida su comportamiento específico la caché que se está aplicando en el punto 1?
Mirando `wp-discourse-cache-header-fix` veo que una de las correcciones es para `load-comments.js`. ¿Tienes habilitada esta configuración?
---
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [8 Julio, 2025 17:32 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/9 "2025-07-08T17:32:36Z")
> [@angus](#):
>
> ¿Qué soluciones de caché utiliza usted (y/o su proveedor de alojamiento) para Wordpress?
Se trata de una instalación de WP autoalojada en nginx+php-fpm 8.3 con caché fast-cgi de nginx para contenido dinámico y caché de objetos Redis (con el drop-in de caché de objetos activo). No hay otras capas (sin CDN, sin CF, sin Varnish en el servidor u otra caché local más allá de la caché fast-cgi de nginx). Volcar la caché fast cgi de nginx (agresivamente, ejecutando `rm -rf /etc/nginx/cache/*`) no tiene ningún efecto en el comportamiento problemático: se sirven resultados obsoletos incluso después de borrar el directorio de caché y reiniciar tanto nginx como php-fpm.
De hecho, tengo activada la carga de comentarios Ajax en este momento, sí, pero de nuevo, desactivarla (y volcar la caché de nginx y reiniciar nginx y php-fpm por si acaso) no tuvo ningún efecto en el comportamiento problemático. Los navegadores seguían mostrando comentarios obsoletos.
> [@angus](#):
>
> Ok, así que como primera medida para su caso le sugeriría:
>
> 1. Mantener Cache Comment HTML deshabilitado; y
> 2. Eliminar el plugin [https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt](https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt) ya que actualmente no está haciendo nada, como observa Richard.
Opción cambiada, transient-killer eliminado. No hay cambios en el comportamiento del problema.
> [@angus](#):
>
> Si [https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt](https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt) soluciona el problema, ¿cómo invalida su comportamiento específico la caché (o las cachés) que se están aplicando en 1?
El efecto que aplica parece ser el suministro de una cabecera `cache-control` de no caché en lugar de una con un tiempo de caché especificado. Sin ella, mi navegador parece querer mucho servir una versión en caché obsoleta del endpoint `wp-json/wp-discourse/v1/discourse-comments` desde su caché de disco; como se mencionó, tengo que presionar shift-ctrl-f5 (o el equivalente) para forzar una actualización sin caché.
El comportamiento problemático parece estar en el lado del navegador, en lugar de en una caché persistente del servidor. Son todos los navegadores en todos los sistemas operativos a los que tengo acceso los que lo hacen.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [8 Julio, 2025 17:50 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/10 "2025-07-08T17:50:08Z")
Ok. Para que quede 100% claro. Cuando tienes
- Webhook de comentarios verificado y funcionando
- Caché de comentarios HTML desactivada
- Carga AJAX desactivada
- sin cdn
- sin cloudfront
- sin plugin de caché de wordpress
- sin advertencias o errores relevantes en los logs de php
¿estás seguro de que no funciona?
Si no funciona con esa configuración, me faltan opciones sin echar un vistazo más de cerca y optaría por
- Carga AJAX activada
- Tus correcciones de `wp-discourse-cache-header-fix.php`
que es lo que sospecho que te funcionaba. Si esa ruta funciona, deberías optar por ella.
---
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [8 Julio, 2025 18:05 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/11 "2025-07-08T18:05:54Z")
> [@angus](#):
>
> Ok, para que quede 100% claro, cuando tengas:
>
> - Webhook de comentarios funcionando y verificado
> - Caché de comentarios HTML desactivada
> - Carga AJAX desactivada
> - Sin CDN
> - Sin Cloudfront
> - Sin plugin de caché de WordPress
> - Sin advertencias o errores relevantes en los registros de PHP
[Aquí tienes una rápida galería de imgur](https://imgur.com/a/BQj2kRL) con capturas de pantalla de la configuración actual de mi plugin, como referencia.
Confirma que no hay CDN, ni Cloudfront ni Cloudflare, ni plugins de caché aparte del helper de Nginx (para ayudar a WP a invalidar la caché fast-cgi de nginx según sea necesario).
También confirma que no hay nada relevante en los registros de errores de php-fpm ni de nginx.
> [@](#):
>
> ¿estás seguro de que no funciona?
Dios, tío, ojalá lo estuviera. Llevo dándole vueltas a esto unas 30 horas, con algunos descansos para dormir. Puede que esté empezando a ver doble, jeje.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [8 Julio, 2025 18:21 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/12 "2025-07-08T18:21:07Z")
Sí, te entiendo. Tómate un descanso por un día o así. Intentaré recrear el problema mañana copiando tu configuración.
---
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [8 Julio, 2025 18:24 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/13 "2025-07-08T18:24:59Z")
Si no logro encontrar una solución por mi cuenta, y si te parece bien, estaré encantado de conceder acceso local temporal (al blog de WP, al discourse y/o a los hosts subyacentes) para la resolución de problemas. Definitivamente no estoy intentando conseguir mano de obra gratuita ni nada por el estilo. Estaría encantado de pagar por tus servicios si hay tiempo real que dedicar aquí.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [9 Julio, 2025 09:04 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/14 "2025-07-09T09:04:06Z")
Ok, aquí tienes un video mío intentando (y fallando) reproducir tu problema:
> **[Setting Up WordPress With Discourse Discussion Forum Software](https://us06web.zoom.us/clips/share/A3Nw_f0pSW67w_DfBkQRgQ)**
>
> I demonstrated how to set up a WordPress site to work with Discourse, a discussion forum software. I explained the process of publishing a post on WordPress, which triggers a webhook that sends a request to the WordPress-Discourse plugin. This plugin...
Lo siguiente que quiero que intentes es [este filtro](https://meta.discourse.org/t/wp-discourse-filters-and-actions/307211#p-1513119-wpdc_comment_sync_period-41).
> [@angus](#):
>
> #### wpdc\_comment\_sync\_period
>
> Establece el período de sincronización de los comentarios en segundos. Por defecto 600, es decir, 10 minutos.
>
> ##### Ejemplo
>
> Establece el período de sincronización a 5 minutos.
>
> ```plaintext
> function custom_comment_sync_period( $minutes, $post_id ) {
> return 300;
> }
> add_filter( 'wpdc_comment_sync_period', 'custom_comment_sync_period', 10, 2);
>
> ```
---
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [9 Julio, 2025 13:07 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/15 "2025-07-09T13:07:13Z")
Gracias @angus — que no se pueda reproducir en realidad me hace sentir mucho mejor, porque eso significa que estoy haciendo algo mal en lugar de que realmente _haya_ algo mal 😃
Añadiré ese filtro hoy cuando tenga un bloque de tiempo para solucionar problemas y te informaré 👍
---
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [12 Agosto, 2025 18:19 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/16 "2025-08-12T18:19:14Z")
Respondiendo un mes y pico después para cerrar el ciclo: todavía estoy experimentando algunas rarezas en el despliegue a producción completa ([sitio prod](https://spacecityweather.com), [ejemplo de publicación en sitio prod con incrustación de Discourse](https://spacecityweather.com/fairly-widespread-showers-likely-today-across-the-region/), [foro real de Discourse](https://discourse.spacecityweather.com)), pero todo es manejable. Voy a atribuir cualquier problema de latencia/retraso restante a la compleja capa de pastel que es Wordpress + Discourse + Cloudflare, y a mi agresiva estrategia de caché para mantener todas estas cosas operativas durante las tormentas de tráfico que resultan de tormentas reales.
Gracias por tomarte el tiempo de responder, @angus \<3
---
### Author:  [@Lee\_Ars](https://meta.discourse.org/u/Lee_Ars)
#### Post date: [4 Septiembre, 2025 13:40 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/17 "2025-09-04T13:40:21Z")
Disculpas por volver a subir esto, pero quería dar seguimiento e informar que ¡encontré la causa del problema! Y fue mi maldita culpa, como de costumbre.
Muy brevemente, guardo detalles comunes de bloques de ubicación de PHP en un fragmento en `/etc/nginx/snippets/` para poder incluirlos en múltiples archivos vhost sin tener que duplicarlos cada vez. Ha pasado mucho tiempo (años, probablemente) desde que revisé ese fragmento, y efectivamente, había un `add_header Cache-Control "public, max-age=7200";` espurio allí, que se aplicaba a todo lo que salía de ese bloque de ubicación.
Así que lo eliminé, vacié todas las capas de caché y, he aquí, el comportamiento problemático desapareció.
Gracias de nuevo por tomarte el tiempo de trabajar conmigo, @angus, aunque al final resultó ser nuevamente otro problema de Discourse hecho por mí 🫂
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [4 Octubre, 2025 13:40 UTC](https://meta.discourse.org/t/attempting-to-work-around-the-10-minute-delay/373254/18 "2025-10-04T13:40:55Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.