Tentativo di aggirare il ritardo di 10 minuti

[Lee_Ars]

Sto pianificando di utilizzare il plugin wp-discourse su un sito di previsioni meteorologiche della costa del Golfo che in genere gestisce circa 10-20.000 visualizzazioni di pagine al giorno, ma occasionalmente, durante eventi meteorologici gravi, raggiunge 1,5-2 milioni di visualizzazioni di pagine al giorno per circa 500-700.000 visitatori. Il sito e la sua strategia di hosting sono stati testati sul campo in diversi eventi meteorologici gravi e funzionano benissimo sotto pressione, principalmente grazie a un’attenta progettazione e all’aiuto di Cloudflare.

Gli utenti del sito sono abituati a un’esperienza di commento a basso attrito tramite i commenti nativi di Wordpress, quindi ci sarà un certo adattamento (come abituarli a fare clic sul link “Continua la discussione su…”) che il personale di front-end è pronto a gestire.

Tuttavia, ciò che non tollereranno è il ritardo variabile di 10 minuti tra la pubblicazione dei commenti e la loro visualizzazione sulla pagina del post giornaliero di Wordpress. Vorranno che i nuovi commenti (fino al limite configurato) appaiano immediatamente sulla homepage al momento della pubblicazione, in modo simile a come i commenti nativi di WP vengono visualizzati immediatamente dopo la pubblicazione.

Dopo aver armeggiato con le opzioni integrate per cercare di far apparire i post immediatamente senza che la cache fastcgi di nginx, Wordpress o la cache del browser interferiscano con la visualizzazione dei nuovi commenti al refresh dopo che sono stati pubblicati, ho aggiunto i seguenti due mu-plugins per mitigare questo problema e far sì che i commenti appena pubblicati vengano visualizzati sul lato Wordpress al refresh:

wp-discourse-transient-killer.php
wp-discourse-cache-header-fix.php

Questo ha risolto il mio problema: i nuovi post nei thread di Discourse creati da Wordpress ora appaiono sotto i post di Wordpress istantaneamente al refresh.

Ma sono al limite delle mie competenze qui: cosa sto rompendo/rovinando/minando facendo questo?

Non mi preoccupa particolarmente creare un carico aggiuntivo sul mio webhost facendo sì che l’endpoint dei commenti venga martellato dai visitatori che controllano la pagina delle previsioni meteorologiche giornaliere (con i suoi commenti Discourse incorporati) — questo è un problema che posso risolvere spendendo soldi. Il mio requisito principale è evitare che oltre 20.000 utenti mi inviino email chiedendomi perché i loro commenti non appaiono istantaneamente sulla homepage quando li pubblicano.

Questo è l’approccio giusto? Quello che sto facendo è saggio? Crea problemi di sicurezza o prestazioni aggiuntivi che non ho previsto? In sostanza, sto rovinando le cose facendo questo?

Grazie

[RGJ (Richard - Communiteq)]

Hmm, sono confuso sul perché questo funzioni, perché

@angus

L’azione riceverà gli ID dei post di Wordpress che sono stati aggiornati dal webhook come argomento, cioè
do_action( 'wpdc_after_webhook_post_update', $post_ids );

E il tuo plugin

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 );

Non stai confondendo gli $post_id (di Wordpress) passati all’azione con il topic_id (di Discourse) che funge da chiave per il transient?

Mi aspetterei che il tuo plugin fosse così:

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 );

D’altra parte, stai dicendo che questo funziona?

[angus (Angus McLeod)]

Ciao @Lee_Ars, puoi prima confermare che hai configurato il webhook dei commenti?

Configure WP Discourse Webhooks

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…

Funziona così:

1. C’è un nuovo post in Discourse.
2. Un payload webhook viene inviato a Wordpress.
3. WP discourse aggiorna il conteggio dei commenti sul post e imposta anche un campo personalizzato del post wpdc_sync_post_comments.
4. Se wpdc_sync_post_comments è impostato, i commenti di Discourse verranno sincronizzati quando viene caricato un post di Wordpress, indipendentemente dal periodo di sincronizzazione (cioè il ritardo di 10 minuti).

Prima di entrare nella cache, voglio solo assicurarmi che sia tutto a posto. Se lo è, forse puoi anche attivare “Verbose Webhook Logs” e verificare che tu stia ricevendo richieste webhook quando viene creato un nuovo post in Discourse.

[Lee_Ars]

@angus

Ciao @Lee_Ars, puoi prima confermare che hai configurato il webhook per i commenti?

Ciao Angus! È affermativo, l’opzione webhook “Sync Comment Data” è abilitata sul lato WP, e ho creato il webhook sul lato Discourse e i ping hanno successo. Il logging del plugin WP mostra messaggi comment.INFO: sync_comments.success ai timestamp corretti:

[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}

È solo che, anche con questi messaggi di successo, i visitatori esistenti (o almeno io, testando più volte su Firefox/Safari/Chrome su un Mac, Firefox/Chrome/Edge su un PC Win10 e Safari su iOS) continuano a ricevere un endpoint /wp-json/wp-discourse/v1/discourse-comments memorizzato nella cache, con header cache-control impostati su un valore non nullo. Se faccio un ctrl-shift-f5 su Chrome (o l’equivalente in altri browser) per forzare l’aggiornamento bypassando la cache locale, tutto funziona alla grande e i nuovi post appaiono.

Con i mu-plugins in atto, quell’endpoint mostra cache-control impostato su no-store no-cache ecc., e il comportamento problematico non si manifesta: semplicemente visitando il post WP o aggiornandolo con il normale pulsante di aggiornamento mostra i nuovi commenti incorporati.

Ho attivato il logging dettagliato dei webhook e ho pubblicato un post di prova, e le cose sembrano a posto quando creo un nuovo post:

webhook_topic.INFO: update_topic_content.update_post_metadata_success {"post_ids":"786"}

Tutto sembra funzionare, ma ancora non capisco bene perché si sia manifestato il comportamento problematico originale, o se sia sorto da qualche problema trascurato da parte mia. (Molto possibile!)

@RGJ

Hmm sono confuso sul perché questo funzioni…

D’oh, scusa, sono sicuro che hai ragione sul fatto che l’ho combinata grossa io — ieri è stata una lunga giornata, e come ho detto, sono un po’ al limite delle mie capacità qui. Stava sicuramente facendo qualcosa, anche se ora mi chiedo se il comportamento “corretto” che sto vedendo sia solo che è rotto in un modo nuovo. (Ho aggiornato il plugin “transient killer” per usare l’argomento giusto ora, grazie!)

[angus (Angus McLeod)]

Grazie, quindi solo un’altra cosa da chiarire. Questa impostazione di WP Discourse (in “Commenti”) è attiva?

[Lee_Ars]

Ho provato sia con l’impostazione Cache Comment HTML abilitata che disabilitata e sembra non avere alcun impatto sul comportamento del problema. Al momento l’ho disabilitata, ma posso impostarla su qualsiasi valore utile per la risoluzione dei problemi.

[RGJ (Richard - Communiteq)]

Se l’impostazione è disabilitata, non noterai il mixup topic_id / post_id, poiché quel plugin non fa nulla in quel caso. Nessuna cache –

non importa se elimini la cache sbagliata.

Se l’impostazione è abilitata, dovresti notare che il plugin non funziona correttamente.

Cioè, se vuoi risolvere i problemi, dovresti abilitare l’impostazione.

[angus (Angus McLeod)]

Ok, come prima misura per il tuo caso suggerirei:

1. mantenere disabilitato Cache Comment HTML; e
2. rimuovere il plugin https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt poiché, come osserva Richard, attualmente non fa nulla.

Se ciò non risolve il problema, allora il problema è legato a un’altra forma di caching. Le prossime domande a cui rispondere sono:

1. Quali soluzioni di caching utilizzate (tu e/o il tuo provider di hosting) per Wordpress?
2. Se https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt risolve il problema, in che modo il suo comportamento specifico invalida la cache (o le cache) applicata/e al punto 1?

Guardando wp-discourse-cache-header-fix vedo che una delle correzioni riguarda load-comments.js. Hai questa impostazione abilitata?

[Lee_Ars]

@angus

Quali soluzioni di caching utilizzate (tu e/o il tuo provider di hosting) per Wordpress?

Si tratta di WP self-hosted su nginx+php-fpm 8.3 con caching fast-cgi di nginx per contenuti dinamici e caching di oggetti Redis (con il drop-in object cache attivo). Non ci sono altri livelli (nessuna CDN, nessun CF, nessun Varnish on-box o altra cache locale oltre alla cache fast-cgi di nginx). Scaricare la cache fast cgi di nginx (aggressivamente, andando su rm -rf /etc/nginx/cache/*) non ha alcun effetto sul comportamento problematico: vengono serviti risultati obsoleti anche dopo aver svuotato la directory della cache e riavviato sia nginx che php-fpm.

Ho effettivamente abilitato il caricamento dei commenti Ajax in questo momento, sì, ma di nuovo, disattivarlo (e scaricare la cache di nginx più riavviare nginx e php-fpm per sicurezza) non ha avuto alcun effetto sul comportamento problematico. I browser continuavano a ricevere commenti obsoleti.

@angus

Ok, quindi come prima misura per il tuo caso suggerirei:

1. mantenere Cache Comment HTML disabilitato; e
2. rimuovere il plugin https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt poiché attualmente non sta facendo nulla, come osserva Richard.

Opzione disattivata, transient-killer rimosso. Nessun cambiamento nel comportamento problematico.

@angus

Se https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt risolve il problema, in che modo il suo comportamento specifico invalida la cache (o le cache) applicata in 1?

L’effetto che applica sembra essere la fornitura di un header cache-control no-cache invece di uno con un tempo di cache specificato. Senza di esso, il mio browser sembra voler molto servire una versione memorizzata nella cache obsoleta dell’endpoint wp-json/wp-discourse/v1/discourse-comments dalla sua cache del disco; come notato, devo premere shift-ctrl-f5 (o l’equivalente) per forzare un aggiornamento no-cache.

Il comportamento problematico sembra essere lato browser, piuttosto che in una cache persistente lato server. Sono solo tutti i browser su tutti i sistemi operativi a cui ho accesso che lo stanno facendo.

[angus (Angus McLeod)]

Ok. Giusto per essere sicuro al 100%. Quando hai

• Webhook dei commenti funzionante e verificato
• Cache HTML dei commenti disattivata
• Caricamento AJAX disattivato
• nessuna CDN
• nessun CloudFront
• nessun plugin di caching di WordPress
• nessun avviso o errore pertinente nei log PHP

sei sicuro che non funzioni?

Se non funziona con quella configurazione, sono un po’ a corto di idee senza un’analisi più approfondita e opterei per

• Caricamento AJAX attivato
• Le correzioni del tuo wp-discourse-cache-header-fix.php

che è ciò che sospetto stesse funzionando per te. Se quella soluzione funziona, allora dovresti procedere con quella.

[Lee_Ars]

@angus

Ok, giusto per essere sicuro al 100%, quando hai:

• webhook dei commenti funzionante verificato
• Cache Comment HTML disattivata
• AJAX Loading disattivato
• nessun cdn
• nessun cloudfront
• nessun plugin di caching di wordpress
• nessun avviso o errore pertinente nei log php

Ecco una rapida galleria imgur di screenshot delle mie attuali impostazioni del plugin, come riferimento.

Conferma nessun CDN, nessun Cloudfront o Cloudflare nessuno dei due, nessun plugin di caching a parte l’helper Nginx (per aiutare WP a invalidare la cache fast-cgi di nginx secondo necessità).

Conferma anche che non c’è nulla di pertinente nei log di errore php-fpm o nginx.

sei sicuro che non funzioni?

Dio, amico, vorrei che fosse così. Ci sto sbattendo la testa da circa 30 ore, con qualche pausa per dormire. Potrei star diventando un po’ strabico, eh.

[angus (Angus McLeod)]

Sì, ti capisco. Prenditi una pausa per un giorno o giù di lì. Cercherò di ricreare il problema domani copiando la tua configurazione.

[Lee_Ars]

Se non riesco a trovare una soluzione, e se vuoi, sarei felice di concedere un accesso locale temporaneo (al blog WP, al forum e/o agli host sottostanti) per la risoluzione dei problemi. Non sto certo cercando lavoro gratuito o altro. Sarei felice di pagare per i tuoi servizi se c’è del tempo effettivo da dedicare qui.

[angus (Angus McLeod)]

Ok, ecco un video di me che provo (e fallisco) a riprodurre il tuo problema:

Setting Up WordPress With Discourse Discussion Forum Software

La prossima cosa che voglio che tu provi è questo filtro.

@angus

wpdc_comment_sync_period

Imposta il periodo di sincronizzazione per i commenti in secondi. Predefinito 600, ovvero 10 minuti.

Esempio

Imposta il periodo di sincronizzazione a 5 minuti.

function custom_comment_sync_period( $minutes, $post_id ) {
  return 300;
}
add_filter( 'wpdc_comment_sync_period', 'custom_comment_sync_period', 10, 2);

[Lee_Ars]

Grazie @angus — il fatto che non riesca a riprodurre l’errore mi fa sentire molto meglio, perché significa che sto facendo qualcosa di sbagliato piuttosto che ci sia effettivamente qualcosa che non va

Aggiungerò quel filtro oggi quando avrò un po’ di tempo per il troubleshooting e ti farò sapere

[Lee_Ars]

Rispondo un mese e spiccioli dopo per chiudere il cerchio: sto ancora riscontrando qualche stranezza nel deployment in produzione completa (sito prod, esempio post sito prod con embed discourse, forum discourse effettivo), ma è tutto gestibile. Attribuisco eventuali problemi di latenza/ritardo residui alla complessa torta a strati che è Wordpress + Discourse + Cloudflare, e alla mia aggressiva strategia di caching per mantenere operative tutte queste cose durante le tempeste di traffico che derivano da tempeste reali.

Grazie per aver dedicato del tempo a rispondere, @angus <3

[Lee_Ars]

Mi scuso per aver ripreso questo argomento ancora, ma volevo dare un seguito e segnalare che ho trovato la causa del problema! E come al solito, è stata colpa mia.

Molto brevemente, conservo i dettagli comuni dei blocchi di posizione PHP in uno snippet sotto /etc/nginx/snippets/ in modo da poterli includere in più file vhost senza doverli duplicare ogni volta. È passato un sacco di tempo (anni, probabilmente) da quando ho controllato quello snippet, e infatti, c’era un add_header Cache-Control \"public, max-age=7200\"; spurio lì dentro, che veniva applicato a tutto ciò che usciva da quel blocco di posizione.

Quindi l’ho rimosso, ho svuotato tutti gli strati della cache e, guarda caso, il comportamento problematico è scomparso.

Grazie ancora per aver dedicato del tempo a lavorare con me, @angus, anche se alla fine si è rivelato ancora una volta un altro problema di Discourse causato da me