WordPress interner Serverfehler – was tun?
Vor nicht allzu langer Zeit hatte ich nach einem WordPress-Update das Problem, einen Internal Serverfehler 500 anstatt eines WordPress Blogs mein Eigen zu nennen. Erst kürzlich bin ich wieder über einen Beitrag in einem Post in einer WordPress & SEO Facebook-Gruppe bezüglich desselben Problems gestolpert. Daher würde ich euch heute mal ein paar Tipps zeigen, wie man unter Umständen die eigene WordPress-Seite doch noch retten kann.
Ein paar generelle Tipps
Bitte regelmäßige Backups machen
All denjenigen, die sch bisher nicht mit dem Thema Datensicherung beschäftigt haben, würde ich zumindest aufgrund der eigenen Erfahrungen raten, sich falls nicht schon vorhanden oder regelmäßig durchgeführt ein Backup-Tool für die WordPress-Seite zuzulegen. Das Plugin UpdraftPlus nutze ich zum Beispiel. Einmal mit der Dropbox oder Google Drive verknüpft leistet es gute Dienste, ohne, dass man Gefahr läuft, das regelmäßige Backup zu vergessen, was bei manuellen Backups ja gut möglich ist. Ich habe es auf 1x wöchentlich gesetzt, was bei einem privaten Blog wohl ausreichend sein sollte, natürlich geht dies auch häufiger.
Eine veraltete Version ist ein Scheunentor für jedwede Malware
Egal ob WordPress oder Joomla, bitte aktualisiert eure Template-Engine regelmäßig! In dem Beitrag in der Facebook-Gruppe, den ich oben erwähnte, meinte die Threaderstellerin tatsächlich, sie habe WordPress in der Version 3.irgendwas – das bedeutet praktisch, dass die WordPress-Version auf ihrer Website 5 Jahre (!) alt ist und auch genau so lange nicht mehr aktualisiert wurde! Das öffnet natürlich Tür und Tor für alle möglichen Angriffe, da es seitdem zig Sicherheitslücken gab, die durch Updates, hätte man sie eben durchgeführt, behoben werden hätten könnten zumal es ja auch gut sein kann, dass es zu Problem bei Aktualisierungen von Plugins, die eine bestimmte Version voraussetzen, auftreten, wenn diese veraltet ist.
Nun mein Lösungsansatz
Ein Satz noch vornweg: Ich kann nicht garantieren, dass es immer funktioniert, aber ich denke, die im Folgenden geschilderte Vorgehensweise sollte in den meisten Fällen Abhilfe schaffen.
1. PHP Memory checken
Vor dem Loslegen sollte man sich bei seinem Webhoster einloggen und mal schauen, ob es was bringt, das PHP Memory Limit zu erhöhen. In meinem Fall war es leider nicht hilfreich, aber falls es doch daran liegen sollte, dass dieses mittlerweile zu niedrig ist, ist das ein wichtiger Schritt und man kann sich den Rest sparen.
2. Ist ein Einloggen im Adminbereich der Seite noch möglich? (wenn nicht, weiter zu Punkt 3)
Vermutlich hat dann die .htaccess – Datei einen Schaden abbekommen. Diese befindet sich direkt im Root-Verzeichnis der WordPress-Installation. Am Besten ist es, die bestehende .htaccess einfach umzubenennen, z.B. in .htaccess_alt. Ist die Datei nicht auffindbar? Je nach FTP-Client kann es sein, dass man erst mal die Ansicht für versteckte Dateien aktivieren muss, was je nach FTP-Client anders sein kann, hier muss man halt Google zu Rate ziehen (bei den meisten FTP-Clients sollte die Datei aber sichtbar sein). Wurde jetzt die aktuelle .htaccess umbenannt, muss man ins WordPress-Backend und dort unter Einstellungen -> Permalinks ohne dort irgendetwas zu ändern auf „Speichern“ klicken. Dies sorgt dafür, dass automatisch eine neue, funktionierende Version dieser Datei erstellt wird (falls man doch noch irgendwann die alte braucht, ist diese ja auch noch vorhanden, halt unter dem geänderten Dateinamen).
3. Das Einloggen im Adminbereich der Seite ist NICHT möglich
Das war in meinem Fall so. Was tun also?
Dateien lokal speichern
Erst loggt man sich mittels FTP-Client ein (Die Zugangsdaten kann man beim Webhoster einsehen und einen guten FTP-Client kann man kostenlos herunterladen falls man keinen hat, z.B. Filezilla für Windows oder in meinem Fall Cyberduck für Mac OS). Jetzt lädt man sich einfach alle Dateien der WordPress-Installation herunter. Sind alle Dateien lokal gespeichert? Gut, dann (aber nur dann) kann man die Dateien auf dem Server löschen.
WordPress neu installieren
Jetzt geht man auf WordPress und installiert sich die aktuelle WordPress-Version: https://de.wordpress.org/txt-download/
Auf der Seite findet man auch eine Anleitung. Damit die Installation richtig funktioniert, muss man in die Datei wp-config die nötigen Datenbankeinträge einfügen. Diese findet man ebenfalls beim Webhoster.
Bilder, etc. wiederherstellen
Unter der Voraussetzung, dass das letzte Datenbankupdate nicht Jahre her ist, müssten nachdem die wp-config nun geändert wurde, eigentlich die Beiträge vorhanden sein. Nachdem es wahrscheinlich ist, dass der Serverfehler 500 aufgrund einer kompromittierten Datei aufgetreten ist , würde ich den wp-content Ordner nicht komplett durch den alten, den man ja lokal gespeichert hat, ersetzen. Es kann nämlich gut sein, dass irgendwo in diesem Ordner die kompromittierte Datei herumfliegt und es einem die schöne neue Installation gleich wieder „zerschießt“. Ich hatte das selbst erst versucht und musste dann alles noch mal erneut aufsetzen, daher spreche ich aus Erfahrung.
Sicherer ist es, das Ganze sukzessive zu gestalten und wirklich nur die Unterordner aus dem wp-content Ordner durch die alten zu ersetzen, die man braucht. In meinem Fall war das der Ordner uploads aus dem wp-content Ordner. Hier befinden sich die Bilder zu den Beiträgen und das Header-Bild. Diesen habe ich hochgeladen und somit den neuen, leeren Ordner durch den alten mit den Inhalten ersetzt. Die Bilder wurden auch wieder mit den richtigen Beiträgen zugeordnet, Datenbank sei Dank!
Hat man nicht zig Templates und Plugins, würde ich das Ersetzen lediglich des uploads Ordners empfehlen, denn lieber installiert man sich alles neu aus dem Backend und ist auf der sicheren Seite, als dass man wieder in die Ausgangssituation kommt (internal Server Error). Hat man aber das Bedürfnis, doch die Ordner mit den Templates / Plugins zu ersetzen, sollte man dies zumindest sukzessive nach dem Ausschlussprinzip tun. Sprich Ordner für Ordner, so kann man dann erkennen, ab welchem Unterordner es alles zunichte macht und weiß zumindest, dass sich in diesem die fehlerhafte / gehackte Datei befindet.
Fazit: Lernen durch „Schmerzen“ – regelmäßige Updates sind essentiell!
Seitdem meine Seite gehackt wurde, wovon ich mal ausgehe (in meinem Fall befanden sich in meiner Datenbank ominöse .ru-E-Mail-Adressen irgendwelcher User) benutze ich für automatische Updates UpdraftPlus, kostet nix und tut, was es soll. Ich hoffe, dieser Post hilft der / dem ein- oder anderen mit diesem Problem weiter, denn in meinem Fall war es ziemlich zeitintensiv, bis ich wirklich durchgeblickt habe bzw. eine Idee davon hatte, wie man in so einem Fall am Besten vorgeht.