Da ich genau das ja gerade erst für Michaela gemacht habe und mir der neue Artikel von Andreas ToDo Liste – Umzug eines WordPress Blogs auf eine neue Domain etwas zu unvollständig ist, dachte ich mir, dass ich dieses Thema aufgreife und ein Tutorial als Erweiterung zu Andreas Artikel dafür verfasse, damit beim Umzug eines WordPress Blogs auf eine neue Domain wirklich nichts schief geht oder vergessen wird. Wichtig finde ich vor allem, dass das Ganze vor dem eigentlichen Umzug einmal durchgetestet wird. So stellst Du sicher, dass nach dem eigentlichen Umzug nicht auf einmal die Hälfte nicht mehr oder nicht mehr richtig funktioniert.
Das bedeutet, dass Du in diesem Testlauf den neuen Blog einmal komplett aufsetzt und ihn Dir von vorne bis hinten ganz genau durchsiehst. Erst wenn Du mit dem Umzug zufrieden bist, solltest Du ihn dann im endgültigen Schritt einleiten.
Der WordPress Blog besteht eigentlich aus zwei Bereichen. Einmal die Datenbank mit ihren Tabellen und Inhalten und einmal die WordPress Dateien selbst, die auch sämtliche Uploads (Bilder etc.), Themes, Plugins etc. beinhalten. Beide Bereiche musst Du getrennt behandeln.
Nun kannst Du Dich auf der neuen Domain in den Adminbereich Deines WordPress Blog mit den gewohnten Zugangsdaten einloggen.
Sämtliche Daten der alten URL auf die neue URL anpassen
Als nächstes benötigst Du das Search and Replace Plugin von Frank Bueltge. Du installierst es in Deinem neuen Blog, aktivierst es und lässt es über alle Tabellen Deiner Datenbank laufen (die alte URL http://www.alte-domain.tld mit der neuen URL http://www.neue-domain.tld ersetzen).
Wenn Du das alles durch hast, dann prüfst Du Deinen neuen Blog auf Herz und Nieren. Sieh Dir alles sehr genau an, klick Dich überall durch und siehe nach, ob z.B. auch wirklich alle URLs richtig sind, alle Bilder URLs richtig sind und so weiter. Schau Dir an, was Deine installierten Plugins für Ausgaben tätigen und vergiss vor allem auch den Bereich der Widgets nicht (manuelle eingegebene Codes müssen ggf. noch angepasst werden) und schau auch in Deinen Template Dateien nach, ob darin feste URLs enthalten sind, die Du anpassen musst.
Erst wenn Du hier rundum zufrieden bist kannst Du den eigentlichen Umzug starten. In der Zwischenzeit werden vielleicht ein paar neue Kommentare etc. in Deinem alten Blog hinzugekommen sein. Das bedeutet, dass Du einen Teil der oben genannten Schritte noch mal durchführen musst. Aber lieber langsam, Schritt für Schritt, als alles schnell schnell und am Ende funktioniert die Hälfte nicht mehr.
Solltest Du Deine Feeds nicht über Feedburner generieren, sondern die WordPresseigenen Feeds nutzen, wäre es angebracht vor dem eigentlichen Umzug noch einen entsprechenden Artikel auf der alten Domain zu posten, wo Du auch Deine Feedleser darüber informierst, dass sie Deine alte Feed URL auf die der neuen Feed URL anpassen mögen, da sie sonst keine neuen Feeds mehr von Dir erhalten. Machst Du dies erst nachdem Umzug, wird keiner Deiner bisherigen Feedleser mehr davon erfahren und Du hast sie verloren.
Der eigentliche Umzug
Für den eigentlichen Umzug empfehle ich auf dem alten Blog das Plugin WP Maintenance Mode, ebenfalls von Frank Bueltge, zu installieren, zu aktivieren und entsprechend einzustellen. Damit stellst Du sicher, dass es nicht zu Überschneidungen seitens Deiner User kommt, niemand mehr auf den alten Blog zugreifen und zum Beispiel kommentieren kann. So lange der Umzug noch nicht ganz gelaufen ist, wären alle diese Kommentare verloren.
Solltest Du vor Deinem Umzug Deinen Lesern schon Deine neue Domain mitgeteilt haben, ist es auch wichtig, dieses Plugin ab diesem Zeitpunkt wo Deine Leser von der neuen Domain wissen, auf der neuen Domain zu aktivieren. Stell Dir mal das Datenbankchaos vor, wenn die einen auf der einen Domain und die anderen auf der anderen Domain kommentieren. Das würdest Du nie mehr in den Griff bekommen!
Alte Domain auf die neue Domain umleiten
Nun ist Dein neuer Blog live, funktioniert hervorragend, aber es kennt ihn noch keiner. Damit Deine Leser wie auch die Suchmaschinen von Deinem Umzug erfahren, musst Du die alte Domain auf die neue Domain umleiten. Das machst Du mit einem entsprechenden Eintrag in der htaccess der alten Domain (natürlich mit Deinem entsprechenden Domain Namen):
RewriteEngine On
RewriteRule ^(.*)$ http://www.domain.tld/$1 [L,R=301]
Falls Du selbst noch auf Deine WordPress Installation auf der alten Domain online zugreifen möchtest, dann holst Du Dir über wieistmeineip.de Deine aktuelle IP Adresse raus, und erweiterst den oben genannten Code in der htaccess um eine Zeile mit Deiner IP Adresse (anstatt den ganzen 9er natürlich Deine IP Adresse in diesem Format eingeben):
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^99\.999\.999\.999
RewriteRule ^(.*)$ http://www.domain.tld/$1 [L,R=301]
Das sorgt dafür, dass alle außer Du (und die, die die gleiche IP Adresse wie Du nutzen), auf Deine neue Domain umgeleitet werden, wenn sie auf Deine alte Domain zugreifen.
Und nun noch ein Tipp am Schluss: Nach dem Umzug würde ich noch ein paar Tage bis Wochen warten, den Blog auf der neuen Domain auf Herz und Nieren beim aktuellen Betrieb prüfen, und erst dann nach und nach die Daten von der alten Domain löschen. Fertige von allem was Du löscht noch mal eine Sicherheitskopie auf Deinem Rechner an, damit Du im Notfall (falls doch noch was auf diese alten Daten verweist) darauf zugreifen kannst und das auf der neuen Domain entsprechend anpassen kannst.
Du siehst, das Ganze ist kein Pappenstiel und schief gehen kann an vielen Stellen etwas. Deswegen rate ich eingehend dazu, das erst einmal in Ruhe auszuprobieren und den ein oder anderen Testlauf durchzuführen, bevor der eigentliche Umzug gestartet wird. Der Teufel steckt bekanntlich im Detail…
[...] – Domain-Umzug mit WordPress-Blog – Beitrag bei crazytoast.de [...]
[...] müssen auf den neuen Server geladen werden.Damit jeder Blog-Umzug gelingt haben Andreas und Tanja jeweils einen Artikel geschrieben, wie man wie man vorgehen muss, sodass jeder Domain-Umzug [...]
[...] einen Hinweis in Jüergen Schnicks Blog bin ich auf das excellente Tutorial bei crazytoast.de gestoßen, das ich meinen Lesern ans Herz legen [...]
[...] durch das Plugin “Search & Replace” von Frank Bültge auf das ich durch Tanja in einem Beitrag bei Majeres aufmerksam wurde. Das Plugin ist klein, schlank und hinterlässt [...]
Ja die Bültge-Plugins hatte ich auch schon benutzt – wir haben uns ja noch darüber unterhalten …. wirklich sehr zuverlässig und komfortabel für diese Zwecke. Also unbedingt zu empfehlen
Die Hausaufgaben hast du hier sehr schön dargestellt. Letztendlich sind es aber die kleinen Hoster-spezifischen Kleinigkeiten, die Ärger bereiten.
Außerdem wäre noch zu empfehlen, dass zuallererst die Plugins deaktiviert werden sollten…….
@Oliver: Warum denn die Plugins deaktivieren? Hab ich nicht gemacht, sehe auch nicht wirklich viel Sinn dahinter. Außer es steht in einem was extrem spezifisches drinne… Ansonsten muss das was hier läuft auch dort laufen
Weil einige Plugins beim Serverwechsel Probleme bereiten können. Im schlimmsten Fall ist der Blog nicht mehr erreichbar. Nun, dies könnte nachträglich umgangen werden, indem per FTP das Plugin-Verzeichnis umbenannt wird – muss aber nicht sein.
Diese Problematik taucht insbesondere dann auf, wenn es sich um unterschiedliche php-Versionen handelt (z.B. php4 – vorher php5). Oder mit Befehlen, die auf dem neuen Host nicht erlaubt sind (z.B. mod_deflate).
Plugins deaktivieren halt ich auch nicht für notwendig. Das sieht man ja im Test gleich ob die alle laufen oder nicht. Allerdings gibt es wie Tanja sagt “spezifische” Plugins. So hab ich zum Beispiel vergessen mein Twitter Plugin im Test auszuschalten und hab meine Follower leider mit ein paar nicht funktionierenden Links genervt.
Ich grübel gerade über den Feed…
Wenn man eine 301er Umleitung macht, dann sollte der Feed inklusive Leser doch auch korrekt umgeleitet werden?
Natürlich sollte man sie motivieren, die neue Feedadresse zu nutzen
@Oliver: Plugins deaktiveren ist bei einem WordPress Update definitiv wichtiger als beim Umzug. Da man sowieso vorher den Testlauf hat, sehe ich es als total unwichtig an. Im schlimmsten Falle müssten halt die Plugins mal schnell via FTP gelöscht werden.
Größere Probleme sehe ich hingegen beim Plugins deaktiveren im alten Blog an, da viele keine if-functions-exists Anweisung eingebaut haben, legt das den alten Blog flach. Und das ist ja schließlich in diesem Moment der aktive.
Ist ein abwägen zwischen: Meine aktuellen Besuchern ärgern (Plugins deaktivieren) und mich selbst ägern (Plugins aktiv lassen). Ich bin da mehr für mich selbst
Wer von php 5 auf 4 zieht ist übrigens selbst schuld *lacht* da dürfte das dann auch mit der Datenbank Probleme geben, da die dann meist auch auf der 4er Version laufen. Davon sind einige der ersten nicht mal mehr mit WordPress selbst kompatibel. WordPress selbst benötigt mindestens MySQL 4.1.2 und mindetens PHP 4.3.
Grundsätzlich habe ich aber bei meinen vielen WordPress Installationen auf den unterschiedlichsten Servern schon so viele Fehler gesehen (alle mit leerem neuen WordPress), so dass die Plugins wirklich die kleinste Rolle spielen bei dem was so alles schief gehen könnte
@Markus: Ja, das Twitter Plugin ist ein Argument. Aber grundsätzlich wie Du auch sagst, halte ich es nicht für notwendig Plugins vor dem Umzug zu deaktivieren, sondern eher für kontraproduktiv für die Leser.
@Marc: Was den WordPresseigenen Feed betrifft würde ich meine Hand dafür nicht ins Feuer legen
Grundsätzlich ist es aber so, dass wenn jemand über einen alten Feed kommt, via dem 301er auf die neue Seite geleitet wird.
Nur das Problem ist, dass die Leser des alten Feeds keine neuen Feeds mehr zu sehen bekommen, da sie von der neuen Domain losgeschickt werden und diese ja nicht auf dem alten Feed läuft. Technisch gar nicht möglich
Im Prinzip sind wir uns ja alle einig was die Plugins betrifft. Ich verstehe sämtliche Einwände und kann auch alle Herangehensweisen nachvollziehen. Ich wollte ja nur darlegen, dass auch von dieser Seite Probleme kommen könnten. So war das zumindest bei meinem Umzug. Mann, hab ich gerätselt.
Letztendlich ist es Geschmackssache und die Art und Weise, wie man dinge anpackt. Wichtig bleibt jedenfalls, dass man sich der Sache bewusst ist und weiß, was man tut
@Oliver: Klar können auch von der Seite Probleme kommen, aber eben auch von vielen anderen Seiten, die man alle gar nicht alle auflisten kann und die teilweise noch viel wahrscheinlicher sind als die Plugins als Problemquelle.
Hi,
um die Datenbank umzuziehen benutze ich immer MySQLdumper. Da gibt es auch keine zu großen Datenbanken, der importiert dir alle Größen, also muss man nicht irgendwo alles einzeln importieren. (Ich habe das mal für mein Forum gemacht, dass dauert Jahre
)
Weiterhin ist der Vorteil das dieses Script direkt auf deinen Server/Webspace liegt und du es so einstellen kannst, dass es dir regelmäßig Backups von deiner Datenbank per Mail zuschickt, oder per FTP auf einen Backup-Speicher hochläd. Ist also wirklich ein Klasse Tool und du kannst damit vieles machen.
Lieben Gruß
Sven
@Sven Genau das Teil nutz ich auch schon seit Jahren. Echt zu empfehlen. Auch dank desen wird mein Umzug nocht mehr wie 10 Minuten dauern. Hab den kompletten Umzug jetzt schon dreimal durchgetestet und würd am liebsten gleich starten. Muss aber noch n bissle was basteln. Hach diese Ungeduld immer^^
@Sven: So was brauche ich nicht, dafür habe ich einen Cronjob laufen, der ganz genauso seinen Zweck erfüllt und gerade mal 1KB groß ist
Für alles was sonst mit MySQL zu tun hat, nutze ich MySQL-Front, das beste Programm das es dafür gibt, schließlich muss ich ja auch mit MySQL arbeiten und nicht nur Datensicherungen machen und einspielen. Restriktionen gibt es bei MySQL-Front auch keine bezüglich der Größe.
Bei Michaela musst ich nur alles einzeln exportieren und importieren, weil so ein doofer Plugin-Autor eine fehlerhafte Tabelle geschrieben hat. Noch dazu war das Plugin nicht mal mehr aktiv, also deinstalliert. Dieser Trottel hat also auch noch vergessen eine Deinstallationsroutine für seinen SQL-Schrott zu schreiben
@Markus: Bis dato ging das bei mir auch immer super flott. Nach ein paar Minuten war alles gelaufen. Nur dieses eine Mal dauerte es länger, aber daran ist dieser depperte Plugin Autor schuld. Mit ner geschrotteten Tabelle kommt kein Tool klar.
Die Ungeduld kenne ich auch
Tja für so einen Umzug gibts die verschiedensten Möglichkeiten, ich habe meine DB z.B. händisch editiert, das heißt vor dem einspielen im Editor geöffnet Suchen/Ersetzen alte domaine/neue Domaine fertig
Meine Datenbanksicherungen mache ich direkt in PHPmyAdmin und zum wieder einspielen benutze ich BigDump, ein Supertool damit brauch ich kein SQL Dumper.
@jokkel: Ja richtig, es gibt die unterschiedlichsten Möglichkeiten
Ich habe zwar keinen Plan von dem allen aber Danke für deine Hilfe.
Echt toll was Oliver und Du so im Hintergrund gebastelt habt.
Ich war da wirklich planlos…
Oliver hat mich ja noch weiterhin am Hals als Nachfolger von Matthias mit jeder Menge Kleinkram und ist sehr lieb und geduldig
Das mit dem Feed habe ich in meinen Kommentaren…der des alten Blogs funktioniert noch immer…
@Arven: Der alte Feed funktioniert noch immer, weil der alte Blog noch nicht gelöscht ist
Wollte ich eigentlich heute machen, aber ich warte noch auf das okay von Oliver.