Blog-Trainer

WordPress-Seminare seit 2006

importer starten

WordPress-Umzug ohne Backup

| 29.850 mal gelesen |

Der Umzug einer WordPress-Installation kann schon in Arbeit ausarten, wenn man die Standard-Prozedur abarbeitet:

  1. Backup des Webspaces
  2. Backup der Datenbank
  3. Restore des Webspaces
  4. Restore der Datenbank
  5. manuelle Anpassung der wp-config.php
  6. manuelle Anpassung fehlerhafter Pfadnamen in der Datenbank mit Search&Replace

Besonders der letzte Schritt hat es in sich, wenn viele Pfade zu Bildern im Upload-Bereich nicht mehr stimmen. Doch unter gewissen Umständen geht es viel einfacher und schneller!

Einfacherer und schnellerer Umzug mit Export und Import

Wichtiger Hinweis: Die nachfolgende Umzugsmethode ersetzt keine regelmäßige Datensicherung Ihrer WordPress-Installation!

Wenn Sie mit Ihrem WordPress von einer Domain oder Subdomain auf eine andere (Sub-)Domain umziehen wollen, gibt es eine Methode „von Server zu Server“. Voraussetzung ist dabei immer, dass sowohl die alte Domain als auch die neue Domain gleichzeitig live und über das Web erreichbar sind. Das ist normalerweise dann der Fall, wenn Sie den Domain-Namen wechseln wollen oder wenn Sie ein WordPress von einem Testserver auf Ihren echten Server umziehen wollen.

Export der Daten

Im Dashboard finden Sie unter Werkzeuge den Punkt Daten exportieren. Wählen Sie Alle Inhalte und starten Sie Export-Datei herunterladen.

daten-exportieren

Die Exportdatei mit der Endung XML enthält die Inhalte Ihrer Beiträge und Seiten, aber auch die Ihrer „Custom Post Types“ (im Beispiel „Slides“). Hinzu kommen alle Taxonomien (Kategorien, Schlagwörter, …) und alle individuellen Menüs. Was hier fehlt, sind (leider) die Widgets und (zum Glück) die Optionen und Einstellungen. Auch die Inhalte des Ordners wp-content sind nicht dabei, d.h. es fehlen die Themes und Plugins.

Neues WordPress einrichten und vorbereiten

Auf Ihrer neuen Domain (dem Ziel Ihres Umzuges) richten Sie nun ein neues, jungfräuliches WordPress ein. Bevor Sie die Exportdatei importieren, sind einige wichtige Vorbereitungen zu treffen:

  1. Einstellungen → Medien: Machen Sie hier bereits jetzt die später gewünschten Größenangaben für Bilder. Beim Import werden dann später alle Bilder gleich in den passenden Größen generiert und auch die Pfade zu den Thumbnails, mittleren und großen Bildern passen exakt. Dies ist eine riesige Arbeitserleichterung!
  2. Theme und Childtheme installieren und aktivieren: Installieren Sie schon jetzt Ihr gewünschtes Theme und Child Theme. Themes bringen oft Vorgaben für die Größen von Kopfbildern und Beitragsbildern mit. Wenn Ihr Theme schon vor dem Import aktiviert ist, werden auch diese Bilder bereits passend generiert.
  3. Slider, Galerien oder weitere Plugins installieren, aktivieren und einstellen: Wenn Sie mit Slidern oder Galerien arbeiten, die eigene Post Types erzeugen oder eigene Taxonomien verwenden, so installieren Sie diese bereits jetzt und stellen Sie auch hier die Wunschgrößen Ihrer Bilder bereits ein. Auch für diese Plugins werden dann beim Import gleich die passenden Bildgrößen generiert.
  4. Plugins mit eigenen Post Types installiern und aktivieren: Wenn Sie noch weitere Plugins mit eigenen Post Types verwenden, sollten Sie auch diese bereits installieren und aktivieren. Beispielsweise speichern manche Event-Plugins die Veranstaltungen in eigenen Post Types. So stellen Sie sicher, dass die bereits in der alten Installation angelegten Events auch in der neuen vorhanden sind.
  5. Unnützes entfernen: Entfernen Sie aus Ihrer neuen Installation unnötigen Ballast wie den Hallo-Welt-Beitrag, die Beispielseite und die Plugins Akismet und Hello Dolly.

Import der Daten

Unter Werkzeuge finden Sie den Punkt Daten importieren. Wählen Sie WordPress aus. Der Daten-Importer ist ein Plugin, das Sie erst installieren müssen. Klicken Sie dazu auf Jetzt installieren.

daten importieren

jetzt installieren

Aktivieren Sie nun den Importer und starten Sie den Import. Dabei werden Sie aufgefordert, die Exportdatei aus Schritt 1 hochzuladen.

importer starten

WordPress prüft nun, welchem Benutzer Ihrer alten Installation die einzelnen Beiträge, Seiten und anderen Objekte Ihrer Installation gehören. Sie müssen für jeden „alten“ Benutzer entscheiden, ob und welchem neuen Benutzer Sie seine Beiträge zuweisen wollen. Das ist eine gute Gelegenheit, einmal die Benutzerliste aufzuräumen oder neue Accounts zu erstellen. Seiten wird man in der Regel dem Administrator des neuen WordPress zuordnen.

Jetzt kommt der wichtigste Punkt des Imports: Checken Sie unbedingt das Kästchen „Download and Import Attachements“! WordPress wird nun alle Ihre Bilder und Mediendateien von Ihrem alten Webspce auf Ihren neuen Webspace hinüberziehen. Dabei wird WordPress gleich die passenden Bildgrößen für Ihre Thumbnails und andere Bildvarianten generieren und sämtliche Pfade in den Beiträgen und Seiten anpassen, in denen Sie die Bilder verwendet haben. Das ist eine große Erleichterung gegenüber der klassischen Search&Replace-Methode und funktioniert fehlerfrei.

import-attachements

Arbeiten nach dem Import

Was bleibt nach dem Import noch zu tun?

  1. Menüs aktivieren: Ihre individuellen Menüs sind mit der Export-Datei umgezogen. Jedoch müssen Sie sie noch mit Ihrem Theme verknüpfen. Das machen Sie unter Design → Menüs → Positionen verwalten.
  2. Widgets einrichten und platzieren: Leider werden Widgets und deren Positionen nicht per Export-Datei mitgenommen. Sie müssen also unter Design → Widgets noch die passenden Widgets in die Widget-Bereiche schieben und platzieren. Das ist meistens schnell erledigt. Nur für Textwidgets mit viel Text oder viel HTML-Code müssen Sie eventuell Copy&Paste bemühen.
  3. Importer-Plugin deaktivieren und löschen: Das Importer-Plugin hat seine Schuldigkeit getan und kann deaktiviert und gelöscht werden.

Vor- und Nachteile der Export-Import-Methode

Die Export-Import-Methode ist besonders dann vorteilhaft, wenn man bei einem Relaunch ohnehin ein anderes Theme wählt, das andere Thumbnail- und Bildgrößen erfordert. Diese werden aus den Original-Bildern neu generiert.

Einen weiteren Vorteil sehe ich darin, dass die Options-Tabelle der Datenbank grundlegend entstaubt wird. Über die Jahre sammeln sich bei jeder WordPress-Installation in dieser Tabelle hunderte oder gar tausende Optionen und Variablenwerte alter Themes und Plugins an, die man mal getestet, aber nicht sauber deinstalliert hat.

Der größte Vorteil aber ist, dass nach dem Import alle Pfade, auch die der mitgenommenem Bilder und anderer Uploads, auf Anhieb stimmen.

Nachteilig gegenüber der klassischen Methode ist, dass man das verwendete Theme/Child-Theme, die verwendeten Plugins und auch die Widgets noch einmal händisch installieren und konfigurieren muss. Das ist aber vor allem eine gute Gelegenheit, mal auszustauben und aufzuräumen! Bezogen auf das Theme und die Plugins kann man das beschleunigen, indem man sein Theme/Child-Theme und die gewünschten Plugins aus den Ordnern wp-content/themes bzw. wp-content/plugins per FTP vom alten Webspace zum neuen Webspace transferiert.

WordPress-Umzug ohne Backup auf Facebook teilen
WordPress-Umzug ohne Backup auf Twitter teilen
WordPress-Umzug ohne Backup auf Google Plus teilen
WordPress-Umzug ohne Backup auf Xing teilen
WordPress-Umzug ohne Backup auf LinkedIn teilen

Das könnte Sie auch interessieren:

30 Kommentare

  1. Oder einfach SQL-Backup + FTP-Download auf altem Server, FTP-Upload und SQL-Restore auf neuem Server, dann ist 1 zu 1-Kopie fertig. Geänderte Pfade noch kurz mit SQL-Update anpassen. DB und Dateien sollte man ja ohnehin immer wieder aufräumen / sauber halten 😉

  2. @Martin: Dieser Artikel heißt „WordPress-Umzug OHNE Backup“ 😉 Die normale Methode, die Du nennst, kennt jeder umd ist überall beschrieben, aber manchmal einfach zu umständlich. Und der Nachteil: Man schleppt vielen alten Ballast mit.

  3. Super Beitrag alles wichtige würde angesprochen. Es gibt Erweiterungen für den Importe, mit dem lassen sich Widgets und Nav-Menüs mit exportieren.

  4. ich bin auf diese Methode durch den Import von Demo-Content bei Premium Themes gestoßen.
    Dies Weg eines Umzugs ist jedenfalls interessant.

    Der Widget- und Menüimport ist ein guter Hinweis.

    Diese Methode kann man auch beim Herauslösen einzelner Blogs aus einer Multisite Installation prima nutzen.

  5. Ich hab das schon öfter so gemacht und sehe noch einen weiteren Nachteil. In den meisten webspaces, wo ich das getestet habe, lief der Import immer in einen PHP timeout.
    Gelöst habe ich das meistens, dass ich die XML-Datei zeitaufwendig geteilt habe. @Karl-Heinz, hast Du da vielleicht noch eine andere Lösung?

    • Hi Martin, verwende einfach den „WordPress WXR File Splitter“. Er teilt die XML Dateien automatisch für den Import auf. Zu finden unter 🙂

    • Das ist vollkommen korrekt. Ich selbst benutze diese Methode nicht mehr. Genau aus den von dir genanten Gründe(n). Ich selbst habe diese Methode bestimmt 30 mal in verschiedenen Blogs ausprobiert (Test zu Original Site). Das funktioniert bestimmt erfahrungsgemäß in 5 % der Fälle.

      Allein wenn schon etwas mehr Content als normal vorhanden ist, dann funktioniert diese Methode nicht. Das fällt auch in letzter Zeit immer mit gekauften Themes auf, die Beispielcontent mitliefern. Ich lasse es meistens sein, da das ganze in einem Chaos endet.

      FAZIT: Ich empfehle unbedingt von dieser Methode abzusehen.

      Warum? SIE FUNKTIONIERT NUR MIT SEHR WENIG IMPORTDATEN.

      Folgende Argumente sind aus meiner Sicht anders zu betrachten:
      Eine neue Site von Test zu Liveserver ist meistens schon von vorneherein sauber, weil frisch aufgesetzt, da muss man auch nicht viel entmüllen.
      Und beim Umzug von großen Seiten auf eine andere Domain hat manchmal eh eine komplett neue Umstrukturierung zur Folge, so dass man die Daten eh nochmal neu einpflegt und überarbeitet (wenn man es vernünftig machen will- ansonsten kann man es auch sein lassen)

      Ich möchte dem Autor nichts unterstellen, aber ich halte den Artikel für eine kleine theoretische Ausführung als auf einen Erfahrung basierten sinnvollen Text.

      Ausserdem muss man sich nur mal die Bewertung des Plugins ansehen, was einem verdeutlicht, wie gut es zu funktionieren scheint:
      – „3.2 out of 5 stars“
      – Aktuelleste Config: 3 people say it works. 2 people say it’s broken.

      • @Marc: Dank auch Dir für Deinen ausführlichen Kommentar. Man erkennt, dass jede der Methoden Vor- und Nachteile hat. Mir gefällt bei der hier beschriebenen, dass sie einfach ist und vor allem, dass die Pfade zu sämtlichen Mediendateien, auch zu den neu generierten Thumbnails ad hoc stimmen. Es spart bei Umzug von Content jede Menge Search & Replace bzw. SQL-Befehle.

        Natürlich ist klar, dass die Methode nicht für jeden Zweck taugt. Zum Beispiel gibt es bei Billighostern Probleme mit dem Upload-Limit, wenn deine Datenbank einige tausend Beiträge hat. Wenn das normale SQL-Backup über 10 MB groß ist, kann man mit Export/Import in der Regel nicht mehr vernünftig hantieren. Aber für alles Kleinere funktioniert es wie geschmiert und fehlerfrei (jede Woche in meinen WordPress-Seminaren zu erleben).

        • Laufen diese Seminare dann im localhost oder von wie viel Daten sprechen wir da?

        • @Marc: Die Seminare laufen seit 2006 ganz normal im Web. Jeder Seminarteilnehmer richtet dabei sein eigenes WordPress auf einer Subdomain auf dem Webservers ein und konfiguriert es, testet Themes und Plugins. Natürlich werden dabei auch die verschiedenen Sicherungs- und Umzugsszenarien behandelt, Datensicherung und Restore der MySQL-Datenbank mit phpmyadmin bzw. Plugins wie BackWpUp behandelt. Also ganz praxisnah – wie im wirklichen Leben.

        • Hallo, ich kann leider nicht auf deinen Kommentar in 3. Ebene antworten, daher hier mein Kommentar.

          Gut. Dann sprechen wir hier eher von einer sehr jungfräulichen Install (wie von dir schon erwähnt- „praxisnah“) und keinem realen Szenario.

          Im realen WP Leben wird diese Methode wahrscheinlich nicht eingesetzt, wegen den erwähnten häufigen Fehlern. An deiner Stelle würde ich eventuell am Anfang des Artikels den Hinweis geben, dass es sich hierbei um eine Methode handelt, die sehr wenige Daten Ex-/Importieren kann. Der Fairnesshalber gegenüber den Lesern, damit diese sich nicht zu viele Hoffnungen machen- hier die Super-Lösung gefunden zu haben. Auch hier sieht man deutlich: Theorie und Praxis sind eben nicht immer dasselbe.

  6. Und es setzt voraus, dass die Quellseite immer online verfügbar ist, und der DNS des Zielservers die Quellseite auflösen kann. Ist also keine Option bei localhost-Entwicklung.

    • @Chris: Punkt 1 hatte ich oben geschrieben. Punkt 2 ist eine richtige und wichtige Ergänzung. Danke!

      • Nun, es gibt ja durchaus die Möglichkeit, eine Seite auf einen öffentlichen Server zu schieben, den Apache-Host einzurichten, aber die DNS-Auflösung nur lokal mit /etc/hosts zu machen, so dass niemand anderes die Seite einfach nutzen kann. Das wäre noch ein gar nicht so seltener Zwischenfall. Das meinte ich mit „dass der DNS des Zielservers die Quellseite auflösen kann“. 😉

        (Sowas kommt recht häufig vor…)

  7. Danke für die tolle Beschreibung.

  8. Bitte auch daran denken das die ID´s der Kategorien, Tags und so neu vergeben werden. Wer also im Theme oder Plugins mit diesen ID´s arbeitet, muss diese anpassen.

    Wie das jetzt mit den ID´s der Artikel ist weiß ich gar nicht mehr, sollte man mal prüfen, den das wäre tödlich für Rankings, wenn die ID für die Permalinks verwendet wird. Stichwort: Google News.

    Kann auch sein das dies alles inzwischen nicht mehr so ist, dann bitte melden 🙂

    • Sehr guter Punkt Markus. Da muss ich zB gleich an WidgetLogic denken. Das Plugin bezieht sich auf die page etc. ID’s. Das wäre dann futsch.

      Artikel-ID’s ist auch ein guter Punkt. Was sagt der Autor dieses Artikels dazu?

    • Hallo Markus,

      Das mit den IDs ist ein interessanter Hinweis. Ich benutze die IDs allerdings nur bei einem Plugin (Google XML Sitemaps), um bestimmte Seiten aus der Sitemap auszuschliessen.

      Das Thema IDs ist für Google News sicher relevant, Im beschriebenen Umzugsszenario geht es aber ausschließlich um Domainwechsel. Da dürften selbst ordentliche Redirects nicht davor bewahren, dass die alten Artikel bei Google News rausfliegen. Also isses schnuppe, wie wir hier in Berlin sagen.

      Gruß,
      Karl-Heinz

      • Na ja ob das Schnuppe ist… Es geht ja auch nicht nur um Google News. Es geht darum wenn man die ID´s eben in den Permalinks drin hat, aus was für Gründen auch immer. Das betrifft ja dann auch den normalen Google Index. Den mal ehrlich, würdest Du es merken wenn Du in Deinen Permalinks die ID hast und die ist nach dem Umzug eine andere? Wenn Du es nicht merkst, erstellst ja auch keine Redirects. Zumal du auch alle internen Verlinkungen anpassen müsstest. Also soooo einfach mal schnuppe ist das nicht 🙂

        Daher nochmal, wer das testet soll doch bitte mal auf die ID´s der Artikel achten, ob die gleich bleiben. Würd mich brennend interessieren. Danke 🙂

        • Hallo Markus, danke nochmals für diesen Kommentar!

          In diesem Artikel geht es um den Umzug auf eine andere Domain oder Subdomain, also immer mit komplettem Wechsel aller Addressen. Da ist das mit den IDs wirklich zweitrangig.

          We ich schon oben mehrmals schrieb: Bei einem Umzug mit gleichbleibender Adresse, zum Beispiel einem einfachen Hosterwechsel, funktioniert die Import/Export-Methode überhaupt nicht.

  9. Wir unterhalten uns wahrscheinlich eh über ein Problem das gar keines ist, den ich denke WordPress wird inzwischen erkennen wenn eine ID in den Permalinks verwendet wird und diese dann beim Import nicht ändern. Aber trotzdem nochmal ein Versuch:

    alte-domain.de/artikel-12345.html
    neue-domain/artikel-12345.html
    neue-domain/artikel-54321.html

    Merkst Du den Unterschied? Wenn WordPress die ID´s der Artikel ändert und man diese eben auch in den Permalinks verwendet ist es eben nicht egal. Da reicht ein normaler Redirect auf die neue Domain eben nicht aus, sondern Du darfst zusätzlich noch für jeden einzelnen Artikel einen eigene Redirect erstellen.

    Natürlich wenn es dir egal ist das evtl. hunderte oder tausende Links ins Leere gehen, oder WordPress die falsche Artikel anzeigt kannst natürlich drauf verzichten. Anderen ist das aber vielleicht nicht egal und deshalb sollte man es mal testen.

    Und nein durch einen Domainumzug verliert man nicht automatisch die Rankings. Man muss es eben nur richtig machen.

    Die Import/Export Funktion funktioniert allerdings auch wunderbar bei gleichbleibender Domain. Hab ich selbst schon mehrfach gemacht/machen müssen.

  10. Deine Argumentation mit den IDs im Permalink verstehe ich schon. Das müsste man mal testen, was in solch einem Fall passiert. Ist aber sicherlich nur bei einem kleinen Prozentsatz von WordPress-Seiten akut, und die sollten genau hingucken.

    Zu deinem letzten Satz: Wie soll der Export/Import bei gleichbleibender Domain und Hosterwechsel funktionieren? Wie sollen da die Mediendateien nachgezogen werden? Ich bin der Meinung, dass man bei Mitnahme des Domainnamens immer die „normale“ Methode (FTP, SQL Backup, SQL Restore) verwenden muss.

    • Die Mediendateien sollten ja noch alle vorhanden sein in dem Fall. Daher brauchst ja die auch nicht „nachziehen“. Ich hab es öfters machen müssen zu Anfangs um die Datenbank wieder etwas „sauberer“ zu bekommen. Als Backup incl. Mediendateien taugt das natürlich nicht viel, da hast Du Recht. Sind Dateien weg bringt einem das ganze nichts, egal ob neue Domain oder alte Domain.

      PS: Ich weiß nur nicht mehr ob man jetzt den Hacken trotzdem setzen muss bei “Download and Import Attachements” das die Attachments weiter funktionieren oder nicht. Ist schon paar Jahre her.

      • Aber bei mitgenommenem Domainnamen zeigen doch die Domain Name Server entweder (noch) auf den alten oder (schon) auf den neuen Webspace, oder? Das Nachziehen der Attachements mit „gecheckter Box“ (siehe Screenshot oben im Artike) kann doch nur funktionieren, wenn man von einer Domain auf die andere zieht, oder liege ich da falsch?

        • Klar die Zuordnung der Domain sollte in dem Fall schon eindeutig sein. Entweder erstmal eine temporäre Domain auf dem neuen Webspace/Server und alles einrichten oder aber man wartet bis der alte Webspace/Server abgeschaltet ist. Dann natürlich nicht vergessen, die Mediendateien von Hand erstmal hochzuladen auf den neuen Webspace/Server.

          Nichts desto trotz ist ein ordentliches Backup in solchen Fällen immer vorzuziehen. mysqldumper 😉

        • Markus, in diesem Artikel geht es um den Umzug von einer Domain auf eine andere OHNE FTP und OHNE Datenbank-Backup/Datenbank-Restore.

          Der Vorteil dieser Export/Import-Methode ist es ja gerade, dass man alle Mediendateien direkt von Server zu Server transferieren kann, also OHNE Download und Upload und OHNE nachträglich per Search & Replace in der Datenbank oder an irgendwelchen internen Pfaden oder Verlinkungen im Content rumfummeln zu müssen. Das Umbenennen der Pfade und die Neugenerierung aller Bildgrößen und Thumbnails übernimmt das Import-Plugin, dafür ist es gemacht worden.

          Diese vereinfachte Umzugsmethode ERSETZT NICHT ein ordentliches Backup (ich mache das wöchentlich bei allen meinen Websites mit BackWpUp in die Dropbox).

          Da sind wir uns einig und das habe ich oben im Artikel und auch in den Kommentaren mehrfach geschrieben.

  11. Pingback: Netzfundstücke der Woche 11/14 :: blog@lewumpy