Le site Magento n'affiche plus qu'une ligne : "An error has happened during application run. See exception log for details." Ce message est volontairement vague : en mode production, Magento cache le détail de l'erreur aux visiteurs. La vraie cause est dans les fichiers de log, dans var/log/exception.log. Les causes les plus fréquentes sont les droits des fichiers, un cache ou du code généré devenu incohérent après une mise à jour, et une base de données ou un moteur de recherche qui ne répond plus.
Que signifie ce message et où lire la vraie erreur ?
C'est le message affiché quand une exception arrive hors du mode développeur. Magento l'écrit dans ses logs au lieu de l'afficher. Lisez les dernières lignes :
tail -n 50 var/log/exception.log tail -n 50 var/log/system.log
Si la page ajoute "Could not write error message to log", Magento n'a même pas pu écrire : le dossier var/log n'est pas accessible en écriture, ou la base de données est injoignable. Vous pouvez aussi passer temporairement en mode développeur pour afficher l'erreur dans le navigateur :
php bin/magento deploy:mode:show php bin/magento deploy:mode:set developer
Revenez ensuite en production avec php bin/magento deploy:mode:set production. Ne laissez jamais un site en ligne en mode développeur : il affiche des informations internes.
Comment vider le cache et le code généré ?
Après une mise à jour ou une modification de module, le code généré par Magento peut ne plus correspondre au code réel. Videz le cache, supprimez le code généré et régénérez-le :
php bin/magento cache:flush rm -rf generated/code/* generated/metadata/* var/cache/* var/page_cache/* var/view_preprocessed/* php bin/magento setup:di:compile
Depuis Magento 2.2, le code généré se trouve dans generated/. Les anciens dossiers var/generation et var/di des versions 2.1 ne sont plus utilisés. Lancez ces commandes avec l'utilisateur qui possède les fichiers du site, pas en root : des fichiers recréés par root provoquent ensuite la cause suivante.
Les droits des fichiers sont-ils en cause ?
C'est très fréquent après un déploiement ou une commande lancée avec le mauvais utilisateur. Le serveur web doit pouvoir écrire dans var, generated, pub/static, pub/media et app/etc. Les commandes de la documentation d'Adobe, à lancer depuis la racine du site :
find var generated pub/static pub/media app/etc -type f -exec chmod g+w {} + find var generated pub/static pub/media app/etc -type d -exec chmod g+ws {} +
L'utilisateur du serveur web doit faire partie du groupe propriétaire des fichiers.
Que faire après une mise à jour ou un déploiement ?
Si l'erreur apparaît juste après avoir ajouté un module ou mis à jour Magento, déroulez la procédure complète :
composer install php bin/magento maintenance:enable php bin/magento setup:upgrade php bin/magento setup:di:compile php bin/magento setup:static-content:deploy -f php bin/magento cache:flush php bin/magento maintenance:disable
Un dossier vendor incomplet, une mise à jour de base oubliée ou des fichiers statiques absents suffisent à produire ce message.
La base de données ou le moteur de recherche répondent-ils ?
Le fichier var/log/exception.log montre alors une erreur de connexion, par exemple SQLSTATE[HY000] [2002] pour MySQL. Vérifiez les identifiants dans app/etc/env.php et que le serveur MySQL ou MariaDB tourne. Magento 2.4 exige aussi un moteur de recherche (OpenSearch ou Elasticsearch) : s'il est arrêté, certaines pages tombent en erreur. Pensez enfin à l'espace disque : un disque plein empêche d'écrire le cache et les logs.
Avant de supprimer quoi que ce soit, copiez les dernières lignes de var/log/exception.log : elles disent quelle cause traiter, au lieu d'essayer toutes les commandes au hasard.
- Le message cache l'erreur en mode production : la cause est dans
var/log/exception.log. - Cache, code généré et droits de fichiers expliquent la plupart des cas.
- Depuis Magento 2.2, le code généré est dans
generated/. - Après une mise à jour :
setup:upgrade,setup:di:compile,setup:static-content:deploy.
Une boutique Magento qui plante coûte des ventes : l'hébergement et la maintenance évitent ces coupures, et nous pouvons aussi relier la boutique à votre gestion.
Questions fréquentes
Faut-il passer Magento en mode développeur pour trouver l'erreur ?
Ce n'est pas obligatoire : le fichier var/log/exception.log contient déjà la cause. Le mode développeur sert seulement à l'afficher à l'écran, et doit être retiré ensuite.
Pourquoi l'erreur revient-elle après chaque déploiement ?
Le plus souvent, les commandes de compilation ou de déploiement sont lancées avec un autre utilisateur que celui du serveur web, ce qui crée des fichiers illisibles pour lui.
La commande cache:flush suffit-elle ?
Elle règle les problèmes de cache, mais pas un code généré obsolète, des droits incorrects ou une base inaccessible. Lisez d'abord le log pour savoir laquelle traiter.