Ich gehe davon aus, dass es fair ist anzunehmen, dass jeder relative Link relativ zum Stammverzeichnis des Unterordners ist. Wenn Sie also einen Link außerhalb des Forums wünschen, müssen Sie die vollständig qualifizierte URL verwenden.
Alternativ könnten Sie meiner Meinung nach eine Permalink-Route für /forum/downloads/* auf https://example.com/downloads/* einrichten.
Das hat vorher funktioniert, warum wurde es geändert?
Ich würde nicht erwarten, dass dies das übliche Verhalten ist, wenn der relative Pfad verankert ist, also /downloads – in der HTML/HTTP-Welt deutet dies auf das Root-Verzeichnis der Site hin, nicht auf das Root-Verzeichnis des Unterordners.
Wenn Sie also einen Link auf Ihrer Hauptwebsite hätten, der mit /t/something beginnt, wie würden Sie dann wissen, ob es sich um einen Discourse-Link oder um einen Link zu Ihrer Hauptwebsite handelt?
Es würde als /forums/t/etwas geschrieben. Das ist das, was ein öffentlicher Benutzer erwarten würde, der einen Forenbeitrag verfasst. So funktionieren die meisten Websites – warum sollte jemand wissen, dass man /t/etwas eingeben muss?
Ernsthaft? Wenn Sie eine URL schreiben, die mit / beginnt, befindet sie sich nach Design im Root des Standorts – definieren Sie neu, wie HTML-Links funktionieren?
Das funktionierte seit 2,5 Jahren einwandfrei auf unserer Website – bis zur jüngsten brechenden Änderung.
Das ist das Problem: Discourse fügt bei mehreren Anwendungen dasselbe Präfix /forums hinzu, was die oben genannten Probleme verursacht. Ich verstehe nicht, warum Sie die in einem Beitrag eingegebene URL überhaupt ändern müssen?
Wir untersuchen dieses Problem. Es könnte mit dieser Korrektur zusammenhängen:
Ich stimme zu, dass Links zu /jobs auf acme.com unabhängig von der Subordner-Konfiguration zu acme.com/jobs führen sollten. Sie sollten nicht zu acme.com/forum/jobs führen.
Ich habe den letzten Commit zu get-url.js etwas nach dem verlinkten Commit durchgeführt.
Ich stimme zu, dass Links nicht umgeschrieben werden sollten, wenn sie vom Benutzer eingegeben wurden. Vielleicht sollte getURL in diesen Fällen gar nicht aufgerufen werden? Ich denke, getURL soll für Standard-Routes von Discourse verwendet werden, um sie in das Subfolder-Setup umzuwandeln. Es gibt Tests, die explizit dieses Voranstellen des Subfolders erwarten:
Ich habe das heute Nachmittag untersucht und habe in diesem PR eine Lösung:
Leider ist unser routeTo-Code so konzipiert, dass er mit relativen URLs arbeitet. Wenn wir also url.routeTo("/cool") aufrufen und ein Unterordner namens sub eingerichtet ist, wird dies zu /sub/cool umgeschrieben, obwohl /cool wie eine relative URL aussieht. Ich halte das nicht für korrekt, aber ich vermute, dass viel Code davon abhängt.
Glücklicherweise war es in diesem Fall der Click-Tracker, der umleitete, weil er annahm, die URL sei intern. Ich habe eine Prüfung hinzugefügt, um sicherzustellen, dass der interne Link dasselbe Präfix verwendet, und die Tests bereinigt. Es scheint zu funktionieren.
Ich habe jedoch keine Ahnung, wie es zu diesem Regression kam – ich habe versucht, mit git blame nachzuvollziehen, was passiert ist, aber ohne Erfolg.
Ich bin mir nicht sicher, ob dies damit zusammenhängt, aber nachdem ich das Update heruntergeladen habe, funktioniert der Link-Editor nicht mehr (erscheint leer oder trennt die Felder nicht).
Wir haben auch bemerkt, dass relative Links zur gleichen Website, wie /downloads, als externe Links behandelt und in einem neuen Browser-Tab geöffnet werden. Das ist eigentlich kein großes Problem.
Auch kein großes Ding, aber wenn du die Post-ID am Ende eines Links zu einem Forenbeitrag entfernst, wie ich es getan habe, geht die Browserverlauf verloren, wenn du auf den Link klickst, z. B. diesen Link.
Leider kann ich das nicht reproduzieren. Lokal funktioniert der exakt gleiche Link einwandfrei. Ich sollte auch hinzufügen, dass mein Patch die Art und Weise, wie Links als HTML geschrieben werden, nicht ändern soll; er regelt nur, was passiert, wenn man auf einen Link klickt.
Ich glaube, dass dies bereits untersucht wird, danke: