Tentando contornar o atraso de 10 minutos

[Lee_Ars]

Estou planejando usar o plugin wp-discourse em um site de previsão do tempo da costa do Golfo que normalmente atende a cerca de 10 a 20 mil visualizações de página por dia, mas ocasionalmente, durante eventos climáticos severos, pode atingir 1,5 a 2 milhões de visualizações de página por dia para aproximadamente 500 a 700 mil visitantes. O site e sua estratégia de hospedagem foram testados em vários eventos climáticos severos e funcionam bem sob pressão, principalmente graças a um design cuidadoso e muita ajuda do Cloudflare.

Os usuários do site estão acostumados a uma experiência de comentários de baixo atrito por meio dos comentários nativos do WordPress, portanto, haverá algum ajuste (como acostumá-los a clicar no link “Continuar a discussão em…”) que a equipe de atendimento ao público está pronta para gerenciar.

No entanto, o que eles não tolerarão é o atraso variável de 10 minutos entre a postagem de comentários e sua exibição na página da postagem diária do WordPress. Eles desejarão que novos comentários (até o limite configurado) apareçam imediatamente na página inicial após a postagem, de forma semelhante a como os comentários nativos do WP são exibidos imediatamente após a postagem.

Depois de mexer nas opções integradas para tentar fazer com que as postagens aparecessem imediatamente sem o cache fastcgi do nginx, o WordPress ou o cache do navegador interferindo no aparecimento de novos comentários ao atualizar após serem postados, adicionei os dois seguintes mu-plugins para mitigar isso e fazer com que os comentários recém-postados apareçam no lado do WordPress na atualização:

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

Isso resolveu meu problema: novas postagens em threads do Discourse criadas pelo WordPress agora aparecem abaixo das postagens do WordPress instantaneamente na atualização.

Mas estou no limite da minha competência aqui — o que estou quebrando/estragando/minando ao fazer isso?

Não me importo particularmente em criar carga adicional em meu servidor web com o endpoint de comentários sendo bombardeado por visitantes que verificam a página de previsão do tempo diária (com seus comentários incorporados do Discourse) — esse é um problema que posso resolver gastando dinheiro com isso. Meu requisito principal é evitar que mais de 20.000 usuários me enviem e-mails perguntando por que seus comentários não estão aparecendo instantaneamente na página inicial quando os postam.

Essa é a abordagem correta? O que estou fazendo é sensato? Isso cria problemas adicionais de segurança ou desempenho que não antecipei? Basicamente, estou estragando tudo ao fazer isso?

Obrigado

[RGJ (Richard - Communiteq)]

Hmm, estou confuso sobre por que isso funciona, porque

@angus

A ação receberá os IDs dos posts do Wordpress que foram atualizados pelo webhook como um argumento, ou seja,
do_action( 'wpdc_after_webhook_post_update', $post_ids );

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

Você não está misturando os $post_ids (Wordpress) passados para a ação com o topic_id (Discourse) que serve como chave do transient?

Eu esperaria que seu plugin se parecesse com isto

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 outro lado, você está dizendo que isso funciona?

[angus (Angus McLeod)]

Olá @Lee_Ars, você pode primeiro confirmar que tem o webhook de comentários configurado?

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…

Isso funciona assim:

1. Há uma nova postagem no Discourse.
2. Uma carga útil de webhook é enviada para o Wordpress.
3. O WP discourse atualiza a contagem de comentários na postagem e também define um campo personalizado de postagem wpdc_sync_post_comments.
4. Se wpdc_sync_post_comments estiver definido, os comentários do Discourse serão sincronizados quando uma postagem do Wordpress for carregada, independentemente do período de sincronização (ou seja, o atraso de 10 minutos).

Antes de entrarmos em caching, quero ter certeza de que isso está configurado primeiro. Se estiver, talvez também ative “Registros de Webhook Verbosos” e verifique se você está recebendo solicitações de webhook quando uma nova postagem é feita no Discourse.

[Lee_Ars]

@angus

Olá @Lee_Ars, você pode primeiro confirmar que configurou o webhook de comentários?

Olá Angus! Isso é afirmativo, a opção de webhook “Sync Comment Data” está habilitada no lado do WP, e eu criei o webhook no lado do Discourse e os pings são bem-sucedidos. O log do plugin WP mostra mensagens comment.INFO: sync_comments.success nos momentos certos:

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

É apenas que, mesmo com essas mensagens de sucesso, visitantes existentes (ou pelo menos eu, testando várias vezes no Firefox/Safari/Chrome em um Mac, Firefox/Chrome/Edge em um PC com Win10 e Safari no iOS) continuam recebendo um endpoint /wp-json/wp-discourse/v1/discourse-comments em cache, com cabeçalhos cache-control definidos para um valor não zero. Se eu fizer um ctrl-shift-f5 no Chrome (ou o equivalente em outros navegadores) para forçar a ignorar o cache local ao recarregar, tudo funciona bem e as novas postagens aparecem.

Com os mu-plugins implementados, esse endpoint mostra cache-control definido como no-store no-cache etc., e o comportamento problemático não se manifesta — simplesmente visitar a postagem do WP ou recarregá-la com o botão de recarregar normal mostra novos comentários incorporados.

Eu ativei o log detalhado do webhook e postei uma postagem de teste, e as coisas parecem OK quando crio uma nova postagem:

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

Tudo parece estar funcionando, mas ainda não entendo realmente por que o comportamento problemático original se manifestou, ou se ele surgiu de algum problema negligenciado do meu lado. (Muito possível!)

@RGJ

Hmm, estou confuso por que isso funciona…

D’oh, desculpe, tenho certeza que você está certo sobre eu ter estragado isso — ontem foi um dia longo e, como eu disse, estou meio que no limite das minhas habilidades aqui. Definitivamente estava fazendo algo, embora agora eu esteja me perguntando se o comportamento “corrigido” que estou vendo é apenas ele estar quebrado de uma nova maneira. (Já atualizei o plugin “transient killer” para usar o argumento correto agora, obrigado!)

[angus (Angus McLeod)]

Obrigado, então só mais uma coisa para esclarecer. Essa configuração do WP Discourse (em "Comentários") está ativada?

[Lee_Ars]

Eu tentei com a configuração Cache Comment HTML ativada ou desativada e parece não ter impacto no comportamento do problema. Atualmente, estou com ela desativada, mas posso configurá-la para o que for útil para solução de problemas.

[RGJ (Richard - Communiteq)]

Se a configuração estiver desativada, você não notará a confusão entre topic_id / post_id, pois esse plugin não faz nada nesse caso. Sem cache –

não importa se você excluir o cache errado.

Se a configuração estiver ativada, você deverá notar que o plugin não funciona corretamente.

Ou seja, se você quiser solucionar problemas, deverá ativar a configuração.

[angus (Angus McLeod)]

Ok, como primeira medida para o seu caso, eu sugeriria:

1. manter o Cache Comment HTML desativado; e
2. remover o plugin https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt, pois ele atualmente não está fazendo nada, como Richard observa.

Se isso não resolver o problema, então o problema está relacionado a outra forma de cache. As próximas perguntas a serem respondidas são:

1. Quais soluções de cache você (e/ou seu provedor de hospedagem) usam para o WordPress?
2. Se https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt corrigir o problema, como o comportamento específico dele invalida qualquer cache que esteja sendo aplicado em 1?

Olhando para wp-discourse-cache-header-fix, vejo que uma das correções é para load-comments.js. Você tem essa configuração ativada?

[Lee_Ars]

@angus

Quais soluções de cache você (e/ou seu provedor de hospedagem) usam para o WordPress?

Este é um WP auto-hospedado em nginx+php-fpm 8.3 com cache fast-cgi do nginx para conteúdo dinâmico e cache de objetos Redis (com o drop-in do cache de objetos ativo). Não há outras camadas (sem CDN, sem CF, sem Varnish na máquina ou outro cache local além do cache fast-cgi do nginx). Despejar o cache fast cgi do nginx (agressivamente, executando rm -rf /etc/nginx/cache/*) não tem efeito no comportamento problemático — resultados desatualizados são servidos mesmo após limpar o diretório de cache e reiniciar o nginx e o php-fpm.

Eu tenho o carregamento de comentários Ajax habilitado no momento, sim, mas novamente, desativá-lo (e despejar o cache do nginx e reiniciar o nginx e o php-fpm apenas por precaução) não teve efeito no comportamento problemático. Os navegadores ainda recebiam comentários desatualizados.

@angus

Ok, então como uma primeira medida para o seu caso, eu sugeriria:

1. manter o Cache Comment HTML desabilitado; e
2. remover o plugin https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt, pois ele atualmente não está fazendo nada, como Richard observa.

Opção alternada, transient-killer removido. Nenhuma mudança no comportamento problemático.

@angus

Se https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt corrigir o problema, como o seu comportamento específico invalida qualquer cache que esteja sendo aplicado em 1?

O efeito que ele aplica parece ser o fornecimento de um cabeçalho cache-control de no-cache em vez de um com um tempo de cache especificado. Sem ele, meu navegador parece querer muito servir uma versão em cache desatualizada do endpoint wp-json/wp-discourse/v1/discourse-comments de seu cache de disco; como observado, tenho que pressionar shift-ctrl-f5 (ou o equivalente) para forçar uma atualização sem cache.

O comportamento problemático parece estar no lado do navegador, em vez de em um cache persistente do servidor. São apenas todos os navegadores em todos os sistemas operacionais aos quais tenho acesso que estão fazendo isso.

[angus (Angus McLeod)]

Ok. Só para eu ter 100% de certeza. Quando você tem

• Webhook de comentário funcionando e verificado
• Cache do HTML do comentário desativado
• Carregamento AJAX desativado
• Sem CDN
• Sem CloudFront
• Sem plugin de cache do WordPress
• Sem avisos ou erros relevantes nos logs do PHP

você tem certeza de que não está funcionando?

Se não estiver funcionando com essa configuração, fico um pouco sem saber o que fazer sem examinar mais de perto e voltaria para

• Carregamento AJAX ativado
• Suas correções wp-discourse-cache-header-fix.php

que é o que suspeito que estava funcionando para você. Se esse caminho estiver funcionando, então você deve segui-lo.

[Lee_Ars]

@angus

Ok, para que eu entenda 100% claro, quando você tem:

• webhook de comentário funcionando e verificado
• Cache do HTML do Comentário desativado
• Carregamento AJAX desativado
• sem cdn
• sem cloudfront
• sem plugin de cache do wordpress
• sem avisos ou erros relevantes nos logs do php

Aqui está uma galeria rápida no imgur de capturas de tela das minhas configurações atuais do plugin, como referência.

Confirme que não há CDN, nem Cloudfront ou Cloudflare, nenhum dos dois, nenhum plugin de cache além do Nginx helper (para ajudar o WP a invalidar o cache fast-cgi do nginx conforme necessário).

Confirme também que não há nada relevante nos logs de erro do php-fpm ou do nginx.

você tem certeza de que não está funcionando?

Cara, eu queria que estivesse. Tenho batido a cabeça nisso por cerca de 30 horas neste momento, com algum tempo para dormir. Posso estar ficando um pouco vesgo, heh.

[angus (Angus McLeod)]

Sim, eu entendo. Dê um tempo por um dia ou algo assim. Tentarei recriar o problema amanhã copiando sua configuração.

[Lee_Ars]

Se eu não encontrar uma solução por conta própria, e se você quiser, ficaria feliz em conceder acesso local temporário (ao blog do WP, ao Discourse e/ou aos hosts subjacentes) para solução de problemas. Definitivamente não estou tentando conseguir trabalho gratuito ou algo do tipo. Ficaria feliz em pagar pelos seus serviços se houver tempo real a ser dedicado aqui.

[angus (Angus McLeod)]

Ok, aqui está um vídeo de mim tentando (e falhando) em reproduzir seu problema:

Setting Up WordPress With Discourse Discussion Forum Software

A próxima coisa que quero que você tente é este filtro.

@angus

wpdc_comment_sync_period

Define o período de sincronização para comentários em segundos. Padrão 600, ou seja, 10 minutos.

Exemplo

Define o período de sincronização para 5 minutos.

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

[Lee_Ars]

Obrigado @angus — falhar na reprodutibilidade, na verdade, me deixa muito mais tranquilo, porque isso significa que estou fazendo algo errado em vez de haver algo errado de fato

Vou adicionar esse filtro hoje, quando tiver um tempo para solucionar problemas, e reportarei de volta

[Lee_Ars]

Respondendo um mês e pouco depois para fechar o ciclo — ainda estou tendo alguns problemas estranhos na implantação em produção completa (site prod, exemplo de postagem no site prod com embed do Discourse, fórum real do Discourse), mas tudo é gerenciável. Vou atribuir quaisquer problemas de latência/atraso restantes à complexa camada de bolo que é Wordpress + Discourse + Cloudflare, e à minha estratégia agressiva de cache para manter todas essas coisas operacionais durante tempestades de tráfego que resultam de tempestades reais.

Obrigado por dedicar seu tempo para responder, @angus <3

[Lee_Ars]

Peço desculpas por reabrir este tópico novamente, mas queria dar seguimento e relatar que encontrei a causa do problema! E foi culpa minha, como sempre.

Resumidamente, guardo detalhes comuns de blocos de localização PHP em um snippet em /etc/nginx/snippets/ para poder incluí-los em vários arquivos vhost sem ter que duplicá-los toda vez. Fazia muiiiiito tempo (anos, provavelmente) que não verificava esse snippet, e lá estava ele, um add_header Cache-Control "public, max-age=7200"; espúrio, que estava sendo aplicado a tudo que saía desse bloco de localização.

Então eu o removi, limpei todas as camadas de cache e, vejam só, o comportamento problemático desapareceu.

Obrigado novamente por dedicar seu tempo para trabalhar comigo, @angus, mesmo que isso tenha se revelado mais uma vez um problema do Discourse causado por mim