Server-Umzug und neuer Anstrich

Heute Nacht ist blogcraft.de umgezogen. Nichts bemerkt? Gut so!

Obwohl zwischenzeitlich durch einige DNS-Umstellungen trotzdem eine Nichterreichbarkeit vorhanden war, leider. Denn man weiß nie so genau, wann die Anbieter da so ihre Aktualisierungen durchlaufen lassen. Und da man eine Domain in aller Regel nur über eine IP gleichzeitig erreichen kann^[01], war mir das Testen etwas erschwert. Und WordPress mit Alternativ-URLs … na lassen wir das, das wird zu technisch.

Was beim Umzug die Sache erleichtert, ist der Vorteil eines “von außen” erreichbaren Datenbankservers, womit man nämlich mehr Zwischenschritte tätigen kann. Vorteil? Ja, denn das minimiert die Fehlersuche unheimlich, wenn es kleinere Portionen sind, die von A nach B transferiert werden. Und man kann anders vorgehen.

Mein gestriger Spontanumzug lief so:

1. Dateien von alten auf neuen Webspace kopieren — der einfachste Schritt
2. Auf dem Server (=neuer Webspace) dem Apache mitteilen, dass er eine neue Domain behandeln soll. (vhost anlegen, Apache reloaden)
3. Domain umkonnektieren auf den neuen Server
4. warten …
5. Hoffen, dass alles gut gegangen ist — was natürlich erfahrungsgemäß nie der Fall ist
   • Die .htaccess anpassen, da dort eine Anweisung drin war, die einen 500er verursachte (Notiz an mich selbst: der Server hat von vornherein mehr RAM für die PHP-Umgebung als der billige Webspace)
6. Blog testen, ob alles läuft. Merke: die Datenbank befindet sich noch auf der alten Umgebung (natürlich musste ich aber das “localhost” zu “blabla.dbserver.tld” umschreiben, da wir ja nicht mehr auf dem selben Server liegen)
7. Check, alles läuft rund. Nun kann die DB umziehen, denn Dateien und Grundkonfiguration machen keine Probleme mehr.
8. Datenbankumzug:
   1. DB auf altem Server sichern. Statt phpmyadmin eine Software nutzen, damit PHP-Laufzeitumgebung und der dahinter stehende Server einem bei großen Datenmengen keinen Strich durch die Rechnung machen! Ich empfehle hier die GUI Tools von MySQL (der MySQL Administrator und der MySQL Query Browser sind sehr gut und für Windows wie auch Linux erhältlich, kostenlos – siehe hier, bzw. Ubunties schauen mal im Repository nach)
   2. DB-Sicherung auf neuen Server einspielen — ich habe mich auch hier für die Variante per GUI Tools entschieden, dauert aber lange! Besser ist es wohl, das DB-Dump auf den Server zu laden und dort per Konsole (ssh) direkt einzuspielen, da diese nativen Werkzeuge dann doch schneller arbeiten. Aber ich hatte ja die Nacht Zeit und mir reichte der DB-Switch auch heute morgen.
   3. Wenn DB auf dem neuen Server ist, dann die wp-config.php anpassen und testen. Läuft wie n V8 — superb!
   4. Ggf. DB umbenennen und vllt. einen DB-User einrichten, der weniger Rechte hat als ein ALL PRIVILEGES-Nutzer, und dann auch nur auf der eigenen DB — Sicherheit geht vor!
9. Freuen wie ein Honigkuchenpferd, dass alles geklappt hat und keine schwerwiegenden Probleme auftraten. Okay, Erfahrung macht hier viel aus, da man so schneller an gewisse Fallstricke denkt und diese vermeidet.

Wie oben erwähnt, war der Umzug eigentlich nicht geplant, bot sich aber an, da ich nach und nach alle Seiten auf dem neuen, schnelleren und individualisierbaren Server umziehen will, sofern möglich. Webspace im Shared Hosting ist halt nie so schnell und gut, und haste mal n Kunden dabei, der eine CPU- oder RAM-intensive Site fährt, dann leiden alle auf dem Server.

Ebenfalls erwähnenswert: WordPress ist mittlerweile so idiotensicher geworden, dass man auch nicht mehr auf server-lokale Pfade achten muss, denn wo WordPress liegt, findet es meist selbst heraus, und eventuelle Pfade in der DB kommen so selten vor, dass es auch im Nachhinein kaum Probleme gibt (höchstens schlecht geschriebene Plugins). Wichtig: beim Umzug nicht auch noch etwas an der allgemeinen Ordner- oder Permalinkstruktur ändern! Gerade letztere ist eh ein Thema für sich, wo ich auch so meine Erfahrungen machen durfte.

Neben dem Umzug habe ich aber auch etwas optisch aufgehübscht. Angeregt durch einige Designs im Netz, die mich daran erinnert haben, dass ich ein Freund des Minimalismus bin, hab ich besonders den Header aufgeräumt und den Hintergrund weiß gestrichen. Da auch hier mehr der Inhalt als das Layout im Vordergrund steht, musste das Design natürlich weniger ablenkend umgestaltet werden. Ich sollte mir definitiv eine persönliche Theme-Spielwiese einrichten …

Das war es dann auch schon.

Wer Fragen zum WordPress-Umzug hat oder ein bisschen Hilfestellung benötigt, kann mir hier gern einen Kommentar hinterlassen. Wenn die Frage auf einen Aspelt hinausläuft, der für viele interessant sein kann, dann widme ich dieser auch einen eigenen Beitrag.