WordPress Internal Server Error Investigation

… und am Ende ist es vielleicht doch nur ein chmod 644-Verstoß

Das Nightly Build als Lebensinhalt eines Programmierers

Die kalte einsame Winternacht (-12  °C), ist die richtige Zeit das eine oder andere produktive Kundensystem zu aktualisieren (upzudaten). Der Terminus Nightly Build wird vermutlich aus diesem Grund und als Wesensmerkmal von Programmierern entstanden sein. Wir gehen ja nie  jedes Update immer sofort mit, sondern warten, auf die wertvollen Erfahrungen mutiger Supporter, um aus ihrem Fundus zu schöpfen. Unsere eigene Erfahrung sagt: 9 von 10 sehr umfangreichen Updates laufen dank der robusten Technik und ausgereiften Software problemlos ab. Aber genau hier lauert die Gefahr, wer die Sorgfalt missen lässt und allen Empfehlungen zum Trotz kein aktuelles Backup zieht, schaut hinterher vielleicht dumm aus der Wäsche. Deshalb haben wir uns vor einem Update folgendes Vorgehen angewöhnt: wir ziehen die Programmdaten und den Datenbank-Dump lokal herunter und erstellen zusätzlich ein Serverbackup. Gleichzeitig orientieren wir uns z.B. an den gut dokumentierten Versionsunterschieden von WordPress (das ist dann hilfreich, falls man mal die eine oder andere Datei zurückspielen will).

Ein fremder Server und der Tanz beginnt

Mit dem Backup ist der wichtigste Teil erledigt. Abschalten der Plugins und im Fall von BuddyPress wechsel auf das Standard WordPress Theme folgen. Und nun sollte das WordPress Update reibungslos funktionieren. Der Link ist schnell geklickt. Da hakt was… INTERNAL SERVER ERROR the server encountered an internal error or misconfiguration and was unable to complete your request.

Merkwürdig. Der Fehler ist nicht generell, denn das Frontend ist problemlos zu erreichen. Aber das Backend ziert sich, erst ein Aufruf von wp-admin löst den Fehler aus.

Einmal tief schlucken und den Blick und das Ohr zur Absicherung auf den ruhigen, gleichmässigen Umlauf der Backup-Platte gerichtet. Maßnahmen prüfen – waren alle Plugins deaktiviert? – Es kann nämlich immer vorkommen, dass das eine oder andere Plugin mit dem Update Probleme verursacht. Sollte hier also die Ursache liegen – könnte man den Plugins-Ordner umbenennen und durch einen leeren Plugin-Ordner ersetzen, denn selbst deaktivierte Plugins könnten noch Fehler auslösen. Man könnte aber auch durch die direkte Manipulation in der Datenbank alle Plugins nachträglich durch ein SQL-Statement abschalten:

1.  SELECT * FROM deinwpprefix_options WHERE option_name = 'active_plugins';

liefert die Parameter aller aktiver Plugins. Ich empfehle das Abfrageergebnis abzuspeichern, um anhand dieser Liste dann die Plugins sukkzessive wieder anzustellen, um ggf.das Problemplugin ausfindig zu machen.

2. (ab WordPress 2.9 +)  aktualisiert man diese Tabelle mittels UPDATE deinwpprefix_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';

Das war es schon, nun sind alle Plugins deaktviert.

Ok… bei uns lag es nicht an den Plugins. Die Ursachenforschung ging weiter (Tipp am Rande: ein Blick in den Serverlog kann jetzt schon Zeit sparen). .htaccess ist immer mal wieder ein Kandidat, der Probleme macht, insbesondere nach einem Serverwechsel. Da wird leicht mal vergessen die Serverbasis zu ändern, bzw. darauf vertraut, dass die Servereinstellungen (z.B. redirect und mod_rewrite) des aktuellen Servers mit denen des Alten identisch sind. Besonders hakelig und auch immer mal wieder der Grund für einen 500 INTERNAL SERVER ERROR sind die Eingriffe die das super nützliche Plugin W3 Total Cache vornimmt. Aus diesen Grund legen wir immer eine Basis-.htaccess mit auf dem Server ab, auf die man zur Not schnell zurückgreiffen kann. Ok das war es bei uns auch nicht. Es half auch nicht der nützliche Tipp die Scriptladezeit und die Memory-Zuweisung im Unterverzeichnis von wp-admin gesondert durch eine PHP.ini zu unterstützen.

In einem Texteditor (ich liebe Notepad++)  wird die PHP.ini erstellt. Die Werte wie 120 Sek. oder 128 Mbyte können variiert werden :

Die PHP.ini sieht dann z.B. entweder so:
register_globals off
register_globals = 0
memory_limit = 128M
max_execution_time = 120

oder so aus:
memory_limit = 128M
max_execution_time = 120

Ok das war es auch nicht. Der frühe Systemabbruch beim Versuch des automatischen Update hätte mich stutzig machen müssen. Tipp am Rande: ein Blick in den Serverlog hätte Zeit sparen können und liefert immer mal aufschlussreiche Erkenntnisse, aber manchmal steht man sich selber im Weg. In unserem Fall stellte sich heraus, dass eine Reihe von Dateien (chmod) mit den Berechtiungen 664 gegen Zugriffsrechte des Servers verstiessen. Der Grund warum sie auf 664 standen ist noch zu recherchieren (Sicherheitslücke? Ein Eindringling?)  Jedenfalls wurde der Sicherheitsverstoß mit dem Zeitpunkt des automatischen Updates ausgelöst. Aber nach dem die geforderten Dateirechte 644 wieder hergestellt waren, verschwand auch der INTERNAL SERVER ERROR im Server-Nirwana und der kalte Kaffee im Ausguss. Das WordPress Update lief nach manueller Installation reibungslos und die Plugins inklusive der automatische BuddyPress Update konnten sukzessive und problemlos reanimiert werden.

DAS SAGT DIE WELT

COMPANY CUSTOMER PACT

ein Herz für unsere KundenWir glauben an gute Kundenbeziehungen und offene Kommunikation miteinander.