Beiträge von Synonym

    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?

    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.

    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.

    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.

    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?

    So, meine Empfehlung da nun, auch wenn das durchaus aufwändig ist und dauert.... Ist aber nur meine Empfehlung, die Entscheidung musst Du treffen.

    1. Im ACP den Suchindex löschen lassen (Link oberhalb dem Formular in der Beschreibung)
    2. Löschung bestätigen
    3. Suchindex neu erstellen

    Deine Ängste bezüglich der dann möglicherweise wieder falschen Sonderzeichen kann ich Dir eigentlich nehmen. Nee, nehmen nicht, aber so auch nicht wirklich bestätigen. Die Sonderzeichen im Searchindex sind jetzt schon falsch bzw. fehlen halt einfach. Also kann es nicht falscher werden, nur besser oder genauso falsch.

    Die Daten zieht er sich aus der forum_text und dort scheinen die Sonderzeichen richtig zu sein, habe zumindest gestern auf die Schnelle keine falschen gefunden von den üblichen ö, ü, ä und ß.

    Ja, das musst Du auch. Die archive.php oder auch die archive.sh müssen auf der Console ausgeführt werden und dort eben vorzugsweise per Cron. Hat schon seinen Grund, warum Piwik den Ordner, wo die drinnen liegen, als "cron" bezeichnet hat ;)

    Manuell für die URL-Zeile gibt es keinen Request. Wenn Du das benutzerabhängig machen willst, dann nur über das Dashboard selbst, also dass der bei einem Zugriff darauf die Daten archiviert. Das ist aber nicht zu empfehlen. Letztendlich macht das Dashboard dann auch nichts anderes, als den Prozess per curl zu starten und das arbeitet auch im Hintergrund als "Konsolenprozess".

    Als direkter Browseraufruf macht das auch nicht viel Sinn, denn das Script gibt nur Logdaten aus, keine sonstigen Inhalte. Auch ist es per Browseraufruf an die /apache2/php.ini gebunden und deren Timeouts sind wesentlich geringer als die von cli. Und drittens würde, selbst wenn die php.ini nicht zum Abbruch führt, der Browser selbst abbrechen und irgendwann sagen "der Server reagiert nicht" oder "Zeitüberschreitung" oder "Netzwerkverbindung zu langsam".