WordPress: Fehlersuche bei kritischem Fehler nach Providerwechsel | Lösung

Möglicherweise bist Du Quereinsteiger, hast den vorherigen Beitrag nicht gelesen. Aus diesem Grund eine kurze Zusammenfassung zum Thema „Domain & WordPress umziehen“.

Umzug der Domain

Zuerst brauchst Du von 1und1 einen „Autorisierungscode“, den Du später bei Strato eingeben musst. Gehe in dein 1und1 Domain-Center, klicke bei der betreffenden Domain im Menü „AKTIONEN“ auf „Umzug & Verlängerung“. Im folgenden Fenster gehst du auf „Autorisierungscode anzeigen“.

Melde dich danach bei Strato an und „bestelle“ in der Domainverwaltung deine eigene Domain, die Du von 1&1 nach Strato portieren möchtest.

Diese findest du ganz unten als letzte Domain aufgelistet.

Klick auf den blauen Button „Umziehen“. In der folgenden Seite wirst du nach deinem Umzugs-Code gefragt, dem Autorisierungscode. Trag ihn ein, scrolle runter, aktiviere das Häkchen bei der Bestätigung der STRATO-AGBs und klicke auf „Domain bestellen“. Innerhalb von zwei Stunden ist der Umzug vollzogen.

Datenbank-Konfiguration ändern

Die Daten zur Datenbank findest du in der Datei „wp-config.php“ im Root, also dem Hauptverzeichnis deiner WordPress-Installation. Trage hier die bei STRATO hinterlegten Daten ein.

Mit den drei Angaben DB_NAME, DB_USER und DB_PASSWORD ist jedoch nicht getan. STRATO hat einen anderen Hostnamen. Statt „localhost“ muss bei „DB_HOST“ jetzt noch „rdbms.strato.de“ eingetragen werden.

/** MySQL hostname */define('DB_HOST', 'rdbms.strato.de');

Jetzt geht es los – Die Fehlersuche!

Du hast meine Ratschläge befolgt, genauso wie ich die Ratschläge Anderer befolgte und nichts klappt? Willkommen im Club.

Es gab einen kritischen Fehler auf Deiner Website. Was sind die Ursachen für diese Fehlermeldung, welche Lösungen gibt es, was schafft Abhilfe bei diesem Problem? Nun, diese Meldung kann wirklich alles Mögliche bedeuten. Anhand dieser Meldung wirst du in keinster Weise schlau.

Die üblichen Verdächtigen

• 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 und „Trial and Error“

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.

DEBUG-Modus entdecken und 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. Warum das nun plötzlich bockig wurde – keine Ahnung. Vor dem Umzug lief alles super. Stimmte etwas mit einem Zeichensatz, einer Codierung nicht? Ebenfalls keine Ahnung. Ich war an dieser Stelle einfach nur verdammt froh, einen Fehler gefunden zu haben, den ich entfernen kann. Wie?

Ohne mich lang mit Grundsatzfragen abzugeben, „schnitt“ ich den Fehler einfach aus dem Array heraus. Ich nutzte nie Emojis im Editor. Hingegen bin ich darauf angewiesen, dass Google meine Website schnell wieder findet und sie nicht aus den SERPS kickt.

Das war nicht der einzige Fehler …

Dieser Beitrag ging der Frage auf den Grund, warum bei mir ein kritischer Fehler im Frontend meiner Website gemeldet wurde. Bei Dir können andere Dinge dafür verantwortlich, doch vielleicht hat meine Art & Weise zu „arbeiten“ Dir etwas geholfen.

Obwohl die Webseite zunächst läuft, haben sich andere Fehler manifestiert. .

Das Gute: Das Frontend funktioniert wieder, die Website ist erst einmal erreichbar und der Google-Bot findet wieder genügend Futter.

Das Ungünstige: Der Adminbereich – ist „zerschossen“. Prinzipiell sind alle Links vorhanden, doch unformatiert. Der Inhaltsbereich, welcher rechts neben der Navigation stehen sollte, wird am unteren Ende der kaputten Navigation angezeigt.

Weiterhin zickt ein Plugin herum, das ich Quellcode-technich nicht anfasste. Um diese Probleme und andere Fehlermeldungen geht es in den nächsten Beiträgen, zu berichten gibt es noch einiges. In Zukunft werde ich WordPress-Umzüge garantiert einem Plugin anvertrauen, dass auf diese Arbeit spezialisiert ist.

Rubrik (deutsch): Tutorial, Anleitung, Fehler, Probleme, Hilfe