Ich weiß auch nicht, warum es gerade bei einem Umzug von 1und1 zu STRATO – oder ausgerechnet bei mir – Probleme gibt, aber sie müssen gelöst werden. Nachdem auf der Startseite ein kritischer Fehler recht rabiat beseitigt wurde, tauchen die nächsten Probleme im Dashboard des Adminbereich auf. Nicht so, dass sie die Funktionalität der Website gefährden, aber schwer genug, um flüssig oder überhaupt im Dashboard arbeiten zu können. Artikelschreiben ist beispielsweise abgesagt.
Vielleicht ist der neue Fehler eine Folge meiner letzten „Problembeseitigung“? Im letzten Beitrag beschrieb ich, wie ich den „kritischen Fehler“ in Zeile 5998 der Datei formatting.php „beseitigte – ich kürzte einfach ein Array, das irgendetwas mit Emojis zu tun hat. Der kritische Fehler im Frontend war dann weg. Ob danach der Fehler im Admin Dashboard auftrat, kann ich nicht prüfen, den ohne funktionierendes Frontend kein Login ins Backend.
Natürlich berichtigte ich meine schlampige Arbeit von gestern, in der Hoffnung der neue Fehler verschwindet wieder.
Der Dreamweaver Code-Editor von Adobe ist wirklich ein sehr nützliches Tool. Fehlerhafte Codeabschnitte markiert er farbig. In Zeile 5998 fehlte tatsächlich ein erwartetes Zeichen, und zwar ein Hochkomma „'„. Mein Admin-Dashboard wurde dadurch aber nicht wieder heile, es muss ein „echter“ Fehler dran schuld sein.
Die Fehlersuche
Was ist eigentlich der Fehler? Alle Links und Elemente sind vorhanden, doch unformatiert, nicht so im Layout angeordnet, wie sie sein sollten. Der Inhaltsbereich wird am unteren Ende der kaputten Navigation angezeigt.
Dashboard: Layout zerstört
Das sieht bisher ja recht harmlos aus, das erste Bild. Vermutlich eine Datei mit Styles, die nicht geladen wird. In so einem Fall öffne ich die Website immer in einem anderen Browser. In diesem Fall im Chrome. Wie Bild Nr. 2 zeigt, ist das Dashboard in Ordnung.
Lösung (bei mir)
Ich deaktivierte und aktivierte meine FireFox-Addons. Zunächst schien es, dass ein Adblocker der Übeltäter ist. Als ich den Adblocker aber wieder aktivierte, lief dieser Bereich des Dashboards trotzdem fehlerfrei. Ich kann nicht sagen, wie die Addons im Firefox das Admin-Dashboard meiner WordPress-Seite zerstört haben könnten, aber nicht einmal Bill Gates könnte vermutlich jeden Windows-Fehler logisch erklären. Als Pragmatiker sehe ich einen verschwundenen Fehler und bin darüber froh. Schwamm drüber und für das nächste Mal gemerkt.
Die Vermutung liegt jetzt nahe, dass nach dem Providerwechsel die Schuld nicht beim neuen STRATO-Server liegt und dass alle Dateien ordnungsgemäß hochgeladen wurden. Zumindest, was diesen Bereich des Dashboards betrifft, den es gibt ja noch andere Fehler.
Gutenberg Editor arbeitet nicht
Ein Klick auf „Beiträge >> Erstellen“ (Bild 3) offenbart das Elend. Einen Beitrag zu schreiben, ist nicht möglich.
ABER: Es werden interessante Informationen zu möglichen Fehlern ausgegeben. Die WordPress REST-API ist angeblich nicht verfügbar. Ob das der gesuchte Hinweis ist?
Zuerst installiere ich deshalb den Classic-Editor für spätere Versuche. Wenn der Classic-Editor ohne REST-API auskommt und funktioniert, bin ich einen Schritt weiter in meiner Fehlersuche. Ich könnte die WordPress REST-API als Fehlerquelle ausschließen.
Aber Pustekuchen – selbst der Classic-Editor streikt.
Ich arbeite nie mit dem Classic-Editor, aber so wie im linken Bild, sollte er nicht aussehen. Als Vergleich habe ich einen funktionierenden Classic-Editor von einer funktionierenden WordPress-Installation eingefügt. An einer fehlenden REST-API kann es nicht liegen. Der Classic-Editor soll ohne REST-API arbeiten.
Aber was ist nun diese REST-API, was macht sie, wo finde ich sie?
REST API nicht erreichbar?
Eine sogenannte „REST API“ ist eine standardisierte Methode, die viele Anwendungen im Internet zur Kommunikation zwischen Server und Client nutzen. Genauere Informationen habe ich dir HIER zusammen gestellt – WordPress REST-API verstehen und deaktivieren.
Kurz: Die REST API ist eine Grundlage des WordPress-Blockeditors (Gutenberg). Ohne dieser REST-API funktioniert er nicht. Alternativ kann der Classic-Editor installiert und genutzt werden, was ich als Nächstes teste.
Meine REST-API IST erreichbar! Demo
Ein Klick auf den Link „holiday-zeit.de/wp-json/wp/v2/posts/443/“ füttert die REST-API mit einer POST-ID, welche alle Informationen zu diesem Post ausspuckt. Die WordPress REST-API funktioniert demzufolge.
REST-API wird deaktiviert – was ändert sich?
Mit dem folgenden Eintrag in der config.php deaktivierte ich die WordPress REST-API:
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');
Ich weiß nicht, was ich bei Aufruf des vorherigen Links („holiday-zeit.de/wp-json/wp/v2/posts/443/“) jetzt erwarten sollte, doch selbst die angezeigte Fehlermeldung macht mir deutlich, dass die REST-API jetzt wohl doch nicht verfügbar ist. Hat sich deshalb etwas beim Aufruf des Gutenberg- oder Classic-Editor geändert?
Der Classic-Editor – wie erwartet – zeigt sich von der fehlenden REST-API nicht beeindruckt und glänzt mit Fehlfunktionen. Weder im FireFox noch im Chrome hat sich etwas geändert – dem Editor fehlen die Bearbeitungs-Funktionen.
Ändert sich etwas bei der bisherigen Fehlermeldung im Gutenberg Blockeditor? Nein. Dieselbe Fehlermeldung wie oben, nur dass diesmal wirklich die REST-API fehlt.
Egal, ob im FireFox oder Chrome-Browser – nichts geht. Das Problem ist also (vermutlich) nicht Browser-spezifisch.
Template wechseln
Oft wird ein Template-Wechsel zu Testzwecken angeraten. Bei mir ist ein zweites Template bereits installiert, ich musste es nur aktivieren. Doch das hilft (bei mir) in keinster Weise. Dafür bemerkte ich einen weiteren Fehler.
NEUER Fehler: Der Versuch ein neues Template zu installieren, scheitert an der Möglichkeit ein Template auszusuchen.
Dort, wo sonst sich das AJAX-Ladesymbol im Kreise dreht, dreht sich überhaupt nichts. Wenn AJAX nicht funktioniert, ist es ein JavaScript Problem?
Neuer Fehler: Wird überhaupt jQuery geladen?
echo "<script type=\"text/javascript\"> if(typeof jQuery == \"function\") alert(\"jQuery geladen\"); else alert(\"jQuery nicht geladen\"); </script>";
In die \wp-admin\index.php packte ich obigen kurzen PHP Code rein. Beachte, dass die index.php im Verzeichnis wp-admin gemeint ist, die das Admin-Dashboard aufruft.
Diese wenigen Zeilen erzeugen ein Pop-up-Fenster mit einer Meldung. Auf der Website Alltag-08/15 ist alles okay und die Meldung lautet: „jQuery geladen“.
Auf der defekten WordPress-Installation unter Holiday-Zeit.de wird ein Fehler angezeigt, jQuery wurde nicht geladen.
Das Praktische: Nur wenn JavaScript im Browser arbeitet, kann diese Meldung funktionieren, denn sie besteht aus in PHP eingebetteten JavaScript-Funktionen. Damit schlägst du zwei Fliegen mit einer Klappe. Ist JavaScript überhaupt aktiv und wird jQuery geladen?
jQuery ist die Bibliothek, die bei WordPress alle Dinge regelt, die etwas mit AJAX zu tun haben. Beispielsweise eine Liste von WordPress-Themes aus dem Internet holen, ohne das Dashboard neu laden. Oder in einem Editor den Beitrag auf dem Server zu aktualisieren, ohne dass der User explizit auf „Speichern“ klicken muss.
Möglicherweise wird der Fehler im Editor erzeugt, weil jQuery nicht geladen wird. Aber es wird noch seltsamer.
Noch ein neuer Fehler?
Bei einem Test deaktivierte ich nach und nach meine Plugins. Als ich das Plugin „Real Media Library“ deaktivierte, war das Layout meines Dashboards plötzlich wieder zerschossen. Plugin wieder aktiviert –> Dashboard wieder heile. Plugin erneut deaktiviert –> Dashboard zerstört.
Das Deaktivieren eines Plugin zerschießt meine WordPress-Installation? Offenbar. Da fällt mir ein, dass ich vor ein paar Tagen ein Plugin löschte, welches eine Fehlermeldung erzeugte. Es handelt sich um das Plugin „wpDataTables“.
Schnell habe ich es wieder installiert. Diesmal erzeugte WordPress keine Fehlermeldung bezüglich dieses Plugin und war neugierig, was passiert, wenn ich es wieder deaktiviere. Dabei stellte ich erstaunlicherweise folgendes fest: Solange ich eines der beiden Plugins aktiviert habe, wird das Layout meines Dashboard nicht zerstückelt.
Das Dashboard wird zerstört, wenn eines der beiden Plugin deaktiviert ist:
- Real Media Library
- wpDataTables
Okay, erklären kann ich dieses Verhalten nicht, aber damit leben. Der (für mich) wichtigste Fehler ist der nicht funktionierende Editor – egal ob Classic oder Gutenberg Blockeditor.
Sicher weiß ich bisher nur, dass JavaScript ordnungsgemäß ausgeführt wird, jQuery aber nicht geladen wird.
Was sagt die FireFox Konsole?
Mit der Funktionstaste F12 aktivierst du die Firefox Tools für Webentwickler im unteren Browserbereich, einen Werkzeugkasten für Entwickler und Programmierer. Die Browserkonsole ist (für mich) eines der letzten Mittel im Kampf gegen kaputte Webseiten. Wenn etwas nicht stimmt – hier bekommst du es heraus.
Angezeigt bekomme ich eine sehr lange Liste mit Fehlermeldungen, die wahrscheinlich alle auf einen oder wenige Fehler zurückzuführen sind. In der Datei jquery.min.js wurden Zeichen in Zeile 3 gefunden, die dort nicht hingehören, sagt die Konsole.
Und tatsächlich zeigt mein Dreamweaver-Editor an dieser Stelle Zeichen, die als Fehler markiert werden. Dieser Fehler muss sich beim Download der Datei vom alten Server auf meinem PC eingeschlichen haben, den auf meinem alten Server, wo die Dateien noch liegen, ist kein Fehler eingebaut. FileZilla muss etwas mit den Daten gemacht haben.
Schnelle Abhilfe: Die Datei lud ich neu aus dem Internet herunter und baute sie in meinem WordPress sein – zumindest dieser Fehler wird jetzt nicht mehr angezeigt.
Bedenklich stimmt mich allerdings: Wenn beim Download der Dateien solch ein Fehler passieren konnte – welche Dateien sind noch „verhunzt“?
FEHLER gefunden: FTP-Programm (FilleZilla) beschädigte Dateien
Es lies mich nicht los, dass beim Download mein FTP-Programm einige Dateien eigenständig umschrieb.
Das Problem war bald gefunden – der Standard-Übertragungstyp bei dem FTP-Programm FilleZilla sollte statt „Automatisch“ lieber „Binär“ sein.
Ich weiß nicht warum, aber dieser Ratschlag aus dem Internet löste ein Problem, behob einen Fehler. Vom alten Server lud ich alle Dateien erneut – im binären Modus – herunter und spielte sie auf den neuen Server auf. Und siehe da – alles wieder gut!
Fazit
Der Umzug von WordPress ist – eigentlich – eine simple Sache und bereitet keine Probleme. Doch wenn einmal der Teufel drin steckt, dann richtig. In meinem Fall beschädigte ein ungünstiger Übertragungstyp im FTP-Programm beim Download verschiedene JavaScript-Dateien und sorgte so für ein seltsames Verhalten meiner WordPress-Website.
Ich gehe davon aus, dass viele von Euch ihr FTP-Programm im Automatik-Modus nutzen und dementsprechend wird es viele geben, die ebenfalls vor unerklärlichen Problemen bei ihrem WordPress-Umzug stehen.
Die gängigen Hilfestellungen aus dem Internet halfen in meinem Fall nichts. Ich musste mich systematisch (wie ein Ur-Mensch) per „Trial and Error“ durch meine WordPress-Installation arbeiten und vermutlich hat die Präsentation dieser Wege viele abgeschreckt. Doch mal ganz ehrlich: Wer nicht lernt selbst zu denken, zu experimentieren, Fehler selbst zu suchen – wird es im Leben überall schwer haben.
.
Rubrik (deutsch): Tutorial, Anleitung, Fehler, Probleme, Hilfe
