Essayer de contourner le délai de 10 minutes

[Lee_Ars]

Je prévois d’utiliser le plugin wp-discourse sur un site de prévisions météorologiques de la côte du Golfe qui dessert généralement environ 10 à 20 000 pages vues par jour, mais qui peut occasionnellement, lors d’événements météorologiques graves, atteindre 1,5 à 2 millions de pages vues par jour pour environ 500 à 700 000 visiteurs. Le site et sa stratégie d’hébergement ont été éprouvés lors de plusieurs événements météorologiques graves et fonctionnent parfaitement sous pression, principalement grâce à une conception soignée et à l’aide de Cloudflare.

Les utilisateurs du site sont habitués à une expérience de commentaires sans friction via les commentaires natifs de Wordpress, il y aura donc un certain ajustement (comme les habituer à cliquer sur le lien « Continuer la discussion sur… ») que le personnel chargé de l’interface utilisateur est prêt à gérer.

Cependant, ce qu’ils ne toléreront pas, c’est le délai variable de 10 minutes entre la publication des commentaires et leur affichage sur la page de l’article Wordpress du jour. Ils voudront que les nouveaux commentaires (jusqu’à la limite configurée) apparaissent immédiatement sur la page d’accueil dès leur publication, de la même manière que les commentaires WP natifs sont affichés immédiatement après leur publication.

Après avoir expérimenté avec les options intégrées pour essayer de faire apparaître les articles immédiatement sans que la mise en cache fastcgi de nginx, Wordpress ou la mise en cache du navigateur n’interfèrent avec l’apparition de nouveaux commentaires lors du rafraîchissement après leur publication, j’ai ajouté les deux mu-plugins suivants pour atténuer ce problème et faire en sorte que les commentaires nouvellement publiés apparaissent sur le côté Wordpress lors du rafraîchissement :

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

Cela a résolu mon problème : les nouveaux articles dans les fils Discourse créés par Wordpress apparaissent maintenant instantanément en dessous des articles Wordpress lors du rafraîchissement.

Mais je suis un peu à la limite de mes compétences ici – qu’est-ce que je casse/gâche/mine en faisant cela ?

Je ne me soucie pas particulièrement de créer une charge supplémentaire sur mon hébergeur en ayant le point de terminaison des commentaires martelé par les visiteurs qui consultent la page de prévisions météorologiques quotidiennes (avec ses commentaires Discourse intégrés) – c’est un problème que je peux résoudre en y consacrant de l’argent. Mon exigence principale est d’éviter que plus de 20 000 utilisateurs m’envoient des e-mails pour me demander pourquoi leurs commentaires n’apparaissent pas instantanément sur la page d’accueil lorsqu’ils les publient.

Est-ce la bonne approche ? Ce que je fais est-il judicieux ? Crée-t-il des problèmes de sécurité ou de performance supplémentaires que je n’ai pas anticipés ? En gros, est-ce que je gâche tout en faisant cela ?

Merci

[RGJ (Richard - Communiteq)]

Hmm, je ne comprends pas pourquoi cela fonctionne, car

@angus

L’action recevra les identifiants des articles Wordpress qui ont été mis à jour par le webhook comme argument, c’est-à-dire
do_action( 'wpdc_after_webhook_post_update', $post_ids );

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

Ne mélangez-vous pas les $post_id (Wordpress) passés à l’action avec le topic_id (Discourse) qui sert de clé de transient ?

Je m’attendrais à ce que votre plugin ressemble à ceci :

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’un autre côté, vous dites que cela fonctionne ?

[angus (Angus McLeod)]

Salut @Lee_Ars, peux-tu d’abord confirmer que tu as configuré le webhook des commentaires ?

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…

Cela fonctionne comme suit :

1. Il y a un nouveau message dans Discourse.
2. Une charge utile de webhook est envoyée à Wordpress.
3. WP discourse met à jour le nombre de commentaires sur le message et définit également un champ personnalisé du message wpdc_sync_post_comments.
4. Si wpdc_sync_post_comments est défini, les commentaires Discourse seront synchronisés lorsqu’un message Wordpress sera chargé, quelle que soit la période de synchronisation (c’est-à-dire le délai de 10 minutes).

Avant de nous pencher sur la mise en cache, je veux juste m’assurer que cela est en place. Si c’est le cas, active peut-être aussi les « Journaux de webhook détaillés » et vérifie que tu reçois des requêtes de webhook lorsqu’un nouveau message est créé dans Discourse.

[Lee_Ars]

@angus

Salut @Lee_Ars, peux-tu d’abord confirmer que tu as configuré le webhook pour les commentaires ?

Salut Angus ! C’est affirmatif, l’option de webhook “Sync Comment Data” est activée côté WP, et j’ai créé le webhook côté Discourse et les pings sont réussis. Le journal du plugin WP affiche des messages comment.INFO: sync_comments.success aux bons horodatages :

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

C’est juste que même avec ces messages de succès, les visiteurs existants (ou du moins moi, testant à plusieurs reprises sur Firefox/Safari/Chrome sur un Mac, Firefox/Chrome/Edge sur un PC Win10, et Safari sur iOS) continuent de recevoir un point de terminaison /wp-json/wp-discourse/v1/discourse-comments mis en cache, avec des en-têtes cache-control définis sur une valeur non nulle. Si je fais un ctrl-shift-f5 sur Chrome (ou l’équivalent dans d’autres navigateurs) pour forcer le contournement du cache local lors du rechargement, tout fonctionne parfaitement et les nouveaux messages apparaissent.

Avec les mu-plugins en place, ce point de terminaison affiche cache-control défini sur no-store no-cache etc., et le comportement problématique ne se manifeste pas — simplement visiter le message WP ou le rafraîchir avec le bouton de rafraîchissement normal affiche les nouveaux commentaires intégrés.

J’ai activé la journalisation détaillée des webhooks et posté un message de test, et les choses semblent correctes lorsque je crée un nouveau message :

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

Tout semble fonctionner, mais je ne comprends toujours pas vraiment pourquoi le comportement problématique d’origine s’est manifesté, ou s’il provient d’un problème négligé de mon côté. (Très possible !)

@RGJ

Hmm, je suis confus pourquoi cela fonctionne…

D’oh, désolé, je suis sûr que tu as raison sur le fait que j’ai foiré ça — hier a été une longue journée, et comme je l’ai dit, je suis un peu à la limite de mes capacités ici. Cela faisait certainement quelque chose, bien que maintenant je me demande si le comportement “corrigé” que je vois n’est qu’une nouvelle façon de le casser. (J’ai mis à jour le plugin “transient killer” pour utiliser le bon argument maintenant, merci !)

[angus (Angus McLeod)]

Merci, juste une dernière chose à clarifier. Ce réglage WP Discourse (dans « Commentaires ») est-il activé ?

[Lee_Ars]

J’ai essayé avec le paramètre Cache Comment HTML activé ou désactivé et cela ne semble avoir aucun impact sur le comportement problématique. Je l’ai actuellement désactivé, mais je peux le définir sur ce qui serait utile pour le dépannage.

[RGJ (Richard - Communiteq)]

Si le paramètre est désactivé, vous ne remarquerez pas la confusion topic_id / post_id, car ce plugin ne fait rien dans ce cas. Pas de mise en cache → peu importe si vous supprimez le mauvais cache.

Si le paramètre est activé, alors vous devriez remarquer que le plugin ne fonctionne pas correctement.

Autrement dit, si vous voulez dépanner, vous devriez activer le paramètre.

[angus (Angus McLeod)]

Ok, donc comme première mesure pour votre cas, je suggérerais :

1. de désactiver le cache des commentaires HTML ; et
2. de supprimer le plugin https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt car il ne fait actuellement rien, comme l’observe Richard.

Si cela ne résout pas le problème, alors le problème est lié à une autre forme de mise en cache. Les prochaines questions à répondre sont :

1. Quelles solutions de mise en cache utilisez-vous (et/ou votre hébergeur) pour Wordpress ?
2. Si https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt résout le problème, comment son comportement spécifique invalide-t-il le(s) cache(s) appliqué(s) en 1 ?

En regardant wp-discourse-cache-header-fix, je vois que l’une des corrections concerne load-comments.js. Avez-vous ce paramètre activé ?

[Lee_Ars]

@angus

Quelles solutions de mise en cache utilisez-vous (et/ou votre fournisseur d’hébergement) pour Wordpress ?

Il s’agit d’une installation WP auto-hébergée sur nginx+php-fpm 8.3 avec la mise en cache fast-cgi de nginx pour le contenu dynamique et la mise en cache d’objets Redis (avec le dépôt de cache d’objets actif). Il n’y a pas d’autres couches (pas de CDN, pas de CF, pas de Varnish sur la machine ou autre cache local au-delà du cache fast-cgi de nginx). Vider le cache fast cgi de nginx (agressivement, en faisant rm -rf /etc/nginx/cache/*) n’a aucun effet sur le comportement problématique — des résultats obsolètes sont servis même après avoir vidé le répertoire de cache et redémarré nginx et php-fpm.

J’ai bien activé le chargement des commentaires Ajax en ce moment, oui, mais encore une fois, le désactiver (et vider le cache de nginx plus redémarrer nginx et php-fpm au cas où) n’a eu aucun effet sur le comportement problématique. Les navigateurs continuaient de servir des commentaires obsolètes.

@angus

Ok, donc comme première mesure pour votre cas, je suggérerais :

1. de garder Cache Comment HTML désactivé ; et
2. de supprimer le plugin https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt car il ne fait actuellement rien, comme le fait remarquer Richard.

Option basculée, transient-killer supprimé. Aucun changement dans le comportement problématique.

@angus

Si https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt résout le problème, comment son comportement spécifique invalide-t-il le(s) cache(s) appliqué(s) en 1 ?

L’effet qu’il applique semble être de fournir un en-tête cache-control de type no-cache au lieu d’un en-tête avec une durée de cache spécifiée. Sans lui, mon navigateur semble très enclin à servir une version mise en cache obsolète du point d’accès wp-json/wp-discourse/v1/discourse-comments depuis son cache disque ; comme mentionné, je dois faire Shift-Ctrl-F5 (ou l’équivalent) pour forcer un rafraîchissement sans cache.

Le comportement problématique semble se situer du côté du navigateur, plutôt que dans un cache serveur persistant. Ce sont juste tous les navigateurs sur tous les systèmes d’exploitation auxquels j’ai accès qui font cela.

[angus (Angus McLeod)]

Ok. Juste pour être sûr à 100%. Lorsque vous avez

• Webhook de commentaires fonctionnel vérifié
• Cache HTML des commentaires désactivé
• Chargement AJAX désactivé
• pas de CDN
• pas de CloudFront
• pas de plugin de mise en cache WordPress
• pas d’avertissements ou d’erreurs pertinents dans les journaux PHP

vous êtes sûr que cela ne fonctionne pas ?

Si cela ne fonctionne pas avec cette configuration, je suis un peu perdu sans y regarder de plus près et je recommanderais par défaut

• Chargement AJAX activé
• Vos correctifs wp-discourse-cache-header-fix.php

ce qui, je suppose, fonctionnait pour vous. Si cette voie fonctionne, alors vous devriez opter pour celle-ci.

[Lee_Ars]

@angus

Ok, juste pour être sûr à 100%, quand vous avez :

• webhook de commentaire fonctionnel vérifié
• Cache HTML des commentaires désactivé
• Chargement AJAX désactivé
• pas de cdn
• pas de cloudfront
• pas de plugin de cache wordpress
• pas d’avertissements ou d’erreurs pertinents dans les logs php

Voici une rapide galerie imgur de captures d’écran de mes paramètres de plugin actuels, à titre de référence.

Confirmez qu’il n’y a pas de CDN, pas de Cloudfront ou de Cloudflare, aucun des deux, pas de plugins de cache à part le helper Nginx (pour aider WP à invalider le cache fast-cgi nginx si nécessaire).

Confirmez également qu’il n’y a rien de pertinent dans les logs d’erreurs php-fpm ou nginx.

vous êtes sûr que ça ne fonctionne pas ?

Dieu, mec, j’aimerais que ce soit le cas. Je me suis arraché les cheveux là-dessus pendant environ 30 heures à ce stade, avec quelques pauses pour dormir. Je deviens peut-être un peu fou, héh.

[angus (Angus McLeod)]

Ouais, je te comprends. Prends une pause d’un jour ou deux. J’essaierai de recréer le problème demain en copiant ta configuration.

[Lee_Ars]

Si je ne trouve pas de solution par mes propres moyens, et si vous le souhaitez, je serais heureux de vous accorder un accès local temporaire (au blog WP, au discourse et/ou aux hôtes sous-jacents) pour le dépannage. Je n’essaie certainement pas d’obtenir du travail gratuit ou quoi que ce soit. Je serais heureux de payer pour vos services s’il y a du temps réel à consacrer ici.

[angus (Angus McLeod)]

Ok, voici une vidéo de moi essayant (et échouant) de reproduire votre problème :

Setting Up WordPress With Discourse Discussion Forum Software

La prochaine chose que je veux que vous essayiez est ce filtre.

@angus

wpdc_comment_sync_period

Définit la période de synchronisation des commentaires en secondes. Par défaut 600, soit 10 minutes.

Exemple

Définit la période de synchronisation à 5 minutes.

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

[Lee_Ars]

Merci @angus — le fait que la reproduction échoue me rassure beaucoup, car cela signifie que je fais quelque chose de mal plutôt qu’il y ait réellement quelque chose qui ne va pas

J’ajouterai ce filtre aujourd’hui lorsque j’aurai un moment pour le dépannage et je vous ferai un retour

[Lee_Ars]

Répondant un mois et quelques jours plus tard pour clore la boucle — je rencontre toujours des bizarreries lors du déploiement en production complète (site prod, exemple de post prod avec embed discourse, forum discourse actuel), mais tout est gérable. Je vais attribuer les problèmes de latence/retard restants à la complexe superposition de Wordpress + Discourse + Cloudflare, et à ma stratégie de mise en cache agressive pour maintenir toutes ces choses opérationnelles pendant les pics de trafic résultant de tempêtes réelles.

Merci d’avoir pris le temps de répondre, @angus <3

[Lee_Ars]

Mes excuses pour avoir déterré ce sujet encore une fois, mais je voulais faire un suivi et signaler que j’ai trouvé la cause du problème ! Et c’était de ma faute, comme d’habitude.

Très brièvement, je conserve les détails courants des blocs de localisation PHP dans un extrait sous /etc/nginx/snippets/ afin de pouvoir les inclure dans plusieurs fichiers vhost sans avoir à les dupliquer à chaque fois. Cela faisait très longtemps (des années, probablement) que je n’avais pas vérifié cet extrait, et bien sûr, il y avait un add_header Cache-Control \"public, max-age=7200\"; superflu, qui était appliqué à tout ce qui sortait de ce bloc de localisation.

Je l’ai donc supprimé, vidé toutes les couches de cache, et miracle, le comportement problématique a disparu.

Merci encore d’avoir pris le temps de travailler avec moi, @angus, même si cela s’est avéré être encore une fois un autre problème de Discourse que j’ai causé moi-même

[system (system) A fermé ce sujet ()]

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.