Gelöst: vBulletin Suche Sonderzeichen und Umlaute

Ok, neue PN ist da. Bin jetzt wieder auf der "nw-forum-neu"

Mensch, jetzt kopiert der schon den Token zur DB mit.....

Zitat von Alex07

und er steht auf [SIZE=13px]utf8_general_ci, also das words. weiss nicht ob man das ändern sollte[/SIZE]

Wo meinst Du das. In der neuen nicht.
Die Tabelle ja, aber nicht die Spalte

Name        Typ            Kollation
wordid    int(10)
word        varchar(50)    utf8_bin

Hier ist nun kein Unterschied zu meiner Test-DB. Beide Spalten sind utf8_bin. Die Tabellen uft8_general bzw. latin1. Da ist nun kein Unterschied mehr.

Der Unterschied ist nur. Du hast alte Importdaten, ich nicht.

Klasse Idee, die hatte ich eben auch. Kommt Zeit, kommt Rad. Kommt viel Zeit, kommen viele Räder. Also morgen machen wir dann einen Zweiradhandel auf

Gute Nacht!

Was mir jetzt eben noch so einfällt. Wäre vielleicht mal ein Versuch, mit den alten Daten zu arbeiten, so richtig, nicht nur mit der DB. Weil, wer sagt denn, dass nur weil wir auf die gleiche DB zugreifen und den gleichen PMA haben, auch unsere Installation und insbesondere das ACP gleich ist?

Kannst Du die nochmal spiegeln, also die "seo-nw", nicht die "nw-forum-neu", allerdings dann auch in Verbindung mit deiner vBulletin-Installation? Also, dass das Testsystem quasi komplett identisch ist (ein Clon von gestern Abend). Datenbank von gestern Abend, Deine jetzige Installation und Addons, falls welche drinnen sein sollten? Also komplett seo-nw.de (ohne Subdomänen) und was dazu gehört?

Dann müsste man doch voll drauf zugreifen können, inkl. Forum und ACP. Dann könnte man dort auch mal "debug" und "debug_sql" anwerfen. Vielleicht sieht man dann ja mehr. Weil, es ist auffallend, dass der fehlerhafte Suchindex immer nur auf den alten Posts beruht.

Möglich wäre dann auch mal, den Suchindex komplett zu löschen und gelöscht zu lassen und mal nur einen Datensatz gezielt neu generieren zu lassen. Also nicht alle, keine JS-Weiterleitung und so. Nur ein Datensatz. Muss man sich ja quasi nur den richtigen rauspicken und mit dem Testen. Da braucht es dann ja nicht immer alles. Den einen erstellen lassen, nachsehen ob es passt, wenn nicht wieder löschen, ändern, wieder den einen erstellen lassen etc.

Klar, es kann ein Bug sein, aber ehrlich gesagt glaube ich daran nicht, da die direkte Suchindexerstellung beim Posten geht (bei beiden Systemen) und die manuelle Suchindexerstellung über den ACP nur bei Dir versagt und das auch nur bei den alten Daten. Wäre das ein genereller Bug, dann müsste die auch bei mir versagen, mit der nagelneuen Installation. Das tut sie aber eben nicht. Wir haben den gleichen Server, die gleiche MySQL-Installation. Nur die Daten an sich sind jetzt noch definitiv unterschiedlich und möglicherweise unsere vBulletin-Installationen.

Zitat von Synonym

Mein Post 88714 stimmt auch nicht mehr. Da stehen jetzt lauter ???? Die waren vorher nicht da. Das hat mit dem Suchindex aber nix zu tun.

So, die ????, die vorher nicht da waren, dann plötzlich kamen, ohne dass da was geändert wurde, sind jetzt wieder weg und die Sonderzeichen wieder da .... Fast so, als ob der die Daten aus einem falsch Codierten Cache gezogen hatte.

Zack, und jetzt sind die wieder weg

Mi scias, kie vi estis ?tiu unde ai fost ?? ?????? ????? ??????? ?? ?????

Tzz, wieder da ...

Und das liegt am Cache, zumindest die stetig wieder verschwindenden Sonderzeichen.
Siehe DB:

Created: 2014-04-01 09:15:40
Expires: 2014-04-08 09:15:40

Also 7 Tage.

Deine forum_cache steht auch auf latin1_swedish_ci
ebenso die Spalte forum_cache.data

Also das muss erst mal alles gerade gebogen werden, aber nicht hier im Live-System. Da muss ein Spiegel her.

Keine Ahnung, aber was ist, wenn die Suchindexerstellung auch Daten in den Cache schreibt und von dort wieder holt? Wäre möglich. vb schreibt da ja so ziemlich alles rein und man sieht ja auch, dass er ihn verwendet, obwohl Du ihn ja anscheinend komplett deaktiviert hast. Dann wäre hier auch wieder ein Sprung von utf8 (text) -> latin (cache) -> utf8 (words)

Отречёмся

10 zeichen: suchstring: wldepabfri

Ja, Zeit ist gerade wenig da. Hänge ja an der Buchhaltung. Aber eine Sache ist mir noch aufgefallen und das ist seltsam.

Aber soviel dazu erst mal: Ich kann die fehlenden Sonderzeichen in der "words" bei mir reproduzieren!!! Ich kann es "erzwingen" und "verhindern". Aber das testen wir in einem Clon.

Erst mal wie ich drauf kam: Ich hatte als Sprache Englisch laufen, da ich das Deutsche zerschossen hatte. Hab da nun wieder das original drauf. Mit Einstellung bei "local" = "de_DE", so wie bei Dir. Dann habe ich das deutsche aktiviert, Systemcache gelöscht, Suchindex gelöscht und neu erstellt. Zack, alle Umlaute in der forum_words waren weg.

Hin und her versucht, neue Sprache installiert etc. "local" gelöscht und versucht. Da geht geht der Suchindex, aber die Seite hat falsche Zeiten. Also wieder "de_DE" eingetragen. Und... Nichts und, das System hat die Daten gar nicht gespeichert... Mehrfach versucht, nicht gespeichert (und ja, die anderen Felder darunter sind auch ausgefüllt). Direkt in der DB geändert und naja, Suchindex geht wieder nicht. Zurück zu englisch -> geht wieder. Deutsch -> geht nicht. Also die "local" mal auf einen gänzlich falschen Wert gesetzt "yx_YX" und siehe da, jetzt geht der Suchindex auch und das Datum / Zeit stimmen. Ok, kann es aber auch nicht sein, also bei Dir nachgesehen, was Dein Server so alles kann. Da gibt es z.B. "de_DE.UTF-8". Also das eingetragen. Und siehe da, das geht auch!

en_US geht
de_DE.UTF-8 geht
de_DE geht nicht
yx_YX geht

Ich habe zwar keine Ahnung, was Datum oder Zeit mit dem Suchindex zu tun haben, aber sobald ich da "de_DE" drinnen stehen habe, geht der manuelle Index nicht mehr, da fehlen alle Sonderzeichen, wie bei Dir (-> hundebrste ohne ü). Die normale Erfassung über normale Posts geht weiterhin richtig, auch wie bei Dir.

So, nach nun über 200 Posts dazu. Das Problem müsste erledigt sein.

Auch hier, wie beim Datum.

Ursache: Die manuelle Suchindexerstellung im ACP nutzt die "local"-Einstellungen. Diese müssen bei einer UTF-8-Seite de_DE.UTF-8 sein, denn de_DE selbst verwendet nur den ISO-Zeichensatz, der keine Umlaute kann. Wenn ein Post neu geschrieben und in den automatisch Index aufgenommen wurde, dann ging es bisher, da dort die PHP-Funktionen entsprechend UTF-8 verwendet werden. Die manuelle Erstellung greift aber auf die "local"-Werte zurück.