Abbiamo già tutta la logica necessaria per gli sprite SVG nei casi di sottocartelle, ed è utilizzata con successo da diversi siti. In questo caso, però, ci siamo imbattuti in un caso limite molto specifico. Controllando le variabili chiave nel sito di @vkozyrev (nella console del browser):
> Discourse.SvgSpritePath
"/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js"
> Discourse.BaseUri
"/sales-community"
Tutto sembra corretto. Ora, quando carichiamo il foglio degli sprite SVG, utilizziamo loadScript, che a sua volta chiama Discourse.getURL. Questa funzione è responsabile dell’aggiunta del prefisso della sottocartella. Proviamo:
> Discourse.getURL(Discourse.SvgSpritePath)
"/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js"
Strano… non ha fatto nulla. Un altro URL casuale funziona invece correttamente:
> Discourse.getURL("/blah")
"/sales-community/blah"
Un’ulteriore indagine rivela questa riga all’interno di getUrl
if (url.indexOf(Discourse.BaseUri) !== -1) return url;
Ovvero, in italiano: “se l’URL contiene già il prefisso della sottocartella, desisti”. Quindi il problema qui è che il prefisso della sottocartella di @vkozyrev (/sales-community) è incluso a metà dell’URL del foglio degli sprite SVG
/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js
Ho reso il controllo più specifico, in modo che verifichi il prefisso della sottocartella solo all’inizio dell’URL:
Ciò mi fa però pensare ad altre potenziali problematiche… ad esempio, se qualcuno volesse impostare il proprio prefisso di sottocartella come /t o /about, o qualsiasi altro URL utilizzato in Discourse 