Keine Panik

In der britischen Sitcom The IT Crowd beantwortet der erfahrene Servicemitarbeiter Roy alle (wirklich alle) Anfragen zu IT-Problemen mit der Gegenfrage „Have you tried turning it off and on again?“ („hast du versucht, es aus- und wieder einzuschalten?“). Bei Fragen zu WordPress kommt man damit alleine zwar selten weiter, aber tatsächlich lassen sich die meisten Probleme schon mit wenigen Handgriffen beheben.

Schnappatmung: Der White Screen of Death

Häufiger berichten Anwender, dass ihre Website nur noch eine völlig leere, weiße Seite anzeigt – und zwar sowohl im Front- als auch Back End! Dieser Umstand wird auch gerne scherzhaft als „Weißer Bildschirm des Todes“ bezeichnet, weil schließlich gar nichts mehr funktioniert. Was für Anwender nach einer mittleren Katastrophe aussieht („sind jetzt etwa meine ganzen Daten weg?“), ist in den meisten Fällen aber recht einfach zu reparieren.

Der Hintergrund: Enthält ein Plugin oder Theme einen Programmierfehler, schaltet PHP die Ausgabe komplett ab, damit mögliche Angreifer nicht obendrein Schwachstellen auf dem Silbertablett serviert bekommen. Die Lösung ist also, die defekte Software zu lokalisieren und abzuschalten.

Ist das Back End von WordPress nicht mehr erreichbar, lassen sich Plugins durch Umbenennen des Verzeichnisses wp-content/plugins vorübergehend deaktivieren. Dies kann entweder über die Dateiverwaltung des Webhoster (so genanntes WebFTP) oder mit einem FTP-Programm wie z.B. FileZilla erfolgen. Die notwendigen Zugangsdaten lassen sich im Kundenmenü des Webhoster nachlesen.

Wurde das Plugin-Verzeichnis umbenannt, deaktiviert WordPress automatisch beim nächsten Zugriff auf das Back End alle Plugins und schaltet so ggf. auch die Ursache für das Problem ab.

Wird das Verzeichnis nun wieder zurückbenannt, kann der Benutzer die Plugins wie bei einem Sicherungskasten nach und nach wieder aktivieren, bis die Website erneut einen Fehler aufweist. Dieser Fehler lässt sich dann auf das zuletzt aktivierte Plugin zurückführen, das direkt aus dem Verzeichnis wp-content/plugins gelöscht werden kann. Anschließend sollte sich der Benutzer mit dem Support des Plugin-Entwicklers in Verbindung setzen und die Schwierigkeiten schildern. Dabei darf man mit gutem Gewissen die Frage „did you turn it off and on again?“ mit einem „Ja“ antworten.

Konnte der Fehler durch Umbenennen des Plugin-Verzeichnisses nicht behoben werden, kann als nächstes das Verzeichnis des aktuell aktivierten Themes in wp-content/themes umbenannt werden. Dazu sollte aber als Rückfall-Option eines der bei der Installation mitgelieferten Standard-Themes („Twenty …“) installiert sein.

Nützt auch das nicht, hilft vielleicht ein Austausch der WordPress-Dateien. Da einige FTP-Programme bereits auf dem Server vorhandene Dateien ohne Nachfrage überspringen, ist es sinnvoll, alle WordPress-Dateien zuerst auf dem Server zu löschen. Dabei müssen natürlich selbst hinzugefügte Dateien ausgespart werden: Die Konfigurationsdateien wp-config.php und .htacess sowie das gesamte Verzeichnis wp-content dürfen nicht gelöscht werden.

Anschließend wird bei WordPress ein frisches WordPress-Paket heruntergeladen, entpackt, aus diese Paket das Verzeichnis wp-content gelöscht und die verbleibenden Dateien auf den Webserver hochgeladen. Zur Erinnerung: Die Inhalte der Website und auch alle Einstellungen sind in der Datenbank gespeichert und werden durch den Austausch der WordPress-Dateien gar nicht berührt. Alle hochgeladenen Mediendateien, Themes und Plugins befinden sich im Verzeichnis wp-content, das bewusst ausgespart wurde.

Bluthochdruck: falsche URL

Manchmal sitzt die Ursache für eine defekte WordPress-Installation vor dem Bildschirm. Gar nicht so selten berichten Benutzer, dass sie (warum auch immer) im Back End unter Einstellungen > Allgemein die WordPress- bzw. Website-Adresse verstellt hätten und nun nicht einmal auf das Back End zugreifen können, um diese Einstellung wieder rückgängig zu machen.

Glücklicherweise hilft hier ein kleiner Kunstgriff: In der Konfigurationsdatei wp-config.php wird oberhalb von /* That's all, stop editing! Happy blogging. */ eine weitere Zeile mit folgendem Code eingefügt: define('RELOCATE', true);.

Sobald die Datei abgespeichert wurde, lässt sich in den meisten Fällen das Back End wieder über den üblichen Link erreichen und die fehlerhaften URLs können korrigiert werden.

Damit niemand diese Einstellung missbrauchen kann, sollte die Codezeile in der wp-config.php nach gelungener Korrektur wieder gelöscht werden.

Schweißausbrüche: Website gehackt

WordPress ist weit verbreitet und deshalb ein lukratives Ziel für Angreifer, die vor allem schwache Passwörter und nicht aktualisierte Plugins ausnutzen, um in möglichst vielen Websites Malware unterzubringen. Oft bemerken Benutzer die Schadsoftware erst, wenn ihre Website durch den Webhoster gesperrt wurde oder Google auf eine Infektion hinweist.

Es ist zwar naheliegend, offensichtlich infizierte Dateien auszutauschen, nur werden dabei oft Hintertüren übersehen, die der Angreifer an unauffälligen Stellen platziert hat – etwa PHP-Code in vermeintlichen Mediendateien. Deshalb lautet die Grundregel: Keine Nachbesserungen (Patches) in einzelnen Dateien.

Statt dessen sollten (wie bereits weiter oben beschrieben) die WordPress-Dateien, aber auch alle Themes und Plugins durch frische Dateien aus dem WordPress-Repository (oder anderen als sicher geltenden Quellen) ausgetauscht und alle Dateien im Verzeichnis wp-content sehr sorgfältig auf eine mögliche Manipulation geprüft werden. Besser (und in den meisten Fällen auch effizienter) ist die Wiederherstellung eines unkompromittierten Backup.

Zusätzlich müssen natürlich alle Zugangsdaten ausgetauscht werden – also nicht nur die für WordPress selbst, sondern auch die Zugangsdaten für den FTP-Zugriff, die MySQL-Datenbank und auch das Kundenmenü des Webhoster. Abgesehen davon können auch eine Malware-Infektion des eigenen Computers oder der unbedachte Zugriff auf das Back End von WordPress über eine unverschlüsselte Verbindung im öffentlichen W-LAN Ursache für den Angriff gewesen sein.

Ein echter Grund zur Sorge: Fehlende Backups

Eine gute Anlaufstelle bei Fragen rund um WordPress ist das deutschsprachige WordPress Support-Forum. Während sich geschätzte 80% aller Anfragen in diesem Forum bereist mit den o.g. Handgriffen beheben lassen, wird es wirklich problematisch, wenn der Benutzer fahrlässig auf Backups verzichtet hat. Wurden etwa durch Fehleingabe des Benutzers oder Angriff eines Hackers die Einträge in der Datenbank unwiderruflich gelöscht, hilft auch keine Zeile Code mehr, um sie wiederherzustellen.

Mitunter ist der letzte Strohhalm, nach dem verzweifelte Benutzer greifen können, das Backup des Webhoster. Je nach Anbieter wird für die Wiederherstellung der WordPress-Installation zwar eine Gebühr fällig, die aber meist in keiner nennenswerten Relation zur sonst verloren gegangenen Arbeit steht.

Manche Webhoster bieten sogar über die im Kundenmenü angebotenen Wiederherstellungsoptionen hinaus noch die Möglichkeit, auf deutlich ältere Sicherungen zurückzugreifen. Hier hilft ein Anruf beim Support des Webhoster.

Wie auch immer: Keine Panik!

Sicher gibt es auch noch anderen Gründe, warum eine WordPress-Website nicht wie gewünscht funktioniert. Viele Fragen können schon im erwähnten WordPress Support-Forum beantwortet werden; bei Fragen zu kommerziell vertriebenen Themes und Plugins sollte sich der Benutzer mit dem Vertrieb oder Support des Entwicklers in Verbindung setzen.

Bei allen Fragen zur Serverkonfiguration (z.B. Einstellungen zur verwendeten PHP-Version, nutzbarem Arbeitsspeicher oder Limits für den Datei-Upload), die sich nicht durch einen Blick in das Kundenmenü des Webhoster beantworten lassen, sollte der Support angesprochen werden. Spätestens hier zeigt sich, ob die monatlichen Kosten für Webhosting gut angelegt sind.

Panik ist ein schlechter Ratgeber. Dies gilt auch, wenn einem die eigene WordPress-Installation unerwartet Sorgen bereitet. Wer jetzt kopflos handelt, verschlimmert die Situation unnötig und verbaut Wege zur Wiederherstellung seiner Website. Ein Backup, eine gute Tasse Tee und ab und zu ein Spaziergang um den Block haben schon viele Websites wieder zum Laufen gebracht.