WordPress 2.1 – Import-Probleme?

WordPress LogoSeit der Version 2.1 von WordPress gibt es ja endlich eine ordentliche Export-Funktion bei WordPress. Import gabs bekanntlich schon länger. Der war primär dafür gedacht, einen Blog (bzw. Beiträge und Kommentare) von einem anderen System zu übernehmen. Nun gibt es auch eine Export-Funktion, die Beiträge in einem WordPress-eigenen XML-Format exportiert. Der Importer kann dieses neue Format auch entsprechend importieren. Grundsätzlich eine feine Sache.

Ich habe seit Anfang des Jahres auf meinem PC hier im Büro XAMPP mit einer Testinstallation von WordPress laufen. Mit dieser Testinstallation habe ich auch das Theme für diesen Blog hier erstellt und arbeite immer wieder damit, wenn Nachbesserungen am Theme oder andere Experimente (z.B. neue Plugins) nötig sind. Da ist es hilfreich, wenn der Stand der Installation (inkl. Beiträge und Kommentare) auf dem Stand der Live-Installation – also dieses Blogs – ist. Vor Version 2.1 war es dazu nötig einen kompletten DB-Dump zu machen und das SQL-File lokal zu importieren. Eine recht aufwändige Sache, da die Tabelle mit den Settings (Pfad, Domain, etc.) entweder explizit aus dem Dump ausgeschlossen werden oder nach dem Import wieder verändert werden musste.

Seit Version 2.1 besteht das Problem nun – zumindest theoretisch – nicht mehr, da Beiträge und Kommentare einfach über den Export/Import übertragen werden können. Der Rest stellt kein großes Problem dar, da ich in der Regel alle installierten Plugins ohnehin erstmal lokal installiere, ist diesbzgl. ohnehin immer der gleiche Stand vorhanden.

Beim ersten Versuch diesen neuen Weg zum Abgleich der Beiträge und Kommentare zu nutzen, bin ich nun vor einigen Tagen ziemlich überrascht worden. Der Export aus dem Liveblog verlief fehlerfrei. Beim anschliessenden Import-Versuch wurde mir dann nach der Autorenzuordnung eine lange Liste mit importierten und bereits vorhandenen Beiträgen geliefert. „Alles klar“, dachte ich – Pustekuchen. Die neuesten Beiträge waren allesamt nicht vorhanden. Ok – den Import nochmal wiederholt und wieder wurden ein paar Beiträge importiert – ein großer Teil als „bereits vorhanden“ gemeldet. Aber warum? Ich habe doch die gleiche Datei eben schon mal importiert – wie können da nun wieder einige neue darunter sein? Eine erneute Wiederholung ergab das gleiche Ergebnis. Auch nach 10 Import-Versuchen waren die neusten Beiträge nicht vorhanden. Wiederholungen des Exports ergaben übrigens auch keine Änderung. Auf den ersten Blick war in der XML-Datei (Export) auch alles vorhanden.

Am Ende dieses Beitrages würde ich nun gerne die Lösung dafür präsentieren – ich kenne sie nur leider nicht. Ich werde heute den Versuch nochmal komplett wiederholen, erhoffe mir da aber keine großen Änderungen. Eine Suche nach Import bzw. Export ergab im WordPress-Forum leider NULL Suchergebnisse. Interessiert die Funktion keinen oder bin ich der einzige mit solchen Problemen?

16 Gedanken zu „WordPress 2.1 – Import-Probleme?“

  1. Interessanter Beitrag Frank. Für mich ist dieses Import/Export-Feature aus einem etwas anderen Blickwinkel interessant. Ich habe vor einen Relaunch meines Blogs in den nächsten Wochen anzugehen und wollte dazu den Blog quasi doppeln um an der zweiten Version – mit derzeitigem Datenbestand – die Weiterentwicklung vorzunehmen. Bin nicht gerade ein DB-Spezialist und habe mir deswegen vorher schon ein wenig den Kopf zerbrochen.

    Also Problemlösung her :)

  2. Ok – Problemlösung nach erneutenm Versuch….

    nach dem 20. mal F5-drücken (reload mit anschliessender „ja ich will die POST-Variablen nochmal übermitteln“-Bestätigung) kam dann die Meldung: „All done. Have fun!“

    Und in der Tat waren dann alle Beiträge importiert – ich weiss nicht ob das ernst gemeint ist und ob das so gehört aber es funktioniert mit Beharrlichkeit – dafür mit wenig Sinn :-|

  3. Ich denke, die Ergebnisse per SQL sind zuverlässiger – ein sehr hilfreiches Tool ist der mysqldumper. Damit ist Backup und Co. ein leichtes.
    Das problem per IM/Export wird wohl an der großen Datenmenge liegen -schonmal mit weniger Daten versucht?

  4. Hi,

    Kann es vielleicht ein Timeout Problem sein? Wie viele Datensätze (Beiträge & Kommentare) sind es denn? Wie groß ist denn Deine Export-Datei?

    Schade, wenn es nicht richtig funktioniert, eigentlich eine tolle Funktion!

  5. post_max_size in der php.ini

    Ich weiß nicht wie der Wert bei Xampp eingestellt ist, bei mir liegt er mittlerweile bei 16M (16Mega Byte).

    Und vor allem max_execution_time, ebenfalls in der php.ini.

    Ist die Zeit zu kurz eingestellt (i.d.R. 30 Sekunden), bricht das Script ab.

    Zuletzt noch ggf. memory_limit in der php.ini.
    Je nachdem wie groß deine Export-Datei ist, wird das eng. Normalerweise steht dort ein Wert von 8M (8Mega Byte).
    WP liest die Export-Datei erst einmal in ein Array ein. Bedenkt man das WP aber schon so einiges an Speicher mit all den ganzen anderen Drisch voll schludert, könnte es sein das nicht mehr genug Speicher übrig ist.

    Fazit:
    Ich würde mir ein eigenes Import-Script basteln welches unabhängig von WP läuft.
    Für den Webspace dürfte die Import-Funktion von WP gänzlich ungeeignet sein. Je nachdem wie der Server-Admin die Einstellungen bearbeitet hat, kommt die zu importierende Datei nicht einmal an.
    Solche Scripte werden anscheinend von Leuten geschrieben, die mit den Ressourcen schön verschwenderisch umgehen können. Sinnvoller wäre es wenn man den Export in verschiedene Bereiche (Beiträge, Kommentare, Einstellungen, usw) aufteilt und in mehrere Dateien abspeichert. Das würde auch ermöglichen z.B. nur die Beiträge zu importieren.

    Wenn schon ein lokaler Webserver vorhanden ist (z.B. XAMPP), warum dann nicht ein kurzes Script schreiben welches die Daten aus der Datenbank im Blog ausliest und sie gleich in der lokalen DB rein schreibt? Das wäre bestimmt ein hübsches Plugin für WP-Entwickler: WP-Synchronisation.

  6. Ok sorry, ich hätte evtl. schreiben sollen, dass ich durchaus Grundwissen bzgl. Serverconfig habe ;)

    Natürlich habe ich den üblichen kram (max. runtime, post_max_size) etc. schon durchgespielt und bis in utopische Dimensionen erhöht – doch das ändert genau NICHTS.

    Zudem hat die XML-Datei gerade mal 2.2 MByte und wir reden hier von nicht mal 500 Beiträgen. Sollte also in der Größenordnung alles kein Problem sein. Der Fehler scheint hier andernorts zu liegen.

    Zumal ja nach jedem Reload wieder ~10-20 Beiträge importiert wurden. Dafür durchläuft er jedesmal alle Beiträge um bei den vorhandenen hinzuschreiben, dass sie schon vorhanden sind.

    Am Ende isses noch schlecht dokumentierte Absicht – dann muss ich aber laut lachen ;)

  7. Ok, hätte ich auch selber drauf kommen können das du da Grundwissen hast ;)

    Dann hilft ja nur noch in der Schleife sich jedesmal ausgeben zu lassen welcher Datensatz grade bearbeitet wird um zu schauen wie weit das Script kommt. Fehlerquellen gibt es dabei ja leider genug. Könnte ja auch sein das die Datensätze nicht korrekt in die DB eingetragen werden und das Script an sich ganz vernünftig läuft.

  8. Hallo Frank,
    dein spezielles Problem kenne ich zwar nicht.

    Aber am WE hatte ich meine Artikel aus meinem Live-Blog Exportiert. Bei mir fehlten bei dem Export doch tatsächlich alle „Titel“ in den einzelnen Beiträgen. Ein Blick in die XML-Datei zeigte mir das die Titel tatsächlich nicht exportiert wurden. Da muss WordPress auch unbdingt nachbessern.

    Ich habe dann aus der XML-Datei die meisten Artikel per Hand entfernt und nur 2-3 dann auf einem anderen Blog importiert. Und tatsächlich kein einziger Titel in den Beiträgen vorhanden :-[

    Viel Spaß noch bei der Fehlersuche …

  9. Hallo

    Danke für den Beitrag. Habe genau das gleiche Problem es Werden einfach nicht alle Posts importiert. Das mit dem Refresh werde ich gleich morgen ausprobieren. Aber dieser Beitrag ist echt sehr hilfreich.
    Hat jemand evtl schon zwischenzeitlich eine anere Lösung gefunden?

  10. Hallo, ich werde das bald mal wieder mit der neuesten Worpress Version testen.

    Alle Artikel aus dem Live Blog raus und versuchen in meinen lokalen Testblog zu importieren. Bin mal gespannt was passiert :-)

  11. Hallo zusammen,

    habe ein ähnliches Problem, nur, dass der Import einen Fehler wirft ohne ihn genauer zu bezeichnen.

    Nur:
    Da war leider ein Fehler.

    Die hochgeladene Datei konnte nicht nach …/wp/wordpress/wp-content verschoben werden.

    Was soll mir das sagen? Ohne Ansatz, was hier der Fehler war, kann ich nicht nach ebendiesem suchen.
    Kennt jemand das? Irgendeiner eine Idee?
    Danke und Gruß!

  12. Hi,
    ich habe genau das gleiche Phänomen beobachtet. Ich wollte von meinem kostenlosen WordPress Blog umsiedeln auf meinen neuen Blog, auf einem eigenen Server, auch WordPress.

    Der Export der XML Datei aus dem Live-Blog hat überhaupt keine Schwierigkeiten bereitet, die Datei hat 2,7MB, ist also auch unter der 5MB Grenze.

    Beim Import dann genau der gleiche Zores, bei mir schluckt es komplett 2009 und ein paar alte Einträge von November/Dezember 2008. Davor scheint alles vollständig zu sein. Auch der Versuch, die XML Datei zu splitten (von Hand) hat nichts gebracht, die aktuellsten Einträge bleiben verschwunden.

    Eventuell gab es Kuddelmuddel, weil zuerst das englische WordPress aufgespielt war und ein deutsches WP Update drüber gerattert ist. WP kommt jetzt nochmal komplett neu (und nur in Deutsch) auf den Server und dann werd ich den Import nochmal testen.

  13. Komisch, bei mir erscheint auch Die hochgeladene Datei konnte nicht nach /srv/www/vhosts/127.0.0.1/httpdocs/wp-content verschoben werden…
    Liegt wohl am Server, oder?

  14. Das selbe Problem habe ich.
    Und ebenfalls keine Lösung dafür.
    Hatte gehofft, sie hier zu finden – aber was solls.
    Wenigstens gibt es jemanden, der sich genauso daran die Zähne ausbeißt und ich bin nicht der Einzige.

    Schöne Grüße =)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.