Warum einen WordPress-System migrieren?

Hier vielleicht eine Abkürzung: wer dazu gar keine Idee hat, muss eigentlich nicht weiterlesen. Der Artikel richtet sich eher an Interessenten, die vor genau dem Problem stehen.

Typischerweise testet man Features erst auf einem Testsystem. Ist alles ok muss der Stand des Testsystems zum Produktivsystem werden. Und das ist der springende Punkt: wie wird ein heutiges WordPress-System A ein morgiges System B?

Dasselbe kann einen Treffen, wenn man den Serveranbieter wechselt oder selbst umzieht. Also wenn z.B. plötzlich „www.meinedomain.de“ zu „www.anderedomain.com“ wird.

Notwendige und sinnvolle Schritte

Tipp (optional): Posts-Tabelle bereinigen – Revisionen entstehen immer, wenn ein Administrator den Befehl speichern benutzt. Dadurch entstehen viele Ballast-Datensätze.

Tipp (optional): Vor dem Exportieren der Datenbank die Datenbank aufräumen/optimieren:

Revisionen löschen, z.B. via phpMyAdmin und dem SQL-Befehl folgenden SQL-Befehl:

DELETE

FROM wp_posts

WHERE `wp_posts`.`post_type` = „revision“

Tipp (optional): Datenbanktabellen optimieren (sinngemäß defragmentieren, reindexieren)

  • in phpMyAdmin die einzelnen Tabellen selektieren
  • in der oberen Befehlsleiste rechts den Befehl optimieren aufrufen

Tipp (optional):  langfristig – wenn die Revisionen ohnehin nur stören, kann man deren Anzahl auf z.B. 3 beschränken:

Dazu in die Datei wp-config folgende Zeile an beliebiger Stelle – nur nicht gerade in einen Kommentar – eintragen:

define('WP_POST_REVISIONS', 3);

Dann werden grundsätzlich nur die drei letzten Stände gespeichert.

Notwendige Schritte:

  1. Die Datenbank muss exportiert werden. WordPress Deutschland hat eine Anleitung mit aussagekräftigen Screenshots dazu erstellt. Hieraus geht gut hervor, welche Optionen der Export-Maske man bei WordPress zur Auswahl empfiehlt.
  2. Der Export führt auf eine SQL-Datei oder ein Zip-Archiv mit der SQL-Datei. Diese ist so wie exportiert unbrauchbar für eine andere IP-Adresse. Der letzte Server-Ort wie „testserver.XYZ.de“ kann an tausenden Stellen abgelegt sein. Damit ist die Datei schon ein gutes Backup – bei anderer/neuer Web-Adresse ist das aber ein Show-Stopper. Kurzum: in einem hinreichend leistungsfähigen Texteditor laden und gewissenhaft die alte oder temporäre Domain mit der neuen per Ersetzen-Befehl austauschen.
  3. Die angepasste Datenbank nun auf dem Server in die entsprechende mySQL-Datenbank importieren.
  4. Gegebenenfalls Statistiken etc. löschen: Falls Besucherstatistiken etc. erhoben werden, enthält die Datenbank bis hier zumeist lediglich die Datensätze der Tests. Solche Daten verschleiern das tatsächliche Besucheraufkommen unnötig und blähen häufig die Datenbank immens auf.
  5. Natürlich muss der neue Server ebenfalls die notwendigen Voraussetzungen erfüllen. Trotzdem können hier Details anders sein. Bei 1und1 muss man z.B. bei manchen Angeboten erst die PHP-Version von PHP4 auf PHP5 umstellen.
  6. Sämtliche Dateien aus dem Ordner der alten oder temporären Installation in den betreffenden Ordner auf dem neuen Server kopieren.
  7. Mögliche Ergänzungen: Der operative Betrieb kann aufgrund der anderen Umgebungen noch kleine Detail-Ergänzungen erfordern:
    1. Bei 1und1 benötigen viele Anwender z.B. eine Datei namens php.ini mit dem Inhalt memory=20MB, die im Ordner /wp-admin/ abgelegt sein muss.
    2. Ebenso können spezielle .htaccess-Files notwendig werden. Wiederum 1und1 benötigt vielfach zur Vermeidung des Server Fehler 500 die Zeilen 
      AddType x-mapp-php5 .php
      AddHandler x-mapp-php5 .php
      in einer solchen Datei, die im Stammverzeichnis der WordPress-Installation liegen muss.
  8. Höchstwahrscheinlich haben sich mit dem Umzug auch die Zugangsdaten zur Datenbank sowie deren Namen und Adresse geändert. Darum muss hier die Datei wp_config.php ähnlich wie bei einer Neu-Installation editiert werden.
  9. Je nach Vorgehen: wenn man eine neue wp_config.php schreibt, sollte man nicht vergessen, dass neben den vier essentiellen Datenbank-Angaben im Laufe der Zeit auch andere Einträge darin gemacht worden sein können. Betreibt man z.B. Caching-Tools, muss ggf. die Option auf true gesetzt werden bzw. das ganze zugehörige define eingefügt werden. Kurzum: ALLE selbst geänderten Einträge müssen übernommen werden. Am Einfachsten ist es daher wahrscheinlich, wenn man die Datei wp_config.php mit allen anderen Dateien kopiert und nur die Zugangsdaten ändert.
  10. Denkbar: Anpassungen der Rechte und Datei-Eigentümer, insbesondere im Linux-Fall. Wenn man die Dateien locker als root mit WinSCP kopiert, kann anfangs alles ganz gut aussehen. Spätestens wenn ein Apache-Prozess mit dem technischen User www-data allerdings etwas updaten soll, kann das dann plötzlich schief gehen. Der User www-data ist nämlich bei Weitem nicht so allmächtig wie root. Dasselbe kann auch eintreten, wenn man die Daten via FTP hochlädt. Zumindest, wenn der FTP-User ebenfalls nicht mit www-data identisch ist.