Contenido Update - 4.6.15 auf 4.8.12

[drive]

Hallo zusammen,

nach einem Update von Con. 4.6.15 auf 4.8.12 sind mit die Zeichen aus der russischen Sprache des Hauptmandanten verloren gegangen.
Habe die Datenbank vorher in UTF-8 konvertiert.

In der Datenbank finde ich in der `pref_cat_lang`.`name` auch nur noch Wortschnipsel bis zu Umlauten. (Bilder im Anhang)

Hat jemand eine Idee wie ich das Problem umgehen kann?
Wenn ich die Datenbank in UTF8 Umwandel müssten doch normal alle Zeichen so übernommen werden oder nicht?

Server Umgebung (Hosteurope Vhost):
PHP Version 5.2.4-2ubuntu5.10
memory_limit 256M
MySQL Version 5.0.51a-3ubuntu5.5
MySQL-Zeichensatz: UTF-8 Unicode (utf8)

EDIT:
Den Speicher für PHP wurde schon hochgesetzt, da früher immer angezeigt wurde, da angeblich zu wenig Speicher zugewiesen war. Was mir noch aufgefallen ist, in dem DB-Dump aus der alten DB steht zum Beispiel folgender INSERT:

Code: Alles auswählen

INSERT INTO `con_cat_lang` (`idcatlang`, `idcat`, `idlang`, `idtplcfg`, `name`, `visible`, `public`, `status`, `author`, `created`, `lastmodified`, `startidartlang`, `urlname`) VALUES (317, 6, 4, 668, 'ÄØàÜÐ', 1, 1, 0, '', '0000-00-00 00:00:00', '2007-04-13 14:53:57', 0, 'AeaUe');

Ich weiß nicht genau wie der russische Text aussehen müsste, aber es sieht komisch aus, oder was meint ihr?

Noch was ganz unabhängiges dazu:
Ist es später eigentlich möglich, die action_log über ne Datei zu parsen? Die nimmt einen größeren Teil der DB in Anspruch.

Gruß
drive

[xmurrix]

Hallo drive,

wie hast du die DB übernommen, export/import über phpMyAdmin?
Vielleicht wäre es besser, wenn du das über die Shell machst.

..Habe die Datenbank vorher in UTF-8 konvertiert...

Wie hast du die DB konvertiert, hat du den Zeichensatz der Verbindung auf UTF-8 umgestellt?

Falls du noch einn Backup der 4.6.15 er Version hast, könntest du versuchen, ein Upgrade auf die 4.8.12 zu machen. Du solltest aber vorher die Tabelle "con_mod_history" (falls "con_" das Prefix bei dir ist) von sehr alten Einträgen bereinigen. Die wird im Laufe der Zeit voll und das Upgrade versucht, alles als XML in das Dateisystem zu exportieren. Dabei kann es schnell zu einem Überschreiten der gesetzten memory_limit kommen.

...Ist es später eigentlich möglich, die action_log über ne Datei zu parsen? Die nimmt einen größeren Teil der DB in Anspruch...

Die action_log kann im Laufe der Zeit stark anwachsen. Eine Umstellung des Logging auf Filebasis ist meiner Meinung nach nicht ideal, da man sich dabei andere Probleme einhandeln kann. Es wäare aber wünschenswert, wenn man die maximale Anzahl der Logeinträge konfigurieren könnte, z. B. 10000 - dann werden ältere Logeinträge gelöscht und/oder zu Archivzwecken in eine Datei gesichert.

Gruß
xmurrix

[drive]

Die DB war leider sehr groß, daher hab ich zuerst ein Dump über PHPMyadmin gemacht und anschließend partiell die Tabellen wieder über PHPMyadmin eingefügt.
Den Dump habe ich vorher mit einem Editor geöffnet und als UTF8 gespeichert.

Wenn ich den alten Dump upgraden will, muss ich doch von MySQL 4.x auf 5.x wechseln und dadurch auch UTF8 nutzen oder nicht?
Was ich nicht verstehe, ist das er die DB-Einträge im UTF8-Format nicht erkennt.

Notiz:
Es handelt sich hier um einen Serverumzug von 1+1 Webpack auf Hosteurope Vhost (inkl. Update).
Shell Rechte habe ich nicht / müsste ich mir extra besorgen.

EDIT:
Hier noch eine Grafik von dem Charset der Russischen Sprache.
Die Artikel von früher werden auch korrekt dargestellt, nur die Kategorien und ein Teil des Backends ist betroffen.

Details zur Russischen Sprache in Contenido.

sprache_details.jpg (23.75 KiB) 3841 mal betrachtet

Seltsamerweise zeigt er mir im Sprachenwechsel in Contenido auch alle Umlaute "russisch" an. (siehe Anhang)

Komische Darstellung innheralb von Con.

uebersicht.jpg (26.37 KiB) 3844 mal betrachtet

Welche Vorgehensweise ist am besten?

Gruß.
drive

[xmurrix]

Die DB war leider sehr groß, daher hab ich zuerst ein Dump über PHPMyadmin gemacht und anschließend partiell die Tabellen wieder über PHPMyadmin eingefügt.
Den Dump habe ich vorher mit einem Editor geöffnet und als UTF8 gespeichert.

Welches Encoding hat die Dumpdatei? Wenn es russische Zeichen enthält, aber nicht UTF-8 ist, vermute ich dass der SQL-Dump mit falschem Encoding exportiert wurde.

Falls die Berechtigungen es zulassen, kannst du den import/export mit PHP probieren.

MySQL-Backup über die Shell:
http://www.selfphp.de/kochbuch/kochbuch.php?code=56

MySQL-Backup in Datenbank einspielen:
http://www.selfphp.de/kochbuch/kochbuch.php?code=57

Wenn das nicht geht, kannst du es auch mit MySQLDumper (http://www.mysqldumper.de/) probieren. Auf beiden Systemen installieren, aus einem exportieren und in anderen importieren.

...Wenn ich den alten Dump upgraden will, muss ich doch von MySQL 4.x auf 5.x wechseln und dadurch auch UTF8 nutzen oder nicht?...

Soweit mir bekannt ist, braucht man für die Contenido 4.8 er Reihe nicht unbedingt MySQL 5.x, mit MySQL 4 geht es auch. Ein Upgrade kann aber nicht schaden.

...Seltsamerweise zeigt er mir im Sprachenwechsel in Contenido auch alle Umlaute "russisch" an. (siehe Anhang)...

Das wird vermutlich eine Ursache des exports/imports sein.

...Welche Vorgehensweise ist am besten?...

Das kann man so nicht sagen. Wenn du es mit phpMyAdmin machst, solltest du darauf achten, dass der Export das richtige Encoding enthält. Das Encoding des Dumps kann man beim Exportieren angeben.

Gruß
xmurrix

[drive]

Hallo xmurrix,

vielen Dank für deine Hilfe

Ich habe aber noch eine Frage:
da ich bereits das Update durchgeführt habe und damals MySQLDumper nicht nutzen konnte,
weil dort PHP-Funktionen genutzt werden, die vom Vhost nicht unterstützt wurden (daher die 20 Splits - reichlich arbeit),
weiß ich nicht genau ob sich ein 2tes Update jetzt lohnt.

Beim Dumpen habe ich über phpmyadmin garkeine Möglichkeit zu entscheiden welches Format ich erzeugen will.
D.h. den Export muss ich notgedrungen über MySQLDumper machen und den Import anschließend über phpmyAdmin - danach das Contenido-Update und Konfigurationen vornehmen?

Gruß drive.

[kummer]

Schau mal hier: http://www.ozerov.de/bigdump.php

Mit BigDump können auch sehr grosse Dateien importiert werden. Dann ist ein erneutes Update vielleicht nicht mehr ein so grosses Problem.

[drive]

Also ich habe jetzt noch einige Male probiert die DB zu exportieren.
Einstellungen unter MySQLDumper kann ich nur als Ausgabeformat folgendes auswählen:

Auswahl der Kodierungen für einen Datenbankexport.
Standard: german1

kodierungen.jpg (17.35 KiB) 3830 mal betrachtet

Aber das Exportieren war mir nicht möglich, ohne dass die Tabelle `cat_lang` komische Zeichen beinhaltet.

Sollten die russischen Zeichen in der Datenbank denn auch "russisch" Aussehen oder sind die "umgewandelt"?

Gruß.
drive

[xmurrix]

german1 als Encoding ist vermutlich nicht ideal, hast du es schon mit latin1 probiert?

Das Ergebnis sollte schon richtige russische Zeichen enthalten.

Gruß
xmurrix

[drive]

Ich habe alle im latin Format probiert, aber das Ergebnis in der SQL-Datei war jedes mal wie:

Code: Alles auswählen

INSERT INTO `con_cat_lang` (`idcatlang`, `idcat`, `idlang`, `idtplcfg`, `name`, `visible`, `public`, `status`, `author`, `created`, `lastmodified`, `startidartlang`, `urlname`) VALUES (317, 6, 4, 668, 'ÄØàÜÐ', 1, 1, 0, '', '0000-00-00 00:00:00', '2007-04-13 14:53:57', 0, 'AeaUe');

Nun bin ich hergegangen und habe die cat_lang aus der alten DB in die neue von Hand exportiert/importiert (SQL-Query).

Das klappt auch einwandfrei soweit, jetzt versuch ich nur noch die Aliase russisch darzustellen - habe dazu aber schon etwas im Forum gefunden. (http://forum.contenido.org/viewtopic.ph ... 68#p139577)

Vielen Dank für die Hilfe.
Gruß drive.