Acho que é justo assumir que qualquer link relativo é relativo à raiz da subpasta. Então, se você quiser um link fora do fórum, precisará usar a URL totalmente qualificada.
Alternativamente, acho que você pode configurar um roteamento de permalink /forum/downloads/* para https://example.com/downloads/*.
Eu não esperaria que isso fosse o comportamento normal quando o caminho relativo está ancorado, ou seja, /downloads — no mundo HTML/HTTP, isso sugere a raiz do site, não a raiz da subpasta.
Então, se você tivesse um link no seu site principal começando com /t/algo, como saberia se era um link do Discourse ou um link para o seu próprio site principal?
Isso seria escrito como /forums/t/something. É isso que um usuário público ao escrever uma postagem no fórum esperaria. É assim que a maioria dos sites funciona — por que alguém saberia digitar /t/something?
Esse é o problema: o Discourse está adicionando o mesmo prefixo /forums a vários aplicativos, e isso está causando os problemas mencionados acima. Não entendo por que você precisa alterar a URL inserida em uma postagem de qualquer forma?
Estamos investigando este problema, que possivelmente está relacionado a esta correção:
Concordo que os links para /jobs em acme.com devem levar a acme.com/jobs, independentemente da configuração de subpasta. Eles não devem levar a acme.com/forum/jobs.
Fiz o último commit em get-url.js, algum tempo após o commit vinculado.
Concordo que links não devem ser reescritos se forem inseridos pelo usuário; talvez getURL não deva ser chamado nesses cenários? Acredito que getURL seja destinado a ser usado para rotas padrão do Discourse para “convertê-las” para a configuração de subpasta; ele possui alguns testes que esperam explicitamente esse prefixo de subpasta:
Investiguei isso esta tarde e tenho uma correção neste PR:
Infelizmente, nosso código routeTo foi projetado para funcionar com URLs relativas. Então, se chamarmos url.routeTo("/cool") e houver uma subpasta sub configurada, ele reescreverá para /sub/cool, mesmo que /cool pareça relativo. Não acho que isso esteja correto, mas aposto que muito código depende disso.
Felizmente, neste caso, foi o rastreador de cliques que estava redirecionando porque achava que a URL era interna. Adicionei uma verificação para garantir que o link interno esteja no mesmo prefixo e limpei os testes. Parece que está funcionando.
Não faço ideia de como isso regrediu — tentei usar git blame e não obtive resultados.
Não tenho certeza se isso está relacionado ou não, mas após baixar a atualização, o editor de links parou de funcionar (aparece vazio ou não separa os campos).
Também notamos que links relativos para o mesmo site, como /downloads, são tratados como links externos e abrem em uma nova aba do navegador. Isso não é realmente um grande problema.
Além disso, também não é algo grave, mas se você remover o ID da postagem do final de um link para uma postagem no fórum, como fiz, o histórico do navegador é perdido ao clicar no link, por exemplo, este link.
Infelizmente, não consigo reproduzir isso. Localmente, quando uso exatamente o mesmo link, ele funciona corretamente. Devo também acrescentar que meu patch não deve alterar a forma como os links são escritos em HTML; ele apenas lida com o que acontece quando você clica em um link.
Acredito que isso já está sendo analisado, obrigado: