Olá,
Existe alguma maneira de desativar os links de âncora para os cabeçalhos do markdown? (introduzido na v2.7.0)
Usamos um trecho de código que consulta tópicos (usando o plugin Data Explorer), mas esses links de âncora quebram o processo. Gostaríamos de atualizar nosso Discourse, mas estamos presos com este trecho de código.
Obrigado, Michel
Olá Michel. 
Não há configuração para configurar os links de âncora.
Talvez possamos ajudá-lo nesse sentido: o que exatamente nos links de âncora quebra sua consulta? 
Obrigado Maiki pelo seu apoio
Ok, estamos usando este software: GitHub - canonical/canonicalwebteam.discourse
Ele usa uma consulta do Data Explorer, mas depois não consegue lidar com os links âncora.
A partir daí, vejo 2 caminhos possíveis:
Nosso servidor está atualmente em 2.9.0 beta10. Não há muito conteúdo lá, então seria super fácil transferir para outro, sem grandes problemas.
Tentei iniciar um novo servidor (no Docker) com:
#version: tests-passed
substituído por
version: f73cdbbd2f20460ea6330930f97cdce59fb984be (último commit do 2.6.7)
Mas, infelizmente, ele se recusa a iniciar:
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 47
ok: run: redis: (pid 62) 0s
ok: run: postgres: (pid 59) 0s
supervisor pid: 57 unicorn pid: 90
config/unicorn_launcher: line 71: kill: (90) - No such process
config/unicorn_launcher: line 15: kill: (90) - No such process
(57) exiting
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
ok: run: redis: (pid 358) 0s
timeout: down: postgres: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
...
Alguma sugestão?
Você não pode voltar versões assim. As migrações de dados tornam o estado do banco de dados incompatível, portanto, apenas avançar é suportado.
Oi Falco,
Eu estava pensando em começar um novo servidor, não em fazer downgrade.
Não é um grande problema para os dados atuais, apenas algumas coisas, fáceis de recolocar em um novo servidor.
O branch 2.6 do Discourse foi lançado há quase 2 anos, então há a possibilidade de que ele simplesmente não funcione com a versão atual da imagem base do contêiner que enviamos no momento. Para solucionar o problema, eu precisaria dos ./launcher rebuild logs ao tentar reconstruí-lo como 2.6.7 em uma instalação totalmente nova.
No entanto, executar uma versão do Discourse que não recebe mais correções de segurança é uma péssima ideia, então a maneira correta de seguir em frente é corrigir o software que você usa para lidar com essa integração.
Talvez você possa compartilhar a consulta SQL que precisa ser corrigida?