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 durch das offene Thema in der Kategorie bug hier angedeutet wird
@sam Ich habe mir das heute noch einmal angesehen, und es gibt zwei Möglichkeiten:
Speichere einen tatsächlichen kodierten Slug in der Slug-Spalte, wenn die Einstellung zur Slug-Generierung auf kodiert gesetzt ist. Führe eine Migration durch, um alle aktuellen Slugs zu löschen, wenn kodierte Slugs verwendet werden, damit sie im Laufe der Zeit ordnungsgemäß neu generiert werden.
Behalte den aktuellen UTF-8-Slug bei und korrigiere ihn on-the-fly, wenn er in einem Header für eine 301-Weiterleitung gesendet wird.
