Auf community.wanikani.com funktioniert das Öffnen von Links zu Themen mit japanischen Zeichen in der vollständig qualifizierten URL nicht mehr, wenn sie in einem neuen Tab geöffnet oder direkt kopiert und eingefügt werden. Das Anklicken des Links zur Navigation im selben Tab funktioniert jedoch weiterhin.
Ich habe versucht, das Problem auch auf try.discourse.org nachzustellen, aber bei dieser Installation werden japanische Zeichen selbst dann nicht in die URL eingefügt, wenn sie im Titel des Themas enthalten sind. Ich bin mir nicht sicher, warum das so ist, aber ohne dieses Verhalten kann ich den Fehler dort nicht demonstrieren.
Seufz Es sieht so aus, als wäre es wieder ein Chrome-Bug. Bei mir funktioniert es sowohl in Firefox als auch in Edge einwandfrei. Seltsamerweise klappt es beim ersten Mal in einem Inkognito-Fenster, scheitert aber beim zweiten Mal. Das Gleiche passiert auch nach dem Löschen des Site-Caches/Cookies und einem Neustart meines Computers.
Wären Sie so nett, das in Chrome zu prüfen, um zu bestätigen, ob es dort generell ein Problem ist und nicht nur bei mir? Bitte versuchen Sie unbedingt, die Seite mehrmals zu öffnen, da die erste Öffnung scheinbar problemlos funktioniert. Ich danke Ihnen für die Hilfe!
Immer noch mit Chrome? Ich möchte nur sichergehen, bevor ich es ihnen melde. Ich gehe davon aus, dass sich kürzlich nichts in Bezug auf dieses Problem auf Discourse geändert hat? (Unabhängig davon wäre dies wahrscheinlich immer noch ein Chrome-Problem, da es nur dort auftritt, selbst wenn sich etwas auf Discourse geändert hätte.)
Nun, das war’s dann wohl. Es ist heute wieder aufgetreten. Ich habe keine Ahnung, wie es für eine Weile behoben werden konnte.
Da das möglicherweise eine Weile in Anspruch nimmt, wäre ich vorerst für Workarounds offen. Ich habe im ursprünglichen Beitrag erwähnt, dass auf try (und ich habe das hier im Meta-Bereich ebenfalls überprüft) japanische Zeichen nie zur URL hinzugefügt werden, was dieses Problem effektiv umgeht. Ist das eine Site- oder Kategorieeinstellung, über die ich mit meinem Site-Administrator sprechen kann? Gibt es noch andere Vorschläge für einen Workaround außer diesem?
Wenn ich eine URL mit einem arabischen Titel in den Browser eingebe, wie zum Beispiel:
https://forums.coretabs.net/t/2456
gerate ich in eine Endlosschleife von Weiterleitungen (und der generierte Link ist meiner Meinung nach falsch; das liegt wahrscheinlich an der Kodierung).
Dieser Fehler existierte vor den letzten Updates noch nicht (das letzte Mal, dass ich versucht habe, einen Link zu teilen, war vor etwa zwei Wochen, und damals hat alles einwandfrei funktioniert).
Ich habe mich in unseren Codebase eingearbeitet und es sieht so aus, als wäre der Fehler relativ einfach, aber ich möchte meine Annahmen gerne verifizieren.
Wir haben eine Site-Einstellung namens slug_generation_method, die von dem Standardwert ascii auf encoded geändert werden muss, um diesen Fehler auszulösen. Wenn Sie diese Site-Einstellung ändern, löschen wir alle Slugs und generieren sie neu.
Was ich nicht verstehe, ist, warum wir, wenn die Site-Einstellung auf “encoded” gesetzt ist, einen Slug wie diesen generieren:
Der Roh-Slug aus der Tabelle wird im Location-Header der 301-Antwort zurückgegeben, wenn ein Topic-Slug nicht übereinstimmt, und meiner Meinung nach sollten wir dort eine gültige URL zurückgeben.
Meinst du also, dass die URL selbst die codierte Version anzeigt? Oder nur, dass die Weiterleitung dies intern durch Verwendung der codierten Version handhabt? Auf jeden Fall wäre es toll, wenn dies „einfach funktioniert
Nein, wie das offene Thema in der Kategorie Contribute > Bug hier zeigt
@sam Ich habe mir das heute noch einmal angesehen, und es gibt zwei Möglichkeiten, dies anzugehen:
Speichere einen tatsächlichen encoded-Slug in der Slug-Spalte, wenn die Einstellung zur Slug-Generierung auf encoded steht. Erstelle eine Migration, um alle aktuellen Slugs zu löschen, wenn Encoded-Slugs verwendet werden, damit sie im Laufe der Zeit korrekt neu generiert werden.
Behalte den aktuellen UTF-8-Slug und passe ihn beim Senden in einem Header für eine 301-Weiterleitung dynamisch an.
Meiner Meinung nach ist Option 1 “korrekter” und macht es schwieriger, den rohen Slug an einen Client zu übergeben. Allerdings reichte es nicht aus, nur den Slug-Generator zu patchen, da der Browser eine encodierte URL bei der 301-Weiterleitung erhält, diese aber für die nächste Anfrage decodiert, wodurch unser Slug-Vergleich fehlschlägt und erneut weitergeleitet wird. Das bedeutet, dass ich auch die Slug-Vergleichsmethode im Themen-Controller patchen muss, sowie möglicherweise andere Stellen.
