Umzug Website 1&1 IONOS zu STRATO: Probleme & Fehlersuche

Probleme beim WordPress Umzug: Fehlersuche und Hilfe

Du hast alle Ratschläge aus dem vorherigen Beitrag „Domain/Website von 1&1 (IONOS) zu STRATO umziehen“ befolgt, aber nach dem Umzug der Domain von 1&1 IONOS zu STRATO funktioniert die WordPress-Website nicht mehr?

Willkommen im Club. Es gibt viele Artikel mit entsprechenden Anleitungen im Internet – doch wenn etwas nicht klappt, hast Du oft ein Problem, welches nicht im Artikel behandelt wird.

Diese Fehlermeldung kann alles Mögliche bedeuten. Ich hatte sie auch schon bei einem veralteten Plugin. Aus dieser Meldung wirst du nicht schlau.

Fehlerquellen: Die üblichen Verdächtigen bei einem Website-Umzug

Natürlich nannte ich auf dem Server den Plugin-Ordner kurzzeitig um, damit ich ein Plugin als Fehlerquelle ausschließen kann. Nix Erfolg.
Ich kontrollierte, ob alle Dateien fehlerfrei auf den neuen Server hochgeladen wurden. Wurden sie.
Wurde die richtige Datenbank in die wp-config.php eingetragen? Ja.
Sind alle Tabellen in der neuen Datenbank vorhanden? Ja.

Mit System, „Trial & Error“ Umzugs-Fehler finden

Nun ging ich systematisch vor, fing bei der index.php im Hauptverzeichnis an. Ihr spendierte ich eine kleine Zeile PHP-Code:

echo "index.php wird geladen";

Die nächsten Dateien, welche von WordPress geladen werden, sind:

wp-blog-header.php
wp-load.php
wp-config.php
wp-settings

Ihnen spendete ich allen meinen kleinen Code und alle Dateien zeigten an, dass sie geladen wurden. Die Webseite sah ich aber dennoch nicht.

Stimmte etwas mit den Datenbank-Zugangsdaten nicht? Um das zu prüfen, schummelte ich Fehler in die wp-config.php einer anderen WordPress-Installation rein und schaute, was WordPress in so einem Fall für eine Fehlermeldung ausspuckt. Jetzt wusste ich: Die Angaben zu meiner Datenbank waren NICHT der Fehler.

Fehler nach dem WordPress-Umzug suchen: DEBUG-Modus nutzten

Als ich die wp-config.php weiter Zeile für Zeile durchging, fiel mir der Eintrag „define (‚WP_DEBUG‘, false);“ auf. Na klar, WordPress hat eine Debug-Funktion. Sie ist aber nicht in jeder wp-config.php eingetragen oder auf „true“ gesetzt und es müssen auch noch weitere „Dinge“ aktiviert werden.

define ('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define ('WP_DEBUG_DISPLAY', true);

WP_DEBUG aktiviert den Debug-Modus. WP_DEBUG_LOG legt im Ordner „wp-content“ ein Logfile an und WP_DEBUG_DISPLAY zeigt die Fehlermeldung direkt im Browser an. Letzteres sollte eventuell auf ‚false‘ stehen, den es wird die Fehlermeldung:

„Warning: Cannot modify header information – headers already sent by (…)“

ausgegeben. Am Ende ist das aber wiederum egal, weil die Webseite ja eh (noch) nicht funktioniert.

… tatsächlich wurde ein (der?) Fehler angezeigt

[23-Apr-2022 06:34:08 UTC] PHP Parse error: syntax error, unexpected token „;“, expecting „)“ in /mnt/web202/a1/51/59419051/htdocs/d_holiday/wp-includes/formatting.php on line 5998

Der Fehler lag in den Daten eines Arrays. Ganz pragmatisch schnitt ich diesen Fehler zunächst einfach aus dem Array heraus. Die Website wurde jetzt wieder angezeigt und ich konnte mich in den Admin-Bereich wieder einloggen.

Den Grund für diesen Fehler erkannte ich erst im nächsten Abschnitt – als ich ein zerschossenes Backend vorfand.

Beim Download der Dateien vom alten Server herunter, schrieb FileZilla einige Dateien eigenständig um. Der Standard-Übertragungstyp bei dem FTP-Programm sollte auf „Binär“ eingestellt sein.