У нас уже вся логика для SVG-спрайтов в сценариях с подпапками реализована и успешно используется на ряде сайтов. В данном случае мы столкнулись с очень специфическим пограничным случаем. Проверим ключевые переменные на сайте @vkozyrev (в консоли браузера):
> Discourse.SvgSpritePath
"/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js"
> Discourse.BaseUri
"/sales-community"
Выглядит хорошо. Теперь, когда мы загружаем лист SVG-спрайтов, мы используем loadScript, который, в свою очередь, вызывает Discourse.getURL. Эта функция отвечает за добавление префикса подпапки. Попробуем это:
> Discourse.getURL(Discourse.SvgSpritePath)
"/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js"
Хм… ничего не изменилось. Другой случайный URL работает нормально:
> Discourse.getURL("/blah")
"/sales-community/blah"
Немного покопавшись, мы находим эту строку внутри getUrl:
if (url.indexOf(Discourse.BaseUri) !== -1) return url;
Или, по-русски: «если URL уже содержит префикс подпапки, прекращаем». Таким образом, проблема здесь в том, что префикс подпапки @vkozyrev (/sales-community) включён в середину URL листа SVG-спрайтов:
/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js
Я сделал проверку более конкретной, чтобы она проверяла наличие префикса подпапки только в начале URL:
Хотя это заставляет меня задуматься о других потенциальных проблемах… например, если кто-то захочет использовать префикс подпапки /t или /about, или любой другой URL, который мы используем в Discourse 