Schon wieder ;) Umlaute bei Suche

[fischstäbchenbrenner]

Ich weiß, ein Klassiker... XY-ungelöst
Template "Findle".
links oben das Suchefeld. Genauer: die Suggestions
http://websitebaker.at/wb-templates/template-findle.html

Sobald ich ein Wort eingebe, das einen Umlaut enthält (zb "menü" ) ist vorbei mit Vorschlägen.
(Die Darstellungsfehler in den Vorschlägen spielen hier keine Rolle)

Dasselbe hier:
http://www.oekl-bauen.at/
zb "Ställe"

Wo soll ich den Fehler suchen?
Alles ist auf UTF8 gestellt, MySQL-Zeichensatz: UTF-8 Unicode (utf8), die Kollation der Datenbank-Felder scheint keine Rolle zu spielen.
Nebenbei: Auch mit phpMyAdmin wird nichts gefunden, das einen Umlaut enthält.
ABER: Wenn ich die Felder direkt in phpMyAdmin eingebe, funktioniert es - da wie dort.

EDIT:
Ich habe bei der oekl-Seite jetzt in das Suchscript eingefügt:
$q = utf8_encode ( $q );
Jetzt gehen äöß (ü scheinbar nicht..)
EDIT2:
Es funktioniert nur mit Feldern, deren Kollation auf unicode steht....

Ich verstehe es aber trotzdem nicht.

[gottfried]

Hallo !

Wenn auch in der datenbank keine umlaute sind, sind sie wohl umgewandelt worden durch

etwas wie


http://www.dynamic-webpages.de/php/function.htmlentities.php


da braucht es dann in dem search wohl was ähnliches, vielleicht ?

[amanuen]

Das Problem hab ich auch schon bemerkt

Wie es aussieht, wird dann nach einem leeren String gesucht..da steht dann wahrscheinlich auch:
Ergebnisse für ''

Aber die Suche ist ja eh veraltet
Der fehler liegt also wohl irgendwo im Code und nicht bei den Einstellungen..tipp e ich mal

[fischstäbchenbrenner]

Hallo,
Nein, das meine ich nicht. Die WB-eigene Suche funktioniert schon, auch mit Umlauten. Dass die Suche nicht optimal ist, wissen wir, aber das funktioniert in den meisten CMS so, prinzipbedingt.

Ich rede von den Suggestions in o.g. Template. Da wird nur in title, descriptions, keywords gesucht, und da gibt es keine Entities.

Mein Problem ist schlichtweg: Ich verstehe die Zusammenhänge nicht.

[gottfried]

Hallo !

So auf den zweiten Blick mein ich, es könnte mit

Code:

$q = preg_replace("/[^\\0-9a-zA-Z_\-\.\/]/", "", $q);  // only allow valid chars

im quicksearch.php des templates findle zu tun haben. Mach doch mal den Kommentar bei

 // echo $q ;

raus und schau, was es macht.

 

[fischstäbchenbrenner]

Ja, wenn ich die Zeile auskommentiere, und das einfüge:
$q = utf8_encode ( $q );
dann gehts.

Zusätzlich muss noch auf manchen Sites (aber nicht überall) die Kollation von title, descriptin und keywords auf utf-8 gestellt werden.

Aber das ist "basteln" - nicht verstehen.

[gottfried]

Hallo !

Basteln ist das nicht, ich hab das durch Analyse des Codes gefunden.

Code:

$q = preg_replace("/[^\\0-9a-zA-Z_\-\.\/]/", "", $q);  // only allow valid chars

ist ein "regulärer Ausdruck" ( die Syntax davon kapier ich nie mehr) , der nur Zeichen in einem gewissen Ausschnitt zuläßt, aber z.B keine Umlaute.

Es steht drin , daß
0-9
a-z
A-Z
_ . / ,

erlaubt sind, Umlaute z.B werden also gefiltert.

Es ist schwer zu sagen, was passiert, wenn man im Suchfeld z.B Dropletcode eingibt,
wenn man solche Möglichkeiten nicht rausfiltert. ( [[ ... ]] & = ).
Besser wäre es, die Umlaute in den regulären Ausdruck mitzunehmen, aber das kann ich nicht.

Alle Module, die Eingaben von außen annehmen machen Sicherheitsüberprüfungen.
Ich find, es wäre besser die auszubauen als durch was zu ersetzen, was pauschal alle Zeichen
erlaubt

Code:

$q = preg_replace("/[^\\0-9a-zA-Z_\ä\ö\ü\Ä\Ö\Ü\ß\-\.\/]/", "", $q);  // only allow valid chars

könnte klappen, aber ich errate das eher weil mir das systematisch vorkommt.
danach vielleicht der utf8_encode

[jacobi22]

Code:

$q = preg_replace("/[^\\0-9a-zA-Z_\-\.\/]/", "", $q);  // only allow valid chars

ist ein "regulärer Ausdruck" ( die Syntax davon kapier ich nie mehr) , der nur Zeichen in einem gewissen Ausschnitt zuläßt, aber z.B keine Umlaute.

dann nimm doch die Umlaute mit 

Code:

$q = preg_replace("/[^\\0-9a-zA-ZÀ-Üà-üß_\-\.\/]/", "", $q);  // only allow valid chars

[gottfried]

dann nimm doch die Umlaute mit  wink

Code:

$q = preg_replace("/[^\\0-9a-zA-ZÀ-Üà-üß_\-\.\/]/", "", $q);  // only allow valid chars

Ja, das wär aus Sicherheitsaspekten sicher besser.

prima, daß jacobi22 regexp besser kennt als ich.

der utf8_encode könnte hinterher aber zusätzlich dennoch nötig sein

[jacobi22]

mal theoretisch, weil ich nun lokal überhaupt keine Probleme habe

wie wär es denn mit mit einem else für den Fall, das die uncodierte Suche keinen Erfolg = Treffer bringt

Originalcode:

Code:

if($res->numRows() > 0) {
                while($row = $res->fetchRow()) {
                        $menu_title = $row['menu_title'];
                        $counter ++;
                        $link = WB_URL.PAGES_DIRECTORY.$row['link'].PAGE_EXTENSION;

                        //$p_id = $row['page_id'];
                        $ergtext .= '<li><a href="'.$link.'">'.$menu_title.'</a></li>
                        ';
                        if ($counter > 19) { break; }
                }
        }

geändert

Code:

if($res->numRows() > 0) {
                while($row = $res->fetchRow()) {
                        $menu_title = $row['menu_title'];
                        $counter ++;
                        $link = WB_URL.PAGES_DIRECTORY.$row['link'].PAGE_EXTENSION;

                        //$p_id = $row['page_id'];
                        $ergtext .= '<li><a href="'.$link.'">'.$menu_title.'</a></li>
                        ';
                        if ($counter > 19) { break; }
                }
        }
else
{
$q = utf8_encode ( $q );
        $theq = "SELECT * FROM `".TABLE_PREFIX."pages` WHERE visibility='public' AND searching=1 AND CONCAT(`page_title`, `menu_title`,`description`, `keywords`) LIKE '%".$q."%' LIMIT 0 , 30";
        $res = $database->query($theq);
        if($res->numRows() > 0) {
                while($row = $res->fetchRow()) {
                        $menu_title = $row['menu_title'];
                        $counter ++;
                        $link = WB_URL.PAGES_DIRECTORY.$row['link'].PAGE_EXTENSION;

                        //$p_id = $row['page_id'];
                        $ergtext .= '<li><a href="'.$link.'">'.$menu_title.'</a></li>
                        ';
                        if ($counter > 19) { break; }
                }
        }
        }

[gottfried]

ja ... stimmt schon. Alle haben viel zeit reingesteckt.

Eigentlich sollte der Browser doch das mit dem Zeichensatz regeln, wenn das template entsprechend codiert ist,
oft sieht man   dort .... (DEFAULT-CHARSET) else utf-8

dann läßt der reguläre Ausdruck aber noch immerkeine Umlaute durch was
a) lästig
b) sicherer ist

dem könnte man mit einer geänderten regexp abhelfen (jacobi hat oben den Vorschlag geliefert)

wenn der Default_Charset und der in der Datenbank ohne templateänderung
(ich glaub z.B FG erzwingt UTF-8 in der Datenbank ohne Rücksicht auf default)
nicht übereinstimmt , wäre jacobi22 Anpassung schon sehr hilfreich ,
wenn vorher die regexp den Eingabestring auf erlaubte Zeichen abprüft.
Die weglassen halt ich eben für ein Risiko.

 

[fischstäbchenbrenner]

(ich glaub z.B FG erzwingt UTF-8 in der Datenbank ohne Rücksicht auf default)

Das ist keine Lösung, sondern Ignoranz.
Die Foldergallery ist schon lange kein Musterbeispiel mehr.

Sieht aus, als gäbe es keine allgemeine Lösung; aber hinreichende Strategien für Korrekturen.

[gottfried]

(ich glaub z.B FG erzwingt UTF-8 in der Datenbank ohne Rücksicht auf default)

Das ist keine Lösung, sondern Ignoranz.
Die Foldergallery ist schon lange kein Musterbeispiel mehr.

nützlich find ich sie schon. Bei der bleibt die Seite weiß, wenn man Umlaute in den Bildernamen hat.