Probleme mit Standard-Suche bei Kyrillisch ...

[Leo]

Hallo Contenido-Gemeinde,

mit der Standard-Suche habe ich momentan ein Problem. Irgendwie werden die kyrillischen Buchstaben in der DB-Tabelle con_keyword nicht korrekt abgespeichert, obwohl ich das Backend und das Frontend auf utf-8 umgestellt habe. Bei dieser Webpräsenz verwende ich Contenido 4.8.15. Soll ich das CMS updaten? Oder bringt ein Update nichts? Habe ich bei der Suche dann immer noch das gleiche Problem. Meine Vermutung: Es liegt an dieser Klasse contenido/classes/class.search.php.

Dank für eure Hilfe! VG Leonhard

[Leo]

So, ein Update bringt leider nichts. Ich habe mich jetzt erst mal durch die Klasse gesucht und eine Notlösung dafür gefunden. Hat niemand das gleiche Problem gehabt??? Die Beiträge im Forum haben mir leider nicht geholfen.

[Leo]

Hat keiner eine Lösung für die Standard-Suche parat?

[Faar]

Ich verstehe nicht so recht Deine Erklärung des Problems.

[Leo]

Also, die kyrillischen Buchstaben werden in der Datenbank verstümmelt abgespeichert. Ich will damit sagen, dass die Buchstaben irgendwo in der Klasse /contenido/classes/class.search.php falsch umgewandelt werden. Es wird in der Klasse mehrmals str_replace verwendet, dies soll bei utf-8 Probleme verursachen. Außerdem gibt es bei der Ausgabe der Suchergebnisse ebenfalls Probleme mit der Kodierung. Die Buchstaben werden irgendwo falsch umgewandelt, bloß wo? VG Leonhard

[Faar]

Hm... ist mit "verstümmelt" nun gemeint, dass in der Datenbank die utf-8 Hiroglyphen stehen oder wirklich verstümmeltes Zeugs?
Dass in der DB utf-8 nicht als Reinschrift vorhanden ist, das ist auch bei Wordpress so. Man kann in der DB die utf-8 Daten bei Wordpress nicht editieren, weil es eben diese Hieroglyphen sind.
Aber verstümmelt sind diese Daten nicht, denn alles ist vorhanden und wird auf der Seite dank des UTF-8 Hinweises als Reinschrift wieder ausgegeben.
Der Zeichensatz in der DB muss also gar nicht auf utf-8 eingestellt sein, weil am Ende die utf-8 Hieroglyphe mit dem richtigen utf-8 Zeichensatz dargestellt wird.

Ich hatte mich in einem nativen Projekt (also ohne CMS von der Stange) mal lange genug damit herum geschlagen und man "sieht" nicht, wann welche Zeichencodierung wirksam ist (das ist eines der größten Schwierigkeiten mit utf-8).
Steht nämlich in der Datenbank alles auf utf-8 und auch die Zeichen sind in utf-8 als Reinschrift in der DB, dann kann man diese z.B. auch nicht mit phpMyAdmin ändern, wenn dieses nicht auch als utf-8 arbeitet, sondern z.B. mit ISO 8859-1.
Dann gibt es echten Datenmischmasch und auf der Seite erscheinen dann z.B. dunkle Rauten mit Fragezeichen drinne.

Nun kannst du dir vorstellen, dass die Suchfunktion im Zweifel nichts finden kann, weil sie nach A (ля) sucht, aber in der Datenbank die utf-8 Hieroglyphen vorhanden sind.
Folglich müsste man dafür sorgen, dass bei der Suche in der DB entweder auch nach den Hieroglyphen gesucht wird oder aber in Reinschrift nach ля.

Bei mir half in meinem Beispiel, dass alle Dokumente auch als utf-8 abgespeichert werden, also besonders die Dateien in denen die utf-8 Zeichen eingegeben werden.
Dabei muss man darauf achten, dass nicht der utf-8 BOM mitgespeichert wird!
In der Folge sind dann die Zeichen die mit str_replace verarbeitet werden, auch utf-8 Zeichen.

Gleiche Erfahrung hat einer gemacht, der in php.net schrieb:

Before spending hours searching your application why it makes UTF-8 encoding into some malformed something with str_replace, make sure you save your PHP file in UTF-8 (NO BOM).
This was at least one of my problems.

Contenido macht das eigentlich auch, dass die eigenen Dateien in UTF-8 umgewandelt werden. Daher findet man dann Plötzlich hier und da die geliebte Raute, besonders im Backend bei den ü = � (dass das immer noch nicht repariert wurde, liebes Contenido Team? ).
Fatal wird es in manchen Modulen, wo z.B. als Trennzeichen drei ßßß stehen (z.B. in der Lightbox Galerie) und die dann als drei ��� dargestellt werden.
So funktioniert der Programmcode dann natürlich nicht mehr.
Aber sobald das Dokument utf-8 ist, hilft es dann, einfach das Zeichen markieren und � wieder als ü zu schreiben und ��� als ßßß, sofern man weiß, was drin stehen sollte.

Ich denke mal, wenn alles andere stimmt, sollte es helfen, die Programm-Datei mit dem str_replace in utf-8 Zeichencode statt ANSI abzuspeichern.
Aber darauf achten, ob irgendwo im Code vielleicht noch Umlaute oder Sonderzeichen stehen, die danach zu � werden könnten.

VG,
Frank

[Leo]

Gibt es mittlerweile eine Lösung für das Problem? Leider funktioniert die Suche mit kyrillischen Zeichen nicht. Gibt es für diese Klasse "class.search.php" ein Beispiel? Wie muss ich die Datei für russisch anpassen?

Vielen Dank vorab!

VG Leonhard

[Leo]

Hallo Contenido-Gemeinde,

also, die Ausführung von Faar habe ich mir schon durchgelesen und verstehe auch was er will. Leider bringt mich das nicht weiter. Anscheinend werden die Zeichen noch mit urlencode oder htmlentities kodiert in die Datenbank con_keyword geschrieben. Außerdem verstehe ich die Funktion removeSpecialChars nicht. Es ist mir schon klar, dass diese Funktion die deutschen Sonderzeichen ö,ü usw. in oe, ue usw. umwandelt. Bloß, macht das nicht bei kyrillischen Zeichen Probleme, besonders wenn man noch str_replace verwendet. Außerdem habe ich mir mal diese Beiträge angesehen. Eine Lösung habe ich hier auch nicht gefunden.

http://forum.contenido.org/viewtopic.ph ... 30#p145594
http://forum.contenido.org/viewtopic.php?f=60&t=30166

Lustig, der eine Beitrag verweist auf den anderen Beitrag und zurück. Da wird mir schwindlig. Dort wird auch erwähnt, dass es sich um einen Bug handelt. Meine MySQL-Datenbank und das CMS sind utf8 gestellt. Daran sollte es also nicht liegen.

Kann sich der jenige bitte mal melden, der diese Klasse "class.search.php" geschrieben hat oder ein Experte, der dieses Class richtig versteht. Wie muss ich diese Klasse anpassen, dass diese sauber mit utf8 läuft. Besser gesagt, mit kyrillischen Zeichen umgehen kann. Oder steht mir irgendwann ein langes Wochenende bevor?

Vielen Dank!

VG Leonhard