Я думаю, что справедливо предположить, что любая относительная ссылка относится к корню подпапки. Поэтому, если вам нужна ссылка вне форума, вам придется использовать полный URL.
В качестве альтернативы, я думаю, вы сможете настроить перенаправление постоянных ссылок /forum/downloads/* на https://example.com/downloads/*.
Я бы не подумал, что это нормальное поведение, когда относительный путь имеет якорь, например /downloads — в мире HTML/HTTP это указывает на корень сайта, а не на корень подпапки.
Итак, если у вас на основном сайте есть ссылка, начинающаяся с /t/something, как вы поймёте, является ли она ссылкой Discourse или ссылкой на ваш основной сайт?
Это будет записано как /forums/t/something. Именно так ожидает увидеть публичный пользователь, пишущий сообщение на форуме. Так работают большинство веб-сайтов — почему кто-то должен знать, что нужно вводить /t/something?
В этом и заключается проблема: Discourse добавляет один и тот же префикс /forums к нескольким приложениям, что и вызывает вышеупомянутые трудности. Я не понимаю, зачем вообще нужно изменять URL, вставленный в сообщение?
Мы расследуем эту проблему, возможно, она связана с этим исправлением:
Я согласен, что ссылки на /jobs на acme.com должны вести на acme.com/jobs независимо от настройки подпапки. Они не должны вести на acme.com/forum/jobs.
Я сделал последний коммит в get-url.js спустя некоторое время после связанного.
Я согласен, что ссылки, введённые пользователем, не должны переписываться; возможно, в таких случаях getURL вообще не должен вызываться? Мне кажется, getURL предназначен для маршрутов по умолчанию Discourse, чтобы «конвертировать» их в настройку с подпапкой. В тестах явно ожидается добавление префикса подпапки:
Я исследовал это сегодня днем и подготовил исправление в этом PR:
К сожалению, наш код routeTo предназначен для работы с относительными URL-адресами, поэтому, если мы вызовем url.routeTo("/cool") и настроена подпапка sub, он перепишет адрес в /sub/cool, даже если /cool выглядит как относительный. Я не считаю это правильным, но, вероятно, от этого зависит много кода.
К счастью, в данном случае перенаправление выполнял трекер кликов, так как он посчитал URL внутренним. Я добавил проверку, чтобы убедиться, что внутренняя ссылка находится на том же префиксе, и привел в порядок тесты. Похоже, всё работает.
Однако я не знаю, как произошло регрессионное изменение — я попытался использовать git blame, но безрезультатно.
Мы также заметили, что относительные ссылки на тот же сайт, например /downloads, обрабатываются как внешние ссылки и открываются в новой вкладке браузера. На самом деле это не проблема.
Также, не критично, но если вы удалите идентификатор поста из конца ссылки на сообщение форума, как я сделал, история браузера теряется при клике на ссылку, например, эта ссылка
К сожалению, мне не удалось воспроизвести это. Локально при использовании точно такой же ссылки она работает корректно. Также хочу добавить, что мой патч не должен изменять способ написания ссылок в HTML, он обрабатывает только то, что происходит при клике на ссылку.