Erste Hilfe bei plötzlich defekter Kommentarfunktion in WordPress.

Gerade habe ich eine Mail von einem Blog-Leser bekommen, der sich darüber beklagte, dass die Kommentarfunktion in diesem Weblog defekt sei. Gleich mal gecheckt und tatsächlich – so bald man versuchte, bei einem Artikel in diesem Weblog einen Kommentar zu senden, kam folgende PHP-Fehlermeldung:

Warning: get_object_vars() expects parameter 1 to be object,
null given in /webseiten/wpmu_netplanet/wp-includes/comment.php
on line 171

Ich hätte eigentlich auch schon etwas früher darauf kommen können, dass irgendetwas schief läuft, denn ich lasse mir neue Kommentare per Mail schicken und in den letzten Tagen sahen diese Mails folgendermaßen aus:

Ein neuer Kommentar zum Beitrag "TiddlyWiki 5 im Betatest."
wartet auf deine Freigabe.
https://blog.netplanet.org/2014/01/03/tiddlywiki-5-im-betatest/

Autor:  (IP:  , )
E-Mail : 
URL: 
Whois: http://whois.arin.net/rest/ip/
Kommentar:

Eine Kommentar-Mail ohne Inhalt, was bedeutet, dass WordPress zwar scheiterte beim Speichern eines Kommentares, aber immerhin die Kommentarlogik zumindest einmal gestartet wurde. Da war also tatsächlich etwas kaputt.

Bei so etwas gilt normalerweise immer das Standardprogramm an Debugging:

  1. WordPress aktuell? (Ist aktuell.)
  2. Plug-Ins installiert, die ggf. inkompatibel sein könnten?
  3. Ggf. Theme mit Problem?
  4. Datenbank bzw. Tabellen inkonsistent oder defekt?

Alle drei Problemfelder konnte ich zumindest ausschließen. Mein WordPress ist aktuell, an kommentarfunktionsspezifischen Plug-Ins habe ich in den letzten Woche nichts geändert und das Blog-Theme ist uralt und die Kommentarfunktion funktionierte vor ein paar Tagen ja auch problemlos. Zudem: Dieses Blog hier ist so aufgebaut, dass es nicht auf einer einzelnen WordPress-Installation läuft, sondern in einer Multiuser-Installation. Die anderen Weblogs auf dieser Installation laufen problemlos und insbesondere die Kommentarfunktion läuft in den anderen Blogs einwandfrei.

Das Problem ist dann letztendlich nur noch an einer Stelle zu suchen gewesen und da war dann auch das Problem: In der MySQL-Datenbank, genau genommen in den Tabellen für diese Blog-Instanz und dort in den zwei Tabellen wp_comments und wp_commentmeta. Diese beiden Tabellen, die es in einer Multiuser-Umgebung für jede Instanz gibt und die Kommentare des jeweiligen Blogs enthalten, waren inkonsistent. Das bedeutete dann, dass WordPress beim Versuch, einen abgesendeten Kommentar in die Datenbank zu schreiben, scheiterte und obige Fehlermeldung produziert. Die ist leider weitgehend nichtssagend, weil sie den Laien in die falsche Richtung führt, aber so bald die entsprechenden Tabellen z.B. in phpMyAdmin repariert werden, funktioniert alles wieder. Kleiner Fehler, große Wirkung.

Also: Kommentarfunktion in diesem Blog geht wieder. Wer in den vergangenen Tagen etwas schreiben wollte und an der defekten Kommentarfunktion scheiterte, darf das nun nachholen. 🙂

Hinterlegte FTP-Zugangsdaten aus WordPress löschen.

Mit einer korrekt installierten WordPress-Umgebung gibt es bei den meisten Webhostern keine Probleme, aus der Administrationsoberfläche heraus dateioperative Dinge zu tun, die das Hochladen von zusätzlichen Dateien in die WordPress-Installation erfordern, beispielsweise die Installation von Plugins. Für Situationen, in denen das nicht funktioniert (beispielsweise aufgrund fehlender Rechte), haben die WordPress-Entwickler eine Hintertüre eingebaut, über die das per FTP erledigt werden kann.

Kann WordPress demnach nicht selbst Dateien hochladen, fragt es den Benutzer nach FTP-Zugangsdaten, die der Benutzer hinterlegen kann. Das Problem hierbei: Einmal hinterlegte FTP-Zugangsdaten kann man nicht mehr in der WordPress-Administrationsoberfläche löschen und die Daten auch nur dann ändern, wenn der Login fehlschlägt, denn nur dann blendet WordPress nochmal das Fenster zum Eingeben der FTP-Zugangsdaten ein. Das ist unkomfortabel, aber immerhin im Backend lösbar. Dazu ist allerdings Zugriff auf die WordPress-Datenbank per PHPmyAdmin notwendig.

Und gleich die obligatorische Warnung: Wer nicht fit mit PHPmyAdmin ist und wer nicht fit darin ist, Dinge aus der WordPress-Datenbank zu löschen, sollte hier bitte die Finger weglassen oder zumindest die Datenbank vor der Operation wegsichern. Ich habe es gesagt.

Und hier nun Punkt für Punkt:

  1. Genau das, was ich oben gesagt habe – zuerst die WordPress-Datenbank sichern. Jetzt. In PHPmyAdmin also oben auf die Registerkarte „Exportieren“ gehen, voreingestellt alle Tabellen der Datenbank markiert lassen. Weiter unten den Exporttyp auf „INSERT“ belassen und ganz unten in der „Senden“-Box eine Komprimierung wählen, damit die Exportdatei nicht allzu groß wird, „Zip“ dürfte seinen Zweck erfüllen.
  2. (Punkt 1 getan? Falls nein, bitte dann jetzt nachholen.)
  3. In der WordPress-Datenbank links in der Tabellenübersicht die Tabelle „wp_options“ mit einem Klick auswählen. Wer in seiner WordPress-Installation in der wp-config.php einen anderen Präfix für seine Tabellen in der WordPress-Datenbank angegeben hat, ersetzt das „wp“ mit seiner benutzerdefinierten Präfix.
  4. In der Tabellenübersicht zu „wp_options“ nun auf die Registerkarte „Suchen“ klicken.
  5. Nun eine „Suche über Beispielwerte“ starten, das ist der Kasten unten. Hier beim Feld „option_name“ rechts in der Spalte „Wert“ den Suchbegriff „ftp_credentials“ (ohne Anführungsstriche) eingeben und auf OK klicken. Das Suchergebnis wird dann ein Ergebnis aufführen, nämlich genau den Datensatz, der im Feld „option_name“ den Eintrag „ftp_credentials“ enthält. Dieser Datensatz enthält nun im Feld „option_value“ die FTP-Zugangsdaten.
  6. Den gefundenen Datensatz ersatzlos löschen, also vorne auf das rote Kreuzchenfeld klicken. Es wird nochmal von PHPmyAdmin gefragt, ob man das wirklich tun möchte. Bestätigen, ja, wir wollen das.

Ist dies getan, sind ab diesem Moment die hinterlegten FTP-Zugangsdaten aus der WordPress-Konfiguration entfernt. Sollte WordPress wieder FTP-Zugangsdaten anfragen, dann bedeutet dies, dass die WordPress-Installation keine Rechte hat, die jeweilige Dateioperation mit den Rechten des Webservers auszuführen.

Wie ich am schnellsten einen SQL-Server ruiniere.

Würde mich jemand fragen (was natürlich niemand tut, sondern selbst ausprobiert), wie man am schnellsten und effektivsten einen SQL-Server so richtig in Schwierigkeiten reinreiten möchte, dann würde ich das so machen:

  1. Eine völlig blöde Konfiguration voraussetzen, beispielsweise alles auf einer Festplatte und alles auf einer Partition: Betriebssystem, SQL-Server-Software, Datenbankdateien, Protokolldateien. Das macht so richtig Spaß, denn wenn ein Teil dieser vier Komponenten heftig zu tun hat, dann hält es einfach alle anderen mit auf. Und wenn die Platte stirbt, wechselt dann auch einfach gleich alles das Ufer des Rubikon.
  2. Server beschäftigen und zwar in ganz großem Stil. Das macht man auf Datenbankservern gern mit „Optimierungsprogrammen“ wie Defragmentieren oder Virenscannern und lässt die dann auf Datenbank- und Protokolldateien los.
    1. Der Virenscanner wird sich redlich bemühen, gigantisch Arbeitsspeicher fressen, die Festplatte polieren und in der Regel nie etwas finden können. Denn selten liegen die Muster, nach denen ein Virenscanner sucht, genau so in einer Datenbankdatei – eine Datenbankdatei ist immer fragmentiert, hat ein eigenes Speicherformat und ist gesperrt. Besonders clevere Virenscanner setzen sich über die Sperrung hinweg und nudeln den Server auf diese Weise sehr effizient in die 386er-Klasse herunter.
    2. Der Defragmentierer wird loslegen und Teile zusammenpuzzeln wollen, die allerdings ständig in Bewegung sind. Datenbankdateien wird jeder vernünftige Defragmentierer nicht anfassen wollen, wenn sie gesperrt sind, aber an den Protokolldateien kann er sich austoben. Dabei sind Protokolldateien noch viel stärker im Fluss, denn in der Regel werden Protokolldateien von einer Datensicherung bis zum Sicherungspunkt eh wieder gelöscht oder es existiert auf einem SQL-Server, der nicht datengesichert wird (brutaler Fehler) eine Umlaufprotokollierung (noch brutalerer Fehler), d.h. ältere Protokolldateien werden gelöscht, wenn neue angelegt werden. Und wenn dann noch Mist passiert und Protokolldateien beschädigt werden, verbaut man sich damit den allerletzten Notnagel, denn Protokolldateien sind eigentlich dazu da, Operationen auf den Datenbankdateien zu protokollieren. Ohne Protokolldatei ist eine defekte Datenbankdatei nicht mehr wiederherstellbar.
    3. Datensicherungen tagsüber laufen lassen, richtig schön bei Spitzenzeiten. Dann hat auch gleich jeder etwas davon.
  3. SQL-Server-Dienste abschießen („Mann, der SQL-Server hängt aber!“) oder auch einfach den Server hart aus- und einschalten („Mann, ist die Kiste lahm“). Gern mehrfach. Ja, das Herunterfahren eines Servers, auf dem Datenbankdienste laufen, kann manchmal sehr lange dauern. Das liegt vor allem daran, dass eine gut konfigurierte Datenbank Inhalte nicht sofort in ihre Datenbankdateien kratzt, sondern im Arbeitsspeicher vorhält. Will ein Dienst beendet oder ein Server neu gestartet werden, müssen diese Inhalte möglichst logisch auf in die Datenbankdateien und das dauert. Wer hier abschießt, der wird büßen. Im günstigsten Fall rattert beim nächsten Start der SQL-Server eine ganze Weile, weil die Datenbankdateien „dirty“ geschlossen wurden, im ungünstigsten Fall erleidet man Datenverlust, weil nicht fertiggeschrieben werden konnte.
  4. Keine Datensicherung haben. Mir kann niemand erzählen, ihm wären die Daten in einer Datenbank nicht so wichtig genug, als dass man sie sichern müsste. Wären sie unnötig, hätte man keine Datenbank, fertig. Und hat man eine Datenbank, hat man sie zu sichern. Dabei genügt es nicht, einfach die Dateien zu sichern, denn ein Datenbank-Server läuft in der Regel ständig und hat, wie bereits geschrieben, gerade die Datenbankdateien exklusiv geöffnet, lässt diese also auch nicht einfach „flach“ sichern. Es braucht also entweder eine (ziemlich peinliche) Notlösung, während der Sicherung den Datenbankdienst vorübergehend zu stoppen oder es braucht eine intelligentere Datensicherungslösung, die die Datenbank auf Transaktionsebene sichert. In der Regel nicht trivial, allerdings eine Lebensversicherung. Und selbstverständlich sichert man nicht gerade dann, wenn am meisten los ist und die Datenbank auch schon ohne Datensicherung unter Druck steht, sondern verschiebt das auf eher ruhige Tageszeiten. Und ja, man testet auch gelegentlich mal, ob die Datensicherung überhaupt sichert.