Gelöst: vBulletin Suche Sonderzeichen und Umlaute

  • das bekomme ich immer als Mail. Das kommt immer bei einem post mit umlauts :(
    Vielleicht hilft das ja. Die vom VB Support haben auch die DB und Report ist erstellt. War aber eines der ersten Sachen die ich gemeldet habe.

  • Ach Du heiliger Mist, bei jedem Umlaut eine Fehlermail .... Allerdings kann man nach der Mail nun nicht gehen, denn dort wäre der Umlaut falsch. Fraglich nun, ob der nur in der Mail falsch ist oder versucht wird, falsch abzusetzen, also die Query wirklich so ist.

    Frage: Wie lange dauert es denn, bis der Suchindex neu erstellt ist und könnte man das während dem Tag machen? Oder geht da der Server in Schlafmodus?

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • nee dauert etwa halbe stunde den neu zu erstellen. Nach der Erstellung sind allerdings auch in der Suche die Umlaute wech.
    Ja bei jedem Umlaut in einem Post ne Fehlermail.

    Der Server kann das ab, fällt gar nicht auf das er arbeitet. :) Sind genug Ressourcen vorhanden.

  • ok, ist gelöscht, ich sehe es. Daten sind alle weg. Nun bitte neu aufbauen lassen. Habe wieder zwei Post mit Kennungen versehen, mal sehen, welche der nun zieht.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Also ich kann aber schon mal einen Zwischenbericht geben. Hier in der DB hackt es irgendwo. Hundeb(mit ü)rste (will das Wort extra nicht schreiben), sondern katzenbürste, wurde wieder zu "hundebrste". Das Ü wurde also einfach wieder verschluckt. Wenn ich nun richtig liege, dann ist dieses katzendingens dann richtig in der DB. Also richtig sind die Wörter, die beim Posten direkt gesendet werden.

    Falsch sind die Dinger, die per Admin-Aufruf neu gebildet werden. Das aber nicht allgemein bei vBulletin, sondern spezifisch hier im Forum. Bei mir sind die alle richtig, wenn die im Post richtig waren.

    Aber mal sehen, welche der beiden Tierbürsten dann letztendlich wirklich da ist.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Ok, sehe es mir gleich an. Bin gerade an was anderem dran. Nee, auch Suche, aber eher die Frage nach dem wie. Daher hier mal ein paar Querys, die mein System ausspukt.


    Das waren alle Query für den Rebuild des Suchindexes für einen Datensatz. Man sieht hier also eigentlich auch, dass in die Worttabellen nichts geschrieben wurde.

    Jetzt mache ich das ganze nochmal mit zuvor gelöschten Tabellen.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Das ist ein schöner Mist, wenn man da ständig die DB wechseln muss ...

    So, das ganze nun nach gelöschten Daten:


    Wie man sieht, nun werden die Tabellen benutzte, also die searchtowords und die words. Auch sieht man, dass die Daten richtig kodiert sind.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Man sieht auch, dass der die Datenbank "words" vorher abfrägt, ob das Wort schon drinnen ist (SQL 5). Wenn nicht, dann folgt der Insert (SQL 6). Bei 7 fragt er dann die neuen wordids ab um die dann bei 8 in die Wortlisten zu packen.

    Genau SQL 6 bringt bei Dir die Fehlermeldung. Wohl auch daher, weil der Select davor sagt, "nee, wort ist nicht drinnen". Und das wohl damit begründet, dass der da irgendwo ein Problem mit dem Zeichensatz hat.

    Frage: Die Einstellung $config['Mysqli']['charset'] = 'utf8'; in der config.php hast Du, oder?

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Hm, ich komme da nicht weiter. Fakt ist, die Kollation der Spalten unterscheidet sich bei uns. Was anderes sehe ich hier nicht als Unterschied. Den Query-Debug kann man bei Dir leider gar nicht laufen lassen, denn es geht nur überall oder nirgends.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(