Migrationsprobleme Wordpress -> Serendipity

[Lux]

Hi!

Wir haben mit Serendipity-Version 1.6 Probleme ein Blog von Wordpress 3.0 zu importieren.

Die Wordpress-Datenbank liegt sauber konvertiert auf dem gleichen Server.

Wenn wir die Daten importieren, werden die Umlaute geschreddert.

Habt Ihr irgendwelche Tipps?

Danke für jeden Hinweis.

Gruss

Dirk

[Timbalu]

Was heißt 'sauber konvertiert'?
Unterschiede in der 'UTF-8'? Kodierung der Datenbank und ihrer Tabellen, vielleicht?

[Lux]

Was heißt 'sauber konvertiert'?
Unterschiede in der 'UTF-8'? Kodierung der Datenbank und ihrer Tabellen, vielleicht?

Das meine ich mit sauber konvertiert: Tabelle ist in utf8 und der Inhalt ebenfalls.

Vorher war die Tabelle in latin1 und dort hinein wurde in utf8 gespeichert. Das haben wir gerade gezogen.

Interessanterweise sind die Umlaute in Überschriften sauber konvertiert worden.

Gruss

Dirk

[Timbalu]

Spielt nicht die Datenbank selbst als Faktor auch noch eine Rolle?

Wenn dein MySQL in UTF-8 speichert, bedeutet das noch lange nicht, dass PHP auch wirklich UTF-8 bekommt. Es gibt da Optionen, die das ändern könnten.

Bei MySQL wäre die erste Query: »SET NAMES "UTF8"« um sicherzustellen, dass du UTF-8 bekommst…

Ein Versuch wäre es eventuell wert.

[Lux]

Bei MySQL wäre die erste Query: »SET NAMES "UTF8"« um sicherzustellen, dass du UTF-8 bekommst…

Das ist gesetzt. Ich habe jetzt herausbekommen, dass die Option "Soll versucht werden, HTML-Instanzen automatisch zu konvertieren?" die Probleme bereitet.

Umlaute sind jetzt sauber drin, aber die Option sollte gefixed werden.

Gruss

Dirk

[Timbalu]

Umlaute sind jetzt sauber drin, aber die Option sollte gefixed werden.

Mach mal einen genaueren Vorschlag.

[garvinhicking]

Hi!

In der include/admin/importer.inc.php gibts diese Zeile:

Code: Select all

    function strtr($data) {   
        return strtr($this->decode($data), $this->trans_table);
    }
  

Die macht das Replacement der HTML-Entities. Ich vemrute dass entweder a.) das $this->decode() nicht da sein dürfte, odre dass $this->trans_table auch einige Sonderzeichen enthält die im UTF-8 Scope enthalten sind und dann in etwas "falsches" übersetzt werden.

Du könntest es testiwese mal mit dieser Variante probieren:

Code: Select all

    function strtr($data) {   
static $test = false;

if (!$test) {
echo "WILL RECODE EVERY INSTANCE OF: " . print_r($this->trans_table, true) . "<br/>\n";
}

        return strtr($data, $this->trans_table);
    }
  

Das würde dann zum einen extra Debug-Code ausgeben um b) zu prüfen und auch variante a) mal ausprobieren....Lust/Zeit das mal zu testen?

Grüße,
Garvin

[Lux]

Umlaute sind jetzt sauber drin, aber die Option sollte gefixed werden.

Mach mal einen genaueren Vorschlag.

Alle Umlaute sollten sauber kodiert sein, wenn ich die Option mit HTML auswähle.

Gruss

Dirk

[Lux]

Das würde dann zum einen extra Debug-Code ausgeben um b) zu prüfen und auch variante a) mal ausprobieren....Lust/Zeit das mal zu testen?

Das mache ich gerne einmal in einem Testblog, aber momentan rennt uns die Zeit weg.

Gruss

Dirk

[Timbalu]

Alle Umlaute sollten sauber kodiert sein, wenn ich die Option mit HTML auswähle.

Na, diese grobe Richtung habe ich mir schon selber gedacht, aber da ich die Stelle im Code nicht kannte, dachte ich wäre es ev. einfacher, wenn du uns mit diesen Erfahrungsschatz sagen könntest, wo genau in einem Import diese Option "HTML-Instanzen" (was damit auch immer gemeint sein mag...) etwas nicht konvertieren soll.
Zum einen frage ich mich, wozu man diese Option bei einem Import eigentlich benötigt?
Doch wahrscheinlich nur, wenn die beiden Datenbanken eben nicht diesselbe Konvertierung haben (sollen), oder? Vielleicht muss man dies nur genauer in der Optionbeschreibung ausführen?

Das mache ich gerne einmal in einem Testblog, aber momentan rennt uns die Zeit weg.

Das hörte sich aber an, als ob ihr das eigentliche Problem doch schon gelöst hattet, oder?

[Lux]

Na, diese grobe Richtung habe ich mir schon selber gedacht, aber da ich die Stelle im Code nicht kannte, dachte ich wäre es ev. einfacher, wenn du uns mit diesen Erfahrungsschatz sagen könntest, wo genau in einem Import diese Option "HTML-Instanzen" (was damit auch immer gemeint sein mag...) etwas nicht konvertieren soll.

Wie geschrieben, das mache ich gerne in einem Testblog.

Zum einen frage ich mich, wozu man diese Option bei einem Import eigentlich benötigt?

Das konvertieren der HTML-Instanzen gilt ja nicht nur für Umlaute. Momentan haben wir (x)html als Artikel im Blog. Das ist in Ordnung, aber nicht schön.

Doch wahrscheinlich nur, wenn die beiden Datenbanken eben nicht diesselbe Konvertierung haben (sollen), oder? Vielleicht muss man dies nur genauer in der Optionbeschreibung ausführen?

Das mache ich gerne einmal in einem Testblog, aber momentan rennt uns die Zeit weg.

Das hörte sich aber an, als ob ihr das eigentliche Problem doch schon gelöst hattet, oder?

Wir haben einen Stand, mit dem wir weiterarbeiten können. Ja.

Gruss

Dirk

[Lux]

Das würde dann zum einen extra Debug-Code ausgeben um b) zu prüfen und auch variante a) mal ausprobieren....Lust/Zeit das mal zu testen?

Habe es getestet: http://www.deimeke.net/testblog/

Leider gab es nur eine leere Seite als Resultat.

Grüsse

Dirk

[garvinhicking]

Hi!

Leere Seite würde eigentlich einen fatal php fehler bedeuten. Hast du die php.ini mal geprüft oder via .htaccess sichergestellt dass die "display_errors" Anweisung auf "On" steht? Ggf. hast du PHP-Fehlerlogfiles von deinem Provider um die vermutlich entstandenen PHP-Fehler zu sehen?

Grüße,
Garvin

[Lux]

Leere Seite würde eigentlich einen fatal php fehler bedeuten. Hast du die php.ini mal geprüft oder via .htaccess sichergestellt dass die "display_errors" Anweisung auf "On" steht? Ggf. hast du PHP-Fehlerlogfiles von deinem Provider um die vermutlich entstandenen PHP-Fehler zu sehen

Hi Garvin,

da bin ich glücklicherweise mein eigener Provider.

Code: Select all

[Sun Feb 19 12:19:58 2012] [error] [client 178.194.168.179] PHP Fatal error:  Allowed memory size of 134217728 bytes exh
austed (tried to allocate 37754881 bytes) in /srv/www/deimeke.net/testblog/include/admin/import.inc.php on line 112, ref
erer: http://www.deimeke.net/testblog/serendipity_admin.php?serendipity%5BadminModule%5D=import&serendipity%5Btoken%5D=d
ebbaea233389bd307bef801d427a893&serendipity%5BimportFrom%5D=wordpress

Der zweite Import endet ebenfalls in einer leeren Seite, trotz "php_value display_errors on" in der .htaccess.

Gruss

Dirk

[garvinhicking]

Hi!

Ah, okay. Da müsstest Du mal das memory_limit von PHP erhöhen, z.b. 128M oder so. Denn scheinbar braucht der Importer mehr RAM zum Parsen als dezreit erlaubt...

Grüße,
Garvin