PHP: Wie bringt man Fehlermeldungen zur Anzeige?

  • 28. August 2026
  • 3 Minuten zum Lesen
  • Zuletzt aktualisiert: 28. August 2026

Du rufst dein Skript auf und bekommst eine weiße Seite. Keine Meldung, kein Hinweis, nichts. Das ist einer der frustrierendsten Momente in der PHP-Entwicklung, und die Lösung besteht aus genau zwei Einstellungen.

Die zwei Einstellungen

Damit du eine Fehlermeldung zu sehen bekommst, müssen beide Einstellungen passen:

<?php
  ini_set('display_errors', '1');
  error_reporting(E_ALL);
?>

display_errors entscheidet ob überhaupt etwas ausgegeben wird. error_reporting entscheidet welche Meldungen das sind. Wer nur eine von beiden setzt, sieht weiterhin nichts oder nur einen Teil.

Was die weiße Seite eigentlich ist

Hier lohnt es sich genauer hinzusehen. Nehmen wir ein Skript mit zwei Problemen: einem Zugriff auf einen nicht gesetzten Array-Schlüssel und dem Aufruf einer Methode, die es nicht gibt.

Mit display_errors=Off, also der typischen Einstellung auf einem Produktivsystem:

Port: (nicht gesetzt)
Zugriff ohne ??:
(exit code: 255)

Und mit display_errors=On und error_reporting=E_ALL:

Port: (nicht gesetzt)
Zugriff ohne ??:
Warning: Undefined array key "port" in /buggy.php on line 8

Fatal error: Uncaught Error: Call to undefined method stdClass::machWas() in /buggy.php:11
Stack trace:
#0 {main}
  thrown in /buggy.php on line 11
(exit code: 255)

Der entscheidende Punkt steht in der letzten Zeile: In beiden Fällen ist der Exit-Code 255. Das Skript scheitert also genau gleich. Die weiße Seite ist kein anderer Zustand als die Fehlermeldung, sie ist derselbe Zustand ohne Rückmeldung. display_errors repariert nichts, es macht nur sichtbar was ohnehin passiert.

error_reporting filtert unabhängig davon

Setzt du display_errors ein, vergisst aber error_reporting, kann es sein, dass du weiterhin nur einen Teil siehst. Mit E_ALL & ~E_WARNING sieht dasselbe Skript so aus:

Port: (nicht gesetzt)
Zugriff ohne ??:

Fatal error: Uncaught Error: Call to undefined method stdClass::machWas() in /buggy.php:11
Stack trace:
#0 {main}
  thrown in /buggy.php on line 11
(exit code: 255)

Die Warnung zum Array-Schlüssel ist verschwunden, der fatale Fehler ist geblieben. Genau deshalb gehören die beiden Einstellungen zusammen.

Auf dem Produktivsystem gehört das ins Log

display_errors=On ist auf einem öffentlich erreichbaren Server eine schlechte Idee. Fehlermeldungen verraten Dateipfade, Klassennamen und manchmal auch Zugangsdaten. Die richtige Einstellung dort lautet:

display_errors = Off
log_errors = On
error_log = /pfad/zu/deinem/error.log

Damit landen dieselben Meldungen in einer Datei, inklusive Zeitstempel:

[28-Aug-2026 19:59:46 UTC] PHP Warning:  Undefined array key "port" in /buggy.php on line 8
[28-Aug-2026 19:59:46 UTC] PHP Fatal error:  Uncaught Error: Call to undefined method stdClass::machWas() in /buggy.php:11
Stack trace:
#0 {main}
  thrown in /buggy.php on line 11

Warum ini_set() manchmal nicht hilft

Ein häufiger Stolperstein: Bei einem Parse-Fehler nützt dir ini_set() nichts. Ein Syntaxfehler wird festgestellt, bevor auch nur eine Zeile deines Skripts ausgeführt wird. Die Zeile, die display_errors einschalten soll, läuft also nie.

Für diesen Fall musst du die Einstellung in der php.ini selbst setzen — oder, in der Entwicklung, beim Aufruf mitgeben:

user@pc:~$ php -d display_errors=1 -d error_reporting=E_ALL skript.php

Welche php.ini gilt überhaupt?

Die zweite große Fehlerquelle. Man bearbeitet eine php.ini und es passiert nichts, weil eine ganz andere geladen wird. Das findest du so heraus:

user@pc:~$ php --ini

Im offiziellen PHP-Docker-Image bekommt man dabei eine Überraschung:

Configuration File (php.ini) Path: "/usr/local/etc/php"
Loaded Configuration File:         (none)
Scan for additional .ini files in: "/usr/local/etc/php/conf.d"

Loaded Configuration File: (none) — das Image lädt gar keine php.ini. Es liegen dort nur die Vorlagen php.ini-development und php.ini-production, von denen man sich eine kopieren muss. Wer im Container eine php.ini bearbeitet und sich wundert, dass sich nichts ändert, hat meistens genau dieses Problem.

Beachte außerdem, dass für PHP-FPM und für die Kommandozeile durchaus unterschiedliche Konfigurationen gelten können. Wenn du also über den Webserver nichts siehst, auf der Kommandozeile aber schon, dann sieh dir die FPM-Konfiguration an.

Zusammenfassung

  • display_errors steuert ob, error_reporting steuert was. Beides setzen.
  • Die weiße Seite ist derselbe Fehler wie die Meldung, nur ohne Ausgabe.
  • Auf dem Produktivsystem: display_errors=Off und log_errors=On.
  • Bei Parse-Fehlern hilft nur die php.ini bzw. -d auf der Kommandozeile.
  • php --ini verrät dir, welche Konfiguration tatsächlich geladen wird.

Hinweis zu Netcup (Werbung)

Der deutsche Hoster Netcup bietet unter anderem günstige und zugleich leistungsstarke Webhosting Pakete, KVM-basierte Root Server und dezidierte Server an. Mit unseren Gutscheincodes kannst du noch mehr Geld sparen (6€ bei deiner ersten Bestellung, 30% Rabatt auf alle KVM-basierten Root Server, ...).

php logging