Erreur 500 dans Dolibarr : trouver la cause

Vous ouvrez une page de Dolibarr et vous obtenez une page blanche, ou le message « Erreur 500 » de votre navigateur. Rien d’autre : pas de message, pas d’indice. C’est voulu. En production, Dolibarr et PHP cachent le détail des erreurs, pour ne rien révéler à un visiteur malveillant.

Le message existe pourtant, et il dit presque toujours exactement ce qui ne va pas. Il faut seulement savoir où le lire, et nous avons vérifié trois choses qui font perdre beaucoup de temps.

Trois idées reçues, vérifiées

Nous avons provoqué deux vraies erreurs fatales sur un Dolibarr 24 de test, puis regardé où elles apparaissaient.

1. Le navigateur ne reçoit rien. Réponse HTTP 500, zéro octet. Inutile de recharger la page ou de vider le cache.
2. Le journal de Dolibarr ne contient pas l’erreur. Le fichier dolibarr.log n’existe même pas tant que le module Journaux (Logs) n’est pas activé. Et une fois activé, il enregistre les requêtes qui précèdent la panne, mais pas l’erreur fatale elle-même.
3. Passer $dolibarr_main_prod à 0 ne suffit pas à afficher l’erreur. Ce conseil revient partout. Dans le code, ce réglage empêche seulement Dolibarr de masquer les erreurs ; c’est la configuration de PHP (display_errors) qui décide de les afficher. Sur notre test, avec main_prod à 0 seul, la page est restée blanche.

Où lire le vrai message

L’erreur est écrite dans le journal d’erreurs du serveur web. Selon votre installation :

• Debian ou Ubuntu avec Apache : /var/log/apache2/error.log.
• Nginx avec PHP-FPM : le journal d’erreurs de Nginx, ou celui de PHP-FPM.
• Docker, image officielle : docker compose logs web, les erreurs de PHP y apparaissent directement.
• Hébergement mutualisé : la rubrique des journaux ou des erreurs de votre espace client.

Rechargez la page qui plante, notez l’heure, et cherchez PHP Fatal error à cette heure-là.

Si vous n’avez aucun accès aux journaux, vous pouvez afficher l’erreur à l’écran le temps d’un test : mettez $dolibarr_main_prod à 0 dans conf/conf.php et activez display_errors dans la configuration de PHP. Rechargez, copiez le message, puis remettez les deux réglages comme avant : une erreur affichée en production donne des chemins et des détails à n’importe quel visiteur.

Lire le message

Un message d’erreur fatale donne le type d’erreur, le fichier et la ligne. Trois réflexes :

• Le fichier est dans custom/ : c’est un module externe. C’est la cause la plus fréquente, surtout juste après une mise à jour.

• Méfiez-vous du fichier annoncé depuis la version 20. Quand un module appelle une méthode qui n’existe plus, le message pointe vers un fichier du cœur, core/class/doldeprecationhandler.class.php. Le vrai coupable est écrit juste avant, après le mot « From ». Voici ce que nous avons obtenu :

  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

  Ce n’est pas Dolibarr qui est en cause, c’est custom/panne/appel.php, ligne 6.

• Le type d’erreur oriente vers la cause, comme le montre la liste suivante.

Les quatre causes qui reviennent presque toujours

1. Un module externe incompatible avec votre version. Messages typiques : Call to undefined method, Call to undefined function, Declaration of … must be compatible with …. Sur les 280 mises à jour réelles que nous avons testées, toutes les erreurs fatales venaient du code de modules externes. Solution : mettre le module à jour, ou le désactiver.
2. La mémoire. Message : Allowed memory size of … bytes exhausted. Cela arrive surtout à la génération d’un gros PDF, d’un export ou d’une longue liste. Solution : augmenter memory_limit dans la configuration de PHP, ou réduire ce que la page doit charger.
3. Une extension PHP manquante. Message : Call to undefined function sur une fonction qui n’est pas celle d’un module, par exemple une fonction d’image ou d’internationalisation. Cela arrive souvent après un changement de version de PHP chez l’hébergeur. Solution : installer l’extension (intl, gd, zip, curl…).
4. Une version de PHP trop récente pour votre code. Votre hébergeur a monté PHP, et un vieux module utilise des fonctions supprimées en PHP 8. Solution : mettre le module à jour, ou revenir temporairement à la version de PHP précédente si l’hébergeur le permet.

Désactiver un module qui bloque tout

Si le module en cause empêche l’ouverture de l’écran des modules, on peut le désactiver directement en base. La requête est donnée, avec les précautions, dans Mettre à jour Dolibarr sans casse. Vérifiez toujours avec un SELECT ce que la requête va toucher avant de supprimer quoi que ce soit.

À quoi sert quand même le journal de Dolibarr

Activé depuis le module Journaux, dolibarr.log (dans le dossier des documents) n’enregistre pas l’erreur fatale, mais il montre la dernière page ouverte et les dernières requêtes exécutées juste avant. Quand le journal du serveur indique seulement une erreur de mémoire, c’est lui qui dit ce que Dolibarr était en train de charger. Pensez à le désactiver ensuite : il grossit vite.

Si vous ne trouvez pas

Si la page plante sans message exploitable, ou si la cause est dans un module que vous ne pouvez pas mettre à jour, le diagnostic à 90 € consiste justement à regarder votre instance avec vous pendant une heure, puis à vous remettre par écrit la cause et ce que coûterait la correction.

À lire aussi

• « Dolibarr config file content seems to be not correctly defined »
• Le fichier install.lock
• Mettre à jour Dolibarr sans rien casser