No problem. I wish I could help you more, but unfortunately, I do not have enough knowledge on the subject. Hopefully someone that knows more will respond soon. I would also watch the topic that I linked to. It might eventually have a solution posted.
In the mean time, you might want to take a look at your logs and see if there are similarities to the logs posted in that topic. I’m pretty sure the logs you would be interested in can be found by adding /logs to your forum’s base URL. So it would look something like https://example.com/logs The user in that topic also mentions a proxy. Are you using a proxy?
If you can provide this type of information, it should be helpful to someone that reads this topic and has a better understanding on the subject.
We’d prefer if you could upload to try first (try.discourse.org), that way we don’t start getting image uploads all over the place. If the image fails to lightbox on try, then feel free to upload it here so the example doesn’t get deleted when try is reset each day. If the image lightboxes on try then the issue is specific to your configuration as @schungx stated.
Estou executando a versão 2.5.0.beta6 e estou enfrentando o mesmo problema.
“Criar miniaturas” está ativo, mas não cria um lightbox, independentemente do tamanho da imagem.
Tenho uma segunda instância do Discourse com alguns meses de idade e, nela, há postagens antigas onde o lightbox funciona, mas não nas postagens novas.
Talvez seja um problema com uma atualização?
Se eu fizer o upload da mesma imagem para try.discourse.org, ela funciona corretamente com o lightbox lá.
Isso sugere que há um problema em algum lugar da sua configuração. Você poderia verificar o console do seu navegador em busca de erros ou enviar um link para o site que está apresentando problemas?
Acabei de criar um tópico de teste em uma nova instância do Discourse que configurei na semana passada.
A imagem tem 1920x1050, mas não abre em um lightbox. https://dis.ctb.co.at/t/test-image-lightbox/44
Na segunda instalação, onde o lightbox funcionava antes, o caminho era inicialmente “/var/docker” e eu o alterei posteriormente para outro local.
Pode ser que o problema do lightbox tenha começado com essa mudança de caminho. — Não tenho certeza.
Será que perdi alguma configuração para o novo caminho?
As linhas acima foram as únicas que encontrei que apontavam para o diretório original “/var/docker”.
Acabei de tentar movê-lo de volta para “/var/discourse” para confirmar que foi a alteração do caminho que causou o problema, mas o mesmo erro ocorre lá com o caminho original.
Ele também roda atrás de um proxy reverso nginx que faz a criptografia SSL, se isso for relevante, mas não alterei nada na configuração dele desde que deixou de funcionar na outra instalação.
Fiz essas configurações para o nginx no arquivo .yml correspondente.
Se não for o caminho, o que mais poderia causar esse problema de lightbox?
Movi de volta para “/var/docker/dis.ctb.co.at”.
Esta é minha configuração atual em yml (apenas alterei os dados pessoais). Poderia haver algo errado aqui, ou isso é um problema do Discourse?
## este é o modelo de contêiner Docker Discourse tudo-em-um, autônomo
##
## Após fazer alterações neste arquivo, você DEVE reconstruir
## /var/discourse/launcher rebuild app
##
## TENHA *MUITO* CUIDADO AO EDITAR!
## ARQUIVOS YAML SÃO SUPER SUPER SENSÍVEIS A ERROS DE ESPAÇAMENTO OU ALINHAMENTO!
## visite http://www.yamllint.com/ para validar este arquivo conforme necessário
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Descomente estas duas linhas se desejar adicionar o Lets Encrypt (https)
# - "templates/web.ssl.template.yml"
# - "templates/web.letsencrypt.ssl.template.yml"
## quais portas TCP/IP este contêiner deve expor?
## Se você quiser que o Discourse compartilhe uma porta com outro servidor web como Apache ou nginx,
## consulte https://meta.discourse.org/t/17247 para detalhes
expose:
# - "80:80" # http
# - "443:443" # https
- "127.0.0.1:3041:80"
docker_args:
- "--network=nginx-br"
params:
db_default_text_search_config: "pg_catalog.english"
## Defina db_shared_buffers para no máximo 25% da memória total.
## será definido automaticamente pelo bootstrap com base na RAM detectada, ou você pode sobrescrever
db_shared_buffers: "4096MB"
## pode melhorar o desempenho de classificação, mas aumenta o uso de memória por conexão
#db_work_mem: "40MB"
## Qual revisão do Git este contêiner deve usar? (padrão: tests-passed)
#version: tests-passed
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## Quantas solicitações web simultâneas são suportadas? Depende da memória e dos núcleos da CPU.
## será definido automaticamente pelo bootstrap com base nas CPUs detectadas, ou você pode sobrescrever
UNICORN_WORKERS: 8
## TODO: O nome de domínio ao qual esta instância do Discourse responderá
## Obrigatório. O Discourse não funcionará com um número IP puro.
DISCOURSE_HOSTNAME: dis.ctb.co.at
## Descomente se quiser que o contêiner seja iniciado com o mesmo
## nome de hostname (opção -h) especificado acima (padrão "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: Lista de e-mails separados por vírgula que serão feitos administradores e desenvolvedores
## no primeiro exemplo de inscrição 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'nothing@nothing.com'
## TODO: O servidor de e-mail SMTP usado para validar novas contas e enviar notificações
## Endereço SMTP, nome de usuário e senha são obrigatórios
## AVISO: o caractere '#' na senha do SMTP pode causar problemas!
DISCOURSE_SMTP_ADDRESS: mailserver.nothing.com
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_USER_NAME: nothing@nothing.com
DISCOURSE_SMTP_PASSWORD: "secret"
DISCOURSE_SMTP_ENABLE_START_TLS: false # (opcional, padrão true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
## Se você adicionou o modelo Lets Encrypt, descomente abaixo para obter um certificado SSL gratuito
# LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## O endereço CDN http ou https para esta instância do Discourse (configurado para buscar)
## consulte https://meta.discourse.org/t/14857 para detalhes
#DISCOURSE_CDN_URL: https://discourse-cdn.example.com
VIRTUAL_HOST: dis.ctb.co.at
VIRTUAL_PORT: 9002
LETSENCRYPT_HOST: dis.ctb.co.at
LETSENCRYPT_EMAIL: nothing@nothing.com
## O contêiner Docker é sem estado; todos os dados são armazenados em /shared
volumes:
- volume:
host: /var/docker/dis.ctb.co.at/shared/standalone
guest: /shared
- volume:
host: /var/docker/dis.ctb.co.at/shared/standalone/log/var-log
guest: /var/log
## Plugins vão aqui
## consulte https://meta.discourse.org/t/19157 para detalhes
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
## Quaisquer comandos personalizados para executar após a construção
run:
- exec: echo "Início dos comandos personalizados"
## Se você quiser definir o endereço de e-mail 'De' para seu primeiro registro, descomente e altere:
## Após receber o primeiro e-mail de inscrição, recomente a linha. Só precisa ser executado uma vez.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: echo "Fim dos comandos personalizados"
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: "types {"
to: |
set_real_ip_from 172.18.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
types {
Agora descobri que isso só acontece quando a opção Forçar seu site a usar apenas HTTPS está ativa no momento em que o post com a imagem é criado.
Eu tinha isso ativo na outra instalação desde o início, mas de repente parou de funcionar, talvez causado por uma atualização do nginx ou do Discourse.
O nginx não mostra nada estranho até onde posso ver.
Geralmente, isso se deve a uma configuração incorreta de esquemas complexos de proxy reverso, na minha experiência. Subpastas adicionam complexidade adicional (e, portanto, variáveis) também.
Estou executando duas instalações separadas do Discourse através desse proxy nginx, além de uma instância do Nextcloud. Na primeira instalação do Discourse, o lightbox funcionava antes e, de repente, parou de funcionar. Na verdade, não alterei nada na configuração do proxy desde que estava funcionando.
Curiosamente, ele ainda cria alguns arquivos e pastas em /var/discourse, mesmo tendo definido os volumes para outro diretório.
Nunca aconteceu que arquivos fossem criados em /var/discourse; talvez eu tenha visto alguns arquivos antigos.
Agora mudei de nginx para traefik para garantir que o problema não venha do nginx, mas o problema ainda persiste. Isso indica para mim que provavelmente há um problema no lado do Discourse e não no lado do proxy.
A mesma situação ocorre com o traefik: se “https forçado” estiver desativado quando a imagem for publicada, a lightbox funciona perfeitamente, mesmo que eu habilite “https forçado” depois.
O mais que eu poderia verificar?
Ele mostra um erro no arquivo de log, indicando que não é possível acessar /uploads/....
Não foi possível acessar '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' para obter suas dimensões.
Posso acessar a imagem sem problemas se digitar a URL em um navegador: https://domain.com/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png
Completed 200 OK em 23ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3000)
Completed 200 OK em 318ms (Views: 1.2ms | ActiveRecord: 0.0ms | Allocations: 50347)
Não foi possível acessar '/uploads/default/original/1X/fe2af548af4a22f4802ddaa54afa557ae557417c.png' para obter suas dimensões.
Started GET "/posts/96" para 84.115.50.36 em 2020-07-04 14:15:14 +0000
Processing by PostsController#show as JSON
Parameters: {"id"=>"96"}
Não há erro quando o HTTPS não é forçado.
Completed 200 OK em 18ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3050)
Completed 200 OK em 296ms (Views: 0.5ms | ActiveRecord: 0.0ms | Allocations: 49562)
Started GET "/posts/97" para 84.115.50.36 em 2020-07-04 14:17:43 +0000
Processing by PostsController#show as JSON
Parameters: {"id"=>"97"}
Parece que o Discourse, por algum motivo, baixa novamente a imagem do servidor web para fazer algo relacionado ao lightbox.
Se eu baixar essa imagem manualmente dentro do contêiner Docker do Discourse, ele tenta acessar o servidor web diretamente pelo seu IP interno, em vez de acessá-lo através do proxy. Isso funciona via HTTP, mas não via HTTPS.
O próprio servidor web só tem HTTP disponível, mas ele tenta acessá-lo via HTTPS, o que falha.
Estou me perguntando por que o Discourse baixa a imagem novamente do servidor web em vez de acessá-la internamente, sem usar HTTP/HTTPS.
Edição: Descobri que renomeei o app.yml para domain.name.yml, o que fez com que o Docker alterasse o nome DNS de domain.name para seu IP interno. Renomeei para domain_name.yml e tudo está funcionando corretamente agora.