Link von Facebook auf Seite mit Umlaut funktioniert nicht

[knollsen]

Gerade eigenartiges Verhalten festgestellt.
Beispiel im Untermenü STRAFRECHT ist ein Punkt mit Vermögensdelikte also: ...domain.de/?STRAFRECHT/Vermögensdelikte
der Browser gibt: ...domain.de/?STRAFRECHT/Verm%C3%B6gensdelikte den in Facebook eingegeben
der Link von Facebook gibt: ...domain.de/?STRAFRECHT%2FVerm%C3%B6gensdelikte aus. - dieser funzt nicht.

aber komischerweise funzt dieser, wenn ich Vermögensdelikte -> Vermoegensdelikte umbenenne also: ...domain.de/?STRAFRECHT/Vermoegensdelikte
der Link von Facebook gibt: ...domain.de/?STRAFRECHT%2FVermoegensdelikte aus. - dieser funzt.

also muß der Umlaut %C3%B6 mit der Kombination %2F irgendwas verwürgeln.

[cmb]

Tja, die Facebook-Links... Da hatten wir vor langem schon einen Workaround eingeführt, der aber nicht funktioniert, wenn im Seitennamen "Sonderzeichen" enthalten sind.

Ich sehe eigentlich nur zwei saubere Lösungen: (a) Facebook davon zu überzeugen, dass sie reservierte Zeichen im Query-String nicht urlkodieren oder (b) clean URLs. (a) wird vermutlich nicht drin sein (auch wenn es eigentlich korrekt wäre), und (b) ist immer noch weit weg. Für jetzt ist wohl die beste Lösung, wenn Du Sonderzeichen in Seitenüberschriften per urichar_org/new ersetzt, was sowieso nicht verkehrt sein dürfte.

[svasti]

Für jetzt ist wohl die beste Lösung, wenn Du Sonderzeichen in Seitenüberschriften per urichar_org/new ersetzt, was sowieso nicht verkehrt sein dürfte.

darum ist jetzt auch diese Ersetzung Standard ab 1.6.7 CMSimple_XH für Deutsch. Aber wenn man updated, wird ja die Sprachdatei nicht mit upgedated.
Wenn man diese Ersetzung einstellt und schon externe Links auf die betreffenden Seiten verweisen, ist Christophs Plugin move_XH sehr nützlich um diese Links auf die neu durch Ersetzung neu benannten Seiten zu lenken.

Bei der Ersetzung haben wir genommen

Code: Select all

$tx['urichar']['new']="ae|oe|ue|ss|Ae|Oe|Ue";
$tx['urichar']['org']="ä|ö|ü|ß|Ä|Ö|Ü"; 

Vielleicht könnte man auch noch weitere Zeichen ersetzten?

[knollsen]

Nein es ist nicht das Sonderzeichen sondern

also muß der Umlaut %C3%B6 mit der Kombination %2F irgendwas verwürgeln.

die Kombination von %C3%B6 und %2F

denn: (sorry hatte ich nicht gepostet) ...domain.de/?STRAFRECHT/Verm%C3%B6gensdelikte geht auch ohne %2F - das ist das was ich nicht verstehe!

[cmb]

denn: (sorry hatte ich nicht gepostet) ...domain.de/?STRAFRECHT/Verm%C3%B6gensdelikte geht auch ohne %2F - das ist das was ich nicht verstehe!

Der Schrägstrich ist ein reserviertes Zeichen; solche dürfen im Query-String (also nach dem ?) unverändert geschrieben werden, oder aber Prozentkodiert (/ vs. %2F). CMSimple akzeptiert eigentlich nur das Zeichen selbst, Facebook aber kodiert es. Daher wurde bei CMSimple_XH der besagte Workaround eingeführt, so dass auch das kodierte Zeichen akzeptiert wird. Das funktioniert aber nur, wenn sonst keine anderen kodierten Zeichen im Query-String vorhanden sind.

[knollsen]

Jepp! Danke auch für den Tip von svasti, damit klappt es. Bei 1.6.6 ist dies ziemlich weit unten und war leer die Felder, hat das nie gesehen.

[lck]

Bei der Ersetzung haben wir genommen

Code: Select all

$tx['urichar']['new']="ae|oe|ue|ss|Ae|Oe|Ue";
$tx['urichar']['org']="ä|ö|ü|ß|Ä|Ö|Ü";

Vielleicht könnte man auch noch weitere Zeichen ersetzten?

Ja, & durch und

[cmb]

Bei 1.6.6 ist dies ziemlich weit unten und war leer die Felder, hat das nie gesehen.

Ja, & durch und

Da besteht wohl tatsächlich Nachbesserungsbedarf, und grundsätzlich habe ich auch nichts dagegen.

MIttelfristig (XH 1.7?) würde ich mir aber wünschen, dass zumindest optional eine möglichst allgemeine Transliteration verfügbar ist, die sich ganz automatisch um "akzentuierte" Buchstaben, aber eben auch um die "Romanisierung" von nicht-lateinischen Schriften kümmert (wenigstens kyrillisch und griechisch). Durch die intl Erweiterung stellt PHP diese Funktionalität auch zur Verfügung (Transliterator), aber die Erweiterung ist nicht unbedingt überall verfügbar, v.a. nicht vor PHP 5.4. Die iconv Erweiterung bietet mit //TRANSLIT eine vergleichbare Möglichkeit an, aber auch diese ist nicht unbedingt verfügbar und, soweit ich weiß, auch nicht universell. Trotzdem vielleicht sinnvoll, das optional anzubieten.

Und dann gibt es natürlich noch diverse "Userland" Implementierungen. Sollte man ggf. mal genauer prüfen, obwohl ich eher zu einer "standardisierten" Implentierung tendiere.

Solch eine Transliteration könnte vielleicht auch für den Filebrowser sinnvoll sein, damit Anwender erst gar nicht in die Verlegenheit kommen, Dateinamen mit Nicht-ASCII-Zeichen auf dem Server zu haben, die in der Folge diverse Probleme verursachen können.

[svasti]

Bei 1.6.6 ist dies ziemlich weit unten und war leer die Felder, hat das nie gesehen.

Mir ging es auch so, und darum haben wir diese Felder bei 1.6.7 nach oben geholt.

ist Christophs Plugin move_XH sehr nützlich

dazu wollte ich noch sagen, dass das dieses Plugin ein Protokoll der Seitenaufrufe führt, die ins Leere gehen (404). Das kann man sich ab und zu anschauen und dementsprechende Umleitungen einbauen. Da findet man dann z.B. die von Facebook verunstalteten LInks und kann passende Weiterleitungen eingeben.

MIttelfristig (XH 1.7?) würde ich mir aber wünschen, dass zumindest optional eine möglichst allgemeine Transliteration verfügbar ist

+1

könnte vielleicht auch für den Filebrowser sinnvoll sein

Oh ja, "ÜÖÄ Foto.jpg" -> "ueoeae-foto.jpg"

[cmb]

MIttelfristig (XH 1.7?) würde ich mir aber wünschen, dass zumindest optional eine möglichst allgemeine Transliteration verfügbar ist

+1

könnte vielleicht auch für den Filebrowser sinnvoll sein

Oh ja, "ÜÖÄ Foto.jpg" -> "ueoeae-foto.jpg"

Tja, iconv()s ASCII//TRANSLIT bringt uns wohl nicht wirklich viel, da Umlaute mit vorangestelltem " transliteriert werden (ä → "a). Das sieht bei Transliterator::create('Latin-ASCII') schon eher wie gewünscht aus, aber für nicht "Latin" Sprachen müsste man wohl weiter kombinieren, wenn das überhaupt funktioniert.

Ansonsten gibt es Urlify und Slugify, die auf den ersten Blick einen guten Eindruck machen. Beide haben eine sehr überschaubare Code-Base, und wären für unsere Zwecke vielleicht schon völlig ausreichend.

Wer will, kann sich ja Urlify jetzt schon einbauen.