Dolibarr Fehler 500 oder weiße Seite: Ursache finden

Ein Fehler 500 in Dolibarr zeigt nichts an, und das Dolibarr-Protokoll enthält ihn nicht. Wo die echte Meldung steht, wie man sie liest und die vier Ursachen, die fast immer dahinterstecken.

Sie öffnen eine Seite in Dolibarr und sehen eine weiße Seite oder die Meldung „Fehler 500” Ihres Browsers. Sonst nichts: keine Meldung, kein Hinweis. Das ist gewollt. Im Produktivbetrieb verbergen Dolibarr und PHP die Fehlerdetails, damit ein böswilliger Besucher nichts erfährt.

Die Meldung gibt es trotzdem, und sie sagt fast immer genau, was nicht stimmt. Man muss nur wissen, wo sie steht, und wir haben drei Dinge geprüft, die viel Zeit kosten.

Drei verbreitete Annahmen, geprüft

Wir haben auf einer Dolibarr-24-Testinstanz zwei echte fatale Fehler ausgelöst und dann nachgesehen, wo sie auftauchen.

Der Browser erhält nichts. HTTP-Antwort 500, null Bytes. Neu laden oder den Cache leeren bringt nichts.
Das Dolibarr-Protokoll enthält den Fehler nicht. Die Datei dolibarr.log existiert gar nicht, solange das Modul Protokolle (Logs) nicht aktiviert ist. Und auch danach verzeichnet sie die Abfragen vor dem Absturz, aber nicht den fatalen Fehler selbst.
$dolibarr_main_prod auf 0 zu setzen, reicht nicht, um den Fehler anzuzeigen. Dieser Tipp ist überall zu finden. Im Code verhindert die Einstellung nur, dass Dolibarr Fehler verbirgt; ob sie angezeigt werden, entscheidet die PHP-Konfiguration (display_errors). In unserem Test blieb die Seite mit main_prod auf 0 allein weiß.

Wo die echte Meldung steht

Der Fehler wird ins Fehlerprotokoll des Webservers geschrieben. Je nach Installation:

Debian oder Ubuntu mit Apache: /var/log/apache2/error.log.
Nginx mit PHP-FPM: das Fehlerprotokoll von Nginx oder das von PHP-FPM.
Docker, offizielles Image: docker compose logs web, PHP-Fehler erscheinen dort direkt.
Shared Hosting: der Bereich Protokolle oder Fehler in Ihrem Kundenmenü.

Laden Sie die fehlerhafte Seite neu, notieren Sie die Uhrzeit und suchen Sie zu dieser Uhrzeit nach PHP Fatal error.

Haben Sie keinerlei Zugriff auf die Protokolle, können Sie den Fehler für einen Test auf dem Bildschirm anzeigen: Setzen Sie $dolibarr_main_prod in conf/conf.php auf 0 und aktivieren Sie display_errors in der PHP-Konfiguration. Neu laden, Meldung kopieren, dann beide Einstellungen zurücksetzen: Ein im Produktivbetrieb angezeigter Fehler verrät jedem Besucher Pfade und Details.

Die Meldung lesen

Eine Meldung über einen fatalen Fehler nennt Fehlerart, Datei und Zeile. Drei Reflexe:

Die Datei liegt in custom/: Es ist ein externes Modul. Das ist die häufigste Ursache, besonders direkt nach einem Update.
Vorsicht bei der genannten Datei seit Version 20. Ruft ein Modul eine Methode auf, die es nicht mehr gibt, zeigt die Meldung auf eine Datei des Kerns, core/class/doldeprecationhandler.class.php. Der wahre Verursacher steht davor, nach dem Wort „From”. Das haben wir erhalten:
```
PHP Fatal error:  Call to undefined method 'methodeQuiNexistePlus'.
From /var/www/html/custom/panne/appel.php:6.
in /var/www/html/core/class/doldeprecationhandler.class.php on line 176
```
Schuld ist hier nicht Dolibarr, sondern custom/panne/appel.php, Zeile 6.
Die Fehlerart weist auf die Ursache hin, wie die folgende Liste zeigt.

Die vier Ursachen, die fast immer dahinterstecken

Ein externes Modul, das nicht zu Ihrer Version passt. Typische Meldungen: Call to undefined method, Call to undefined function, Declaration of … must be compatible with …. Bei den 280 echten Updates, die wir getestet haben, kam jeder fatale Fehler aus dem Code externer Module. Lösung: das Modul aktualisieren oder deaktivieren.
Der Speicher. Meldung: Allowed memory size of … bytes exhausted. Das passiert vor allem beim Erzeugen eines großen PDFs, eines Exports oder einer langen Liste. Lösung: memory_limit in der PHP-Konfiguration erhöhen oder die Menge verringern, die die Seite laden muss.
Eine fehlende PHP-Erweiterung. Meldung: Call to undefined function bei einer Funktion, die zu keinem Modul gehört, etwa einer Bild- oder Internationalisierungsfunktion. Das passiert oft nach einem Wechsel der PHP-Version beim Hoster. Lösung: die Erweiterung installieren (intl, gd, zip, curl…).
Eine zu neue PHP-Version für Ihren Code. Ihr Hoster hat PHP aktualisiert, und ein altes Modul nutzt Funktionen, die in PHP 8 entfernt wurden. Lösung: das Modul aktualisieren oder vorübergehend zur vorherigen PHP-Version zurückkehren, wenn der Hoster das erlaubt.

Ein Modul deaktivieren, das alles blockiert

Verhindert das fehlerhafte Modul, dass sich die Modulverwaltung öffnet, kann man es direkt in der Datenbank deaktivieren. Die Abfrage steht mit den nötigen Vorsichtsmaßnahmen in Dolibarr Update: Checkliste und Versionen 16 bis 24. Prüfen Sie immer zuerst mit einem SELECT, was die Abfrage betrifft, bevor Sie etwas löschen.

Wofür das Dolibarr-Protokoll trotzdem gut ist

Über das Modul Protokolle aktiviert, verzeichnet dolibarr.log (im Dokumentenordner) den fatalen Fehler nicht, zeigt aber die zuletzt geöffnete Seite und die letzten Abfragen direkt davor. Meldet das Serverprotokoll nur einen Speicherfehler, verrät diese Datei, was Dolibarr gerade geladen hat. Deaktivieren Sie es danach wieder: Es wächst schnell.

Wenn Sie nicht weiterkommen

Stürzt die Seite ohne brauchbare Meldung ab oder liegt die Ursache in einem Modul, das Sie nicht aktualisieren können, ist genau das die Diagnose für 90 €: eine Stunde gemeinsam an Ihrer Instanz, danach schriftlich die Ursache und was die Behebung kosten würde.

Dolibarr Fehler 500: die Ursache finden