Die ini_get_all() Warnung in WordPress 4.6 angehen

Gestern Nacht wurde WordPress 4.6 veröffentlicht. Dieses Release glänzt mit „Shiny Updates“ sowie der Unterstützung nativer Fonts im Admin, aber vor allem unter der Haupe hat sich wieder Einiges getan. Ein großer Dank gebührt dabei neben anderen Dominik Schilling, der dieses Release in führender Rolle begleitet hat und monatelang daran gearbeitet hat. Auch dem deutschsprachigen Polyglot-Team, welches es wieder einmal geschafft hat, alle neuen Textelemente der Version rechtzeitig zur Veröffentlichung übersetzt zu haben, gebührt viel Dank.

Bisher läuft das Update ziemlich reibungslos. Ich beispielsweise hatte auf diesem Blog keinerlei Probleme. Allerdings hat sich gezeigt, dass es in manchen Server-Konfigurationen zu der Ausgabe einer kleinen Fehlermeldung kommen kann:

Warning: ini_get_all() has been disabled for security reasons in /var/www/html/wp-includes/load.php on line 1020

Was bedeutet diese Fehlermeldung

WordPress läuft mit PHP. Dein Hoster kann mit Hilfe der Datei php.ini individuell festlegen, einige Funktionen zu deaktivieren. So blockieren einige Hoster beispielsweise den Befehl system() mit dem man System-Befehle ausführen kann. In der Konfigurationsdatei findet sich dazu die Zeile disable_functions. Hier können Funktionen deaktiviert werden, welche vom Hoster als für nicht sicher erklärt werden. Wenn Du also eine solche Fehlermeldung bekommst, so wurde die Funktion ini_get_all() in diese Liste mit aufgenommen.

Das bedeutet allerdings nicht, dass Dein WordPress nun nicht mehr läuft. Allerdings erhälst Du nun eine Fehlermeldung, die ich – zumindest in meinen Tests – auch nicht unterdrücken konnte, indem ich die WordPress Konstante WP_DEBUG auf false setzte (was bei einer Liveseite automatisch der Fall ist, es sei denn, man hätte dies in der wp-config.php absichtlich geändert).

Ist mein WordPress jetzt unsicher?

Was macht die Funktion ini_get_all() eigentlich und warum wird sie in WordPress benötigt? Mit Hilfe dieser Funktion kann man die Konfigurationseinstellungen der php.ini auslesen. Für ressourcenintensive Prozesse versucht WordPress manchmal das in der php.ini gesetzte Arbeitsspeicherlimit hochzusetzen. Dies passiert beispielsweise um sicherzustellen, dass Bilder die hochgeladen werden auch korrekt verarbeitet werden können. Nun erlaubt allerdings nicht jeder Hoster die Einstellungen der Konfiguration mit Hilfe des Befehls ini_set() zu ändern. Um also für diesen Fall gewappnet zu sein führt WordPress 4.6 die Funktion wp_is_ini_value_changeable() ein. Diese Funktion prüft, ob ein bestimmter Wert der php.ini mit Hilfe von ini_set() geändert werden kann. Nur in diesem Fall wird dann versucht beispielsweise das Arbeitsspeicherlimit zu erhöhen. Eine sinnvolle Aktion also, die ein bisschen Ärger sparen kann. Nur: Um das herauszufinden nutzt wp_is_ini_value_changeable() die Funktion ini_get_all() und handelt sich damit Ärger mit anderen Hostern ein, welche es für ein Sicherheitsrisiko halten, einem PHP-Script die aktuelle Konfiguration mitzuteilen?!

Warum die Funktion als unsicher angesehen werden soll erschließt sich mir nicht ganz, allerdings wird sie im beschriebenen Kontext nicht in irgendeiner Art und Weise eingesetzt die als unsicher einzustufen wäre. Dein WordPress ist nicht unsicher wegen der Verwendung von ini_get_all().

Mittlerweile ist ein Patch unterwegs, welches dieses Problem beheben soll. Es ist also davon auszugehen, dass das Problem mit 4.6.1, welches wahrscheinlich in wenigen Tagen herauskommen wird und die ersten Stolpersteine der Version behebt, auch dieses Problem beheben wird.

Soll ich jetzt nicht updaten?

Wenn Du sicher gehen möchtest, dass Du dieses Problem nicht hast, kannst Du vor dem Update prüfen, ob die Funktion bei Dir deaktiviert wurde. Gehe dabei wie folgt vor:

Erstelle eine Datei mit folgendem Inhalt:

<?php phpinfo(); ?>

Nenne diese Datei beispielsweise phpinfo.php. Lade sie via FTP in Deinen Webspace und rufe sie im Browser unter http://deine-domain.de/phpinfo.php auf. Hier siehst Du nun eine Zusammenfassung Deines PHP-Systems. Suche hier mit der Suchfunktion des Browsers nach ini_get_all. Wenn Du nichts findest kannst Du sicher sein, dass diese Funktion nicht deaktiviert wurde.
Wichtig: Lösche die Datei phpinfo.php wieder, da diese Informationen enthält, welche Du eigentlich nicht öffentlich zugänglich haben möchtest.

Alternativ kannst Du auch auf das WordPress Plugin phpinfo zurückgreifen. Dieses Plugin gibt Dir die Informationen im WordPress Admin unter Einstellungen > WordPress phpinfo() aus.

Und natürlich: Wie bei jedem Update solltest Du auch hier natürlich zunächst ein Backup Deiner Seite angelegt haben.

Ich habe aber schon geupdated und jetzt dieses Problem

Richtig ärgerlich an diesem Problem (daneben, dass es die Seite häßlich macht) ist, dass es den Pfad zu Deiner WordPress Installation ausgibt. Das möchtest Du wirklich nicht. Prüfe bei Deinem Hoster, ob Du eine eigene php.ini für Deinen Webspace erstellen kannst. Üblicherweise findet sich so eine Information in der FAQ zu Deinem Webspace. Wenn dies der Fall ist kannst Du eine php.ini einsetzen, welche diese Funktion nicht deaktiviert. Wie Du dabei vorgehst erfährst Du üblicherweise von Deinem Hoster.

Sollte dies nicht möglich sein, bitte Deinen Hoster, diese Funktion nicht zu deaktivieren. Viele Hoster lassen sich auf so etwas ein, wenn man freundlich fragt.

Sollte auch das nicht möglich sein kannst Du zu guter Schluss folgendes machen: Gehe in die Datei wp-includes/load.php. Dort findest Du in Zeile 1020 das Problem. Dort steht:

$ini_all = ini_get_all();

Setze nun vor die Funktion ini_get_all() ein @-Zeichen:

$ini_all = @ini_get_all();

Dies wird die Fehlermeldung unterdrücken. Normalerweise würde ich niemals empfehlen die System-Dateien von WordPress zu ändern, aber in diesem Fall nimmst Du diese Änderung nur temporär vor. Änderungen in den Systemdateien werden mit dem nächsten Update überschrieben. Da das nächste Update allerdings absehbar dieses Problem angegangen sein wird willst Du ja direkt, dass deine Änderung wieder aus dem System getilgt wird.

Wie konnte es zu einem solchen Fehler kommen

Zunächst einmal, es handelt sich um eine relativ kleine Warnung die zwar ärgerlich ist aber nicht Dein System kaputt macht. Seit fast einem Monat wird WordPress 4.6 von vielen unterschiedlichen freiwilligen Helfern auf den unterschiedlichsten Serverkonfigurationen getestet und getestet. Das sind die sogenannten Release Candidates, welche vor der Veröffentlichung einer neuen Version veröffentlicht werden. Kein einziger dieser Helfer hatte allerdings eine Serverkonfiguration, bei der dieses Problem aufgetaucht wäre. Es ist also ein eher seltenes Problem. Verhindern kann jeder ein solches Problem. Gerade, wenn Du von diesem Problem betroffen bist und weist, dass Du eine eher exotische Serverkonfiguration hast wäre es super, wenn Du Dich beim nächsten WordPress Release einbringst und den Release Candidate testest. Natürlich nicht mit Deiner eigenen Webseite. Aber Du könntest ein Unterverzeichnis erstellen, in welchem Du eine Testversion von WordPress am Laufen hast. Wenn dann der Release Candidate veröffentlicht wird (worüber Du beispielsweise in den WordPress News im Admin informiert wirst) kannst Du diesen dort testen und noch bevor die nächste Version draußen ist, würdest Du sehen, ob Du in Probleme rennst wegen der neuen Version oder Deiner Serverkonfiguration. Nicht nur würdest Du Dir dann Ärger ersparen. Es ist super einfach, bei einem solchen Problem dieses schnell zu melden, so dass es gefixt würde, bevor die Version überhaupt veröffentlicht ist. Dazu gibt es das sogenannte Alpha/Beta-Forum, in welchem man sich melden kann. Je mehr Leute testen, desto weniger Fehler wird es geben! Erfahre hier, wie Du mithelfen kannst, WordPress zu verbessern.