Aufgrund von internen Umstrukturierungen der IT mussten wir nun diesen Blog auf einen neuen Server mit einem neuen Domain-Namen (blog.e9a.at anstatt e9a.at) umsiedeln. Normalerweise verläuft so etwas bei uns relativ problemlos, wir haben das auch schon ein paar mal gemacht. Allerdings war es für uns ein Novum, eine WordPress-Instanz über die Kommandozeile zu migrieren. Und wie sich herausstellen sollte, kann es mit WordPress durchaus wilde Komplikationen geben. Vor allem, wenn man es sich zur Aufgabe macht, das ganze mit nginx und mit einem Reverse-Proxy laufen zu lassen. Hier nun eine Anweisung, wie wir schließlich ans Ziel gekommen sind, und welche Steine WordPress uns in den Weg gelegt hat.

Als erstes mussten wir die Seite vom alten Server wegbringen. Dazu haben wir den Ordner /var/www/e9a-webpage als tar.gz verpackt und mittels dem Tool „mysqldump“ die erforderliche Datenbank als SQL-Instruktionen in einer Datei abgespeichert.

Diese Daten haben wir auf dem neuen Server kopiert, fürs erste einmal ins Home-Verzeichnis. Nun mussten wir ein paar Applikationen installieren (wir verwenden Debian 9):

Hier haben wir nun eine nginx-Konfiguration eingepielt

Die php.ini von php-fpm müssen wir noch bearbeiten, weil wir den Parameter „cgi.fix_pathinfo = 0“ setzen müssen. Der Dateipfad lautet wie folgt:

Jetzt haben wir die Backup-Daten in das enstprechende Verzeichnis entpackt und den mysqldump eingespielt. Den MySQL Benutzer und das Passwort wurde in unserem Fall neu gesetzt, wir können aber nicht mit Sicherheit behaupten, ob das auch notwendig war.

Am Reverse-Proxy kopierten wir folgende Konfiguration:

Nach einem kurzen Neustart von nginx und php-fpm war die Konfiguration so weit fertig.

Nun hingen wir an einem Fehler, der uns einige Zeit kostete. Überzeugt davon, die File-Permissions richtig gesetzt zu haben, waren wir doch sehr überrascht, immer wieder nur eine weiße Seite mit einer Fehlermeldung wie „No Input File selected“ zu sehen. Nach einiger Recherche-Arbeit stießen wir dann an über folgenden Link:

https://stackoverflow.com/questions/25774999/nginx-stat-failed-13-permission-denied

Nachdem wir den Befehl (sudo muss nachinstalliert werden, sonst funktioniert es nicht)

wie im Artikel beschrieben probiert hatten, stellte wir tatsächlich fest, dass irgendeine Berechtigung nicht richtig gesetzt war. Wir sind uns bis jetzt nicht sicher, was genau da nicht gepasst hat, aber nachdem wir nochmal chmod und chown über das Verzeichnis gemacht haben, ging der Befehl auf einmal, und nach einem kurzen F5 im Browser hatten wir unsere Seite wieder vor uns. Aber Moment, WAS IST DAS DENN? Man konnte zwar fetzen von e9a.at sehen, aber alles war am falschen Platz. Kurz mit F12 einen Blick darauf geworfen, konnten wir feststellen, dass SSL nicht korrekt werkte und gewisse Inhalte von WordPress über HTTP geladen werden wollten, was dem Browser so gar nicht gefallen wollte.

Hier hat uns dieser Link extrem weitergeholfen:
https://www.variantweb.net/blog/wordpress-behind-an-nginx-ssl-reverse-proxy/

Wichtig ist dabei nur zu beachten, den auf dieser Website beschrieben Block am ANFANG der Config-File und nicht am Ende einzufügen. Ansonsten erwarten euch sehr komische Fehlermeldungen wie etwa “ Du bist leider nicht berechtigt, auf diese Seite zuzugreifen “ im Admin-Bereich… obwohl euer User die immer hatte.

UPDATE: Damit auch alle externen IP-Adressen richtig durchgeleitet werden, muss zusätzlich in die wp-config.php noch folgender Eintrag rein:

Der letzte wichtige Punkt ist, dass ihr in der Datenbank, solltet ihr die Website so wie wir unter einem neuen Hostnamen laufen haben, alle Verweise und Links auf die alte URL durch die neue erstetzt. Dies geschieht wie auf dieser Website beschrieben:

https://codex.wordpress.org/Changing_The_Site_URL