Wir haben die gesamte Logik für SVG-Sprites in Unterordner-Szenarien bereits implementiert, und sie wird von mehreren Sites erfolgreich genutzt. In diesem Fall sind wir jedoch auf einen sehr spezifischen Randfall gestoßen. Ein Blick auf die relevanten Variablen auf @vkozyrevs Site (in der Browserkonsole):
> Discourse.SvgSpritePath
"/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js"
> Discourse.BaseUri
"/sales-community"
Sieht gut aus. Wenn wir nun das SVG-Sprite-Sheet laden, verwenden wir loadScript, das wiederum Discourse.getURL aufruft. Diese Funktion ist dafür zuständig, das Unterordner-Präfix hinzuzufügen. Testen wir das:
> Discourse.getURL(Discourse.SvgSpritePath)
"/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js"
Hm… das hat nichts bewirkt. Eine andere zufällige URL funktioniert hingegen einwandfrei:
> Discourse.getURL("/blah")
"/sales-community/blah"
Beim weiteren Nachforschen stießen wir auf diese Zeile innerhalb von getUrl:
if (url.indexOf(Discourse.BaseUri) !== -1) return url;
Oder auf Deutsch: „Wenn die URL bereits das Unterordner-Präfix enthält, abbrechen.“ Das Problem ist also, dass @vkozyrevs Unterordner-Präfix (/sales-community) in der Mitte der SVG-Sprite-Sheet-URL enthalten ist:
/svg-sprite/sales-community-staging.rainmakers.co/svg-2-8ed106e6e3d908b1b86898dfe93a7bac0fd358f4.js
Ich habe die Prüfung nun präziser gestaltet, sodass sie nur das Unterordner-Präfix am Anfang der URL überprüft:
Das lässt mich allerdings an andere potenzielle Probleme denken… z. B. wenn jemand sein Unterordner-Präfix als /t oder /about oder eine andere URL wählen möchte, die wir in Discourse verwenden 