Beiträge von Synonym

Bei den Privaten Nachrichten werden keine Uhrzeiten angezeigt, nur das Datum.

In allen alten privaten Nachrichten sind die Umlaute falsch.

Zitat

Synonym ist jetzt Mod und Admin zugleich

Wenn ich ehrlich sein soll, dann hört sich das ja schon fast erschreckend an "Hausmeister mit erweiterten Rechten" würde das eher beschreiben. Der "Admin" bleibt der Admin und da gibt es nur einen. Und unsere beiden "Mods" bleiben auch die Mods. Schließlich hat jeder seine Erfahrungen mit seinem "Berufsstand".

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.

Отречёмся

10 zeichen: suchstring: wldepabfri

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)

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.

Tzz, wieder da ...

Zack, und jetzt sind die wieder weg

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

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.

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.

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!

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.

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

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

du bist auch in der richtigen db? nw-forum-neu...

Nein, bin jetzt wieder in der "seo-forum-extra". In die neue komme ich nicht mehr rein und die PM mit den Zugangsdaten ist auch weg.

Siehe mein Post 193. Hier ist nun eine andere Datenbank aktiv. Das ist nicht die, auf der ich war und von der ich die Daten gepostet habe.

Also, entweder ist es jetzt schon zu spät oder ich weiß nicht. Oben hatte ich Abfrageergebnisse gepostet, die waren von der "neuen Datenbank". Da waren die Umlaute in der Db vorhanden und die Spalte auf utf8_bin. Dort kann ich mich allerdings nicht mehr einloggen. Die PM von Dir mit den Zugangsdaten ist auch weg. In der jetzigen DB ist wieder utf8_general_ci

Ach Moment, Du verdrehst da gerade was. Die forum_word.words steht schon auf uf8_bin (latin1 wegen den sonstigen Sonderzeichen nicht möglich), Die ist auf utf8_bin. Da ist auch "schon" und "schön" getrennt drinnen, was vorher nicht der Fall war. Das Problem besteht also nur bei der Übernahme von den alten Posts.

Zitat von Alex07

zimt note bei guppys zaubertrank. müssen wir also auch die tabelle von den einträgen auf swedish umstellen, würde dsa gehen?

Das kann ich so nicht sagen, da an dem Import irgendwas vermurkst ist und nicht klar ist, was genau. latin1_swedish oder utf8_general ist bei ö ü ä eigentlich egal, denn das können beide.