I have a client for whom embedded youtube videos are missing. They appear in composer’s preview, but when the messages are saved, they disappear. They are working fine in try.discourse.org. I tried whitelisting youtu.be and changing the URL to a youtube.com url too. Neither solved the problem.
It seems that the problem was that recent Discourse updates have caused my DOI resolver plugin to muck things up. (I disabled a couple other things too, but it was definitely some plugin. . . )
Eu também encontrei isso. É um banimento temporário de IP (creio que de 1 hora), e durante esse período todos os oneboxes do YouTube falham para as postagens rebaked.
Talvez devesse ser implementado algum mecanismo para impedir mais de x solicitações ao YouTube por hora durante o rebaking?
Recentemente, após uma série de alterações e atualizações na minha instalação do Discourse, apenas duas coisas estão faltando. Uma é não conseguir reconstruir o contêiner de dados, e estou tentando descobrir como resolver, mas a outra é que todos os oneboxes funcionam, exceto com URLs do YouTube.
Dentro do servidor e do contêiner, consigo fazer CURL para o YouTube. Como posso ter certeza de que se trata de um banimento temporário de IP?
Edição: Posso confirmar que nem o Rebuild (App) nem o Rebake afetam esse problema.
Edição 2: Ao pesquisar, vi que @jomaxro comentou aqui que coisas como o CloudFlare podem afetar os Oneboxes… um CDN pode afetar apenas um Onebox? Tentei colocá-lo no Modo de Desenvolvimento, mas não houve mudanças.
Edição 3: Tentei remover todos os plugins. Nada mudou. (Além disso, não consigo rebakear, pois parece que os processos estão se interrompendo mutuamente).
Edição 4: Tentei o comando de @Overgrow e sim, de fato tenho um problema
[1] pry(main)> posts = Post.where("raw like '%youtube%'").count
=> 72674
Estou tendo dificuldade para executar os comandos de rebake porque meu contêiner está me retornando:
Primeiro de tudo, muito obrigado por dedicar seu tempo para me ajudar, @riking.
Executei esse comando e obtive o que presumo ser o número de postagens faltantes: 22462. Com base na última parte do comando, é seguro assumir que ele está sendo executado em segundo plano?
Não é necessário usar regex para encontrar uma string em um post. Uma simples busca por string funcionará bem para youtube (por exemplo). Neste exemplo, cada post que contenha a string youtube será reprocessado, um a cada 100 segundos (muito lento…)
Cerca de 100 segundos se passaram:
Vou deixar isso rodar, imaginando que em 76.200 segundos, mais ou menos, essa tarefa rake estará concluída
Acho que deveria ter configurado este exemplo com um atraso de 10 segundos
Queria dizer que executei em uma pequena amostra e depois executei novamente, mas o número não mudou.
Ou seja: executei o comando e tinha 76.000 posts, processou 200, parou, executei outro e o novo número foi 76.200 (sim, talvez meus usuários tenham adicionado 400 posts com YouTube… mas… não sei).
Agora estou executando novamente só para ver como fica, mas vai levar alguns dias (76.500 acessos…)
Como ninguém mais tem esse problema, estou tentando pensar nas minhas variáveis e basicamente:
Mudei de máquina (então poderia ser limitação de taxa do YouTube?)
Restaurei um backup do Discourse em uma nova instalação (isso não deveria estar relacionado, mas neste ponto estou apostando em tudo que se move)
Instalação em dois containers (Pensei que tivesse um problema com a reconstrução dos dados, mas graças a esta informação do @Falco, agora sei que é “normal”.)
Coloquei o CloudFlare em cima seguindo os tutoriais de CDN que estão aqui.
Depois pensei: “Bem, óbvio, você precisa adicionar o temporizador, senão não conseguimos testar a ‘Teoria do Limite de Taxa’”, então tentei o que você postou:
root@cont-web-only:/var/www/discourse# time rake posts:rebake_match['youtube',string,100]
216 / 76594 (0.2%)-
E parei só para verificar se as coisas estavam mudando. Aparentemente nada, então pensei: “ok, deixe-me rodar isso novamente e ver como vai”:
root@cont-web-only:/var/www/discourse# time rake posts:rebake_match['youtube',string,100]
116 / 76598 (0.2%)-
Isso está rodando agora mesmo. Então meu argumento era que o número total de posts não diminuiu com o outro rebake. (Eu poderia estar, e possivelmente estou, errado com essa lógica).