Bernds Rappelkiste

Serendipity sichern

Bevor es los geht, sollte man sich natürlich erstmal eine Sicherung aller Daten und Datenbanken anlegen. Sollte im späteren Verlauf irgendwas kaputt gehen…ich bin nicht schuld und auch nicht verantwortlich zu machen

alte Media-Daten übertragen

Zuerst muss man seine alten Daten (in meinem Fall Bilder) von Wordpress nach Serendipity bringen. Üblicherweise liegen diese Daten im Verzeichnis /wp-content/uploads/ von Wordpress. In der S9y-Installation hab ich mir einfach unter /uploads/ einen Ordner wordpress-content angelegt und den Inhalt da rein geschoben. Auf diesen Unterordner könnte man wohl auch verzichten, da bei beiden Systemen der Ordner uploads heißt, aber ich mach es jetzt halt mal so

Wordpress-Daten anpassen

Als nächstes muss man die Wordpress-Datenbank im SQL/Text-Format exportieren (z. B. mit phpMyAdmin) und mit einem Texteditor bearbeiten. Unter Linux kann man sich einfach vim/nano/gedit schnappen, unter Windows z. B. Notepad++. Speziell unter Windows sollte man das integrierte Notepad nicht nehmen, da dieses eine Dateigrößen-Beschränkung hat (oder hatte?) und auch sonst nicht sehr komfortabel ist.

Je nach Editor muss man jetzt einfach über die Suchen/Ersetzen-Funktion die Dateipfade von alt zu neu anpassen.

Da ich gegenüber meiner alten Wordpress-Installation neben dem System auch die Domain gewechselt habe, sieht das bei mir wie folgt aus:

Suche nach:    http://blog.bernd-distler.net/wp-content/uploads/
Ersetze durch: http://bernd.distler.ws/uploads/wordpress-content/

Hier muss man allerdings sagen, dass es (bei mir) noch einige Ersetzungen mehr waren, da zum einen die Umlaute/Sonderzeichen kaputt waren (irgendwas aus Wordpress mit UTF8-Konvertierung, was weiß ich) und noch viele alte Pfade aus einer noch älteren WP-Installation vorhanden waren Aber das ist mehr oder weniger Fleißarbeit und macht Sinn, wenn man eh schon am anpassen ist.

Danach kann man die modifizierte Wordpress-Datei wieder per phpMyAdmin in die Datenbank einpflegen. Entweder man überschreibt die alten Daten der man legt sich zur Sicherheit eine neue Datenbank an, in der die neue Datei eingelesen wird, dann hat man die alte Datenbank noch funktionsfähig als Sicherung laufen. Letzteres wäre natürlich empfohlen

Serendipity-Wordpress-Importer anpassen

Als nächstes kommen wir zu einem Problem, das so eigentlich keines ist. Ich möchte einfach nur, dass importierte Artikel nicht automatisch öffentlich sind (ist viel alter Mist dabei, den keiner sehen soll ). Die Lösung ist relativ simpel, indem man die importierten Beiträge einfach als Entwurf deklarieren lässt. Dies muss jedoch im Import-Modul angepasst werden, da die Oberfläche dies nicht erlaubt.

Dazu muss man in der Datei /include/admin/importers/wordpress.inc.php etwa in Zeile 294 die Zeile

'isdraft'        => ($entries[$x]['post_status'] == 'publish') ? 'false' : 'true',

gegen

'isdraft'        => 'true',

tauschen. An der Stelle nochmal vielen Dank an Garvin für den Tipp

Da ich in meinem Blog auch immer der einzige Benutzer war und bin, habe ich im Importer auch noch etwas geändert, damit alle Beiträge automatisch meinem Serendipity-Benutzer zugeordnet werden. Dafür habe ich einfach etwa in Zeile 299 die authorid fest für meinen Benutzer vorgegeben.

 'authorid'       => 1);

Wer nicht weiß, welche ID welcher Benutzer hat, einfach in der Datenbank nachsehen oder in der Benutzerverwaltung von Serendipity. Wenn man dort auf „Vorschau” geht, steht die ID vor dem Benutzernamen in der URL.

Datenbank in Serendipity importieren

Im Admin-Bereich kann man nun den Punkt “Daten importieren” auswählen und das Wordpress-Datenformat wählen. Im nachfolgenden Fenster muss man dann die erforderlichen Angaben dazu machen, was größtenteils selbsterklärend sein dürfte.

Der einzige Punkt, worüber ich gestolpert war bzw. was ich beim ersten Versuch vergessen hatte, ist „Datenbank-Prefix”, hier muss man (im Standardfall) wp_ eintragen.

Den Punkt „Soll versucht werden, HTML-Instanzen automatisch zu konvertieren?” sollte man wohl auf Nein stellen. Das Teil versucht irgendwie alte kaputte Umlaut-Formatierungen zu konvertieren, aber was ich so über Tante Google gefunden habe, klappt das nicht so recht. Man sollte lieber vorher in der exportierten Wordpress-Datenbank die nötigen Ersetzungen machen, wie ich es auch für die Domainpfade beschrieben hatte. Ggf. muss man halt einfach nochmal von vorne anfangen, wenn die Umlaute nicht passen

Danach sollte der Import im Idealfall durchlaufen.

Probleme beim Import

Leider war bei mir natürlich nicht der Idealfall und nach ca. einer Minute kam immer eine Server-Fehlermeldung.

Laut Fehlermeldung hätte das Problem wohl an einem zu geringen Time-Out von PHP/MySQL/CGI liegen sollen, aber auch eine Erhöhung der Wartezeit brachte keinen Erfolg.

Nun ist es dummerweise auch so, dass die Statusseite zum Import erst generiert wird, wenn der Import abgeschlossen ist. Treten vorher Fehler auf und das Script kann nicht abgeschlossen werden, erhält man überhaupt keine Rückmeldung bzw. man kann nirgendwo nachsehen, an welcher Stelle es hakt.

Ich musste daher die Datei /include/admin/importers/wordpress.inc.php ein bisschen erweitern, damit die Ausgabe der verschiedenen Debug-Meldungen sofort in eine Textdatei erfolgt, damit man nachvollziehen kann, an welcher Stelle ein Fehler sein könnte.

Erstmal muss man die Funktion import() erweitern, damit eine Datei verwendet werden kann…

function import() {
        global $serendipity;
        static $debug = true;
        $debugfile = fopen('import.log', 'a');

Der Parameter ‘a’ bei fopen sorgt dafür, dass die Datei entweder erstellt oder (falls sie schon da ist) zum anhängen geöffnet wird. Die Datei import.log selbst liegt dann im Hauptverzeichnis von Serendipity.

Im weiteren Verlauf der Funktion stehen immer wieder Zeilen in der Art

if ($debug) echo "Importing category associations (WP 2.3 style)...<br />\n";

Diese muss man ein bisschen anpassen, damit der Text in die Datei geschrieben wird…

if ($debug) fwrite($debugfile, "Importing category associations (WP 2.3 style)...\n");

Im Endeffekt also vor und hinter dem Text ein bisschen was ersetzen

Der guten Form halber kann man am Ende der Funktion die Datei wieder schließen lassen:

// That was fun.
fclose($debugfile);
return true;

So erhält man bei Bedarf schon mal eine grobe Richtung, an welcher Stelle der Importer nicht mehr mag.

Ich habe mir dann an ein paar Stellen noch ein paar zusätzliche Abfragen/Ausgaben eingerichtet, um einen genaueren Überblick zu haben (siehe Zeilen mit fwrite)…

Beim Übertragen der Beiträge:

   if ($debug) fwrite($debugfile, "Importing entries...\n");
            for ($x=0, $c = mysql_num_rows($res) ; $x < $c ; $x++ ) {
                $entries[$x] = mysql_fetch_assoc($res);
                fwrite($debugfile, "\n".$entries[$x]['ID']." ".$entries[$x]['post_date']." - ".$entries[$x]['post_title']." gelesen");
                $content  = explode('<!--more-->', $entries[$x]['post_content'], 2);
                $body     = $content[0];
                $extended = $content[1];

                $entry = array('title'          => $this->decode($entries[$x]['post_title']), // htmlentities() is called later, so we can leave this.
                               'isdraft'        => 'true',
                               'allow_comments' => ($entries[$x]['comment_status'] == 'open' ) ? 'true' : 'false',
                               'timestamp'      => strtotime($entries[$x]['post_date']),
                               'body'           => $this->strtr($body),
                               'extended'       => $this->strtr($extended),
                               'authorid'       => 1);

                if (!is_int($entries[$x]['entryid'] = serendipity_updertEntry($entry))) {
                    printf(COULDNT_SELECT_ENTRY_INFO, mysql_error($wpdb));
                    echo "ID: {$entries[$x]['ID']} - {$entry['title']}<br />\n";
                    return $entries[$x]['entryid'];
                }

                $assoc['entries'][$entries[$x]['ID']] = $entries[$x]['entryid'];
                fwrite($debugfile, "\n".$entries[$x]['post_date']." - ".$entries[$x]['post_title']." importiert");
            }
            if ($debug) fwrite($debugfile, "Imported entries...\n");

Beim Übertragen der Kommentare:

fwrite($debugfile, "\n".$comment['timestamp']." ".$comment['body']." gelesen");
serendipity_db_insert('comments', $this->strtrRecursive($comment));
if ($comment['status'] == 'approved') {
      $cid = serendipity_db_insert_id('comments', 'id');
      serendipity_approveComment($cid, $assoc['entries'][$a['comment_post_ID']], true);
}
fwrite($debugfile, "\n".$comment['timestamp']." ".$comment['body']." geschrieben");

Wo das Problem aber nun bei mir tatsächlich lag, kann ich nicht sagen. Ich hatte nur festgestellt, dass trotz Fehlermeldung der SQL-Server weiter sehr hoch ausgelastet war und auch die Log-Datei immer größer wurde. Ich habe also einfach mal gewartet, bis sich an der Log-Datei nichts mehr geändert hatte und auch der SQL-Server wieder normal lief und hab dann in die Textdatei geschaut.

Ergebnis: Alle Beiträge und Kommentare wurden übernommen. Hat mich etwas irritiert, aber ich lebe nun damit und funktioniert hat es ja scheinbar

Aufräumen

Danach beginnt der evtl. mühsamste Teil…

• unnötige Benutzer löschen
• unnötige Kategorien löschen
• alte Beiträge durchsehen, Links korrigieren, Tags vergeben

Den letzten Punkt kann man sich natürlich sparen, wenn man darauf „scheißt” und die Artikel einfach so kaputt übernimmt, wie sie aus Wordpress kommen. Speziell bei Formatierungen kann das aber sehr unschön aussehen. Andererseits macht die Arbeit bei mehreren 100(0) Artikeln keinen Sinn mehr und man lebt wohl am leichtesten damit, wenn der zufällige Besucher eben was kaputtes sieht.