Creo que es razonable asumir que cualquier enlace relativo es relativo a la raíz de la subcarpeta. Por lo tanto, si deseas un enlace fuera del foro, necesitarás usar la URL completamente calificada.
Alternativamente, creo que podrías configurar un enrutamiento de enlace permanente /forum/downloads/* hacia https://example.com/downloads/*.
No pensaría que esto sea lo normal de esperar cuando la ruta relativa está anclada, es decir, /downloads. En el mundo HTML/HTTP, esto sugiere la raíz del sitio, no la raíz de la subcarpeta.
Entonces, si tuvieras un enlace en tu sitio web principal que comenzara con /t/algo, ¿cómo sabrías si es un enlace de Discourse o un enlace a tu sitio web principal?
Se escribiría como /forums/t/something. Esto es lo que esperaría un usuario público al publicar en un foro. Así es como funciona la mayoría de los sitios web: ¿por qué alguien sabría que debe ingresar /t/something?
Ese es el problema: Discourse está agregando el mismo prefijo /forums a varias aplicaciones y eso está causando los problemas mencionados. No entiendo por qué necesitas alterar la URL ingresada en una publicación en absoluto.
Estamos investigando este problema; es posible que esté relacionado con esta solución:
Estoy de acuerdo en que los enlaces a /jobs en acme.com deberían dirigirse a acme.com/jobs, independientemente de la configuración de subcarpeta. No deberían ir a acme.com/forum/jobs.
He realizado el último commit en get-url.js, algún tiempo después del enlace mencionado.
Estoy de acuerdo en que los enlaces no deberían reescribirse si fueron ingresados por el usuario; quizás getURL no debería llamarse en estos casos. Creo que getURL está diseñado para usarse con las rutas predeterminadas de Discourse para “convertirlas” a la configuración de subcarpeta; tiene algunas pruebas que esperan explícitamente este prefijo de subcarpeta:
Investigué esto esta tarde y tengo una corrección en este PR:
Desafortunadamente, nuestro código routeTo está diseñado para funcionar con URLs relativas, por lo que si llamamos a url.routeTo("/cool") y hay una subcarpeta llamada sub configurada, lo reescribirá como /sub/cool, aunque /cool parezca relativo. No creo que esto sea correcto, pero apuesto a que gran parte del código depende de ello.
Afortunadamente, en este caso fue el rastreador de clics el que estaba redirigiendo porque pensaba que la URL era interna. Agregué una verificación para asegurarme de que el enlace interno esté en el mismo prefijo y limpié las pruebas. Parece que funciona.
Sin embargo, no tengo idea de cómo se produjo la regresión; intenté usar git blame pero no obtuve ningún resultado.
También hemos notado que los enlaces relativos al mismo sitio, como /downloads, se tratan como enlaces externos y se abren en una nueva pestaña del navegador. En realidad, no es gran cosa.
Además, tampoco es un problema grave, pero si eliminas el ID de la publicación al final de un enlace a una publicación del foro, como hice yo, se pierde el historial del navegador al hacer clic en el enlace, por ejemplo, este enlace.
Lamentablemente, no puedo reproducir esto. Localmente, cuando uso exactamente el mismo enlace, funciona correctamente. También debo aclarar que mi parche no debería cambiar la forma en que se escriben los enlaces en HTML; solo gestiona lo que sucede al hacer clic en un enlace.