[RÉGLÉ] messages d'erreur plus explicites

[kmchen]

Bonjour,
Depuis les modifications de la gestion des erreurs j'obtiens des messages très peu explicites comme:

Une erreur s'est produite

0 syntax error, unexpected 'false' (T_STRING)

Sans autre information. Est ce possible d'améliorer la précision de ces messages pour obtenir au moins le fichier en cause, voir la ligne reponsable ?

[cavo789]

Bonjour Thierry

Réponse hyper générique que la mienne : les erreurs sont provoquées par tant et plus de sources; cela peut être Joomla lui-même, mais aussi le serveur, une extension (plugin, module, composant), le template, ...

Il faudrait que tu puisses identifier exactement "qui" est à l'origine de l'erreur, dans quel contexte que tu l'as rencontré et remonter l'information à la bonne personne.

Si c'est une erreur dans un composant, remonter l'erreur au développeur du composant.

Si c'est une erreur dans le code source de Joomla, remonter l'erreur aux développeurs core de Joomla. Dans ce cas de figure, tu peux les joindre en créant une issue sur https://github.com/joomla/joomla-cms/issues.

Bonne journée.

[RobertG]

Bonjour,

Mettre le rapport d'erreurs à "Dévelopement" et activer le débogage permet souvent de savoir quel est le fichier, ou au moins l'extension, en cause.
Compte tenu du message, je dirais qu'il s'agit d'un problème de version de PHP (modifiée récemment ?).

[kmchen]

Merci beaucoup pour vos réponses. J'ai résolu le problème entre temps via les logs apache mais ce n'est pas la première fois que je constate la lourdeur et l'inconcistance du nouveau système de gestion d'erreurs de joomla et je voulais juste échanger sur la manière dont vous vous en acomodez. Personnellement je trouve fastidieux d'avoir à chercher dans les justement devenus nombreux logs (apache2, php-fpm, everthing.php, error.php, etc...) pour une simple erreur de syntaxe dont on pourrait simplement afficher la source lorsqu'on la rencontre, il me semble.

J'ai donc reproduit une erreurde syntaxe en enlevant une acolade sur un script de composant en cours de développement. Lorsque j'accède au script j'obtiens le message en question. Mais lorsque je passe le rapport d'erreur en mode "développement" c'est pire: j'obtiens 3 warning deprecated et le message d'erreur de syntaxe disparait !

[pmleconte]

Bonsoir Thierry,

Mettre le rapport d'erreurs à Développement ne suffit pas en général, il faut aussi activer le débogage système( onglet Système) comme évoqué par Robert.

Sinon, effectivement, on va un peu à la pêche.

Pascal

[kmchen]

Un autre cas similaire: j'ai fait un replace massif dans un composant à upgrader pour joomla 3, de JREQUEST / JINPUT de la forme:

JREQUEST::getCmd('var') par $jinput->get('var')

où $jinput a été la plupart du temps défini plus haut dans les scripts par

$jinput = new Jinput();

Mais bien sûr dans certains scripts il n'est pas défini et je pensais trouver rapidement les cas par les messages d'erreur (error_reporting à "development" et plugin log everything activé). Joomla affiche l'erreur suivante:

0 - Call to a member function get() on null

Et voici ce que j'obtiens dans les logs:

everything.php:

2019-11-05T08:32:38+00:00       CRITICAL 127.0.0.1      error   Uncaught \Throwable of type Error thrown. Stack trace: #0 /home/www/lef/libraries/src/Helper/ModuleHelper.php(201): include()
#1 /home/www/lef/libraries/src/Document/Renderer/Html/ModuleRenderer.php(98): Joomla\CMS\Helper\ModuleHelper::renderModule(Object(stdClass), Array)
#2 /home/www/lef/libraries/src/Document/Renderer/Html/ModulesRenderer.php(47): Joomla\CMS\Document\Renderer\Html\ModuleRenderer->render(Object(stdClass), Array, NULL)
#3 /home/www/lef/libraries/src/Document/HtmlDocument.php(491): Joomla\CMS\Document\Renderer\Html\ModulesRenderer->render('user1', Array, NULL)
#4 /home/www/lef/libraries/src/Document/HtmlDocument.php(783): Joomla\CMS\Document\HtmlDocument->getBuffer('modules', 'user1', Array)
#5 /home/www/lef/libraries/src/Document/HtmlDocument.php(557): Joomla\CMS\Document\HtmlDocument->_renderTemplate()
#6 /home/www/lef/libraries/src/Application/CMSApplication.php(1041): Joomla\CMS\Document\HtmlDocument->render(false, Array)
#7 /home/www/lef/libraries/src/Application/SiteApplication.php(780): Joomla\CMS\Application\CMSApplication->render()
#8 /home/www/lef/libraries/src/Application/CMSApplication.php(201): Joomla\CMS\Application\SiteApplication->render()
#9 /home/www/lef/index.php(49): Joomla\CMS\Application\CMSApplication->execute()
#10 {main

Dites moi qu'il y a un moyen de trouver où se niche la ligne en erreur sans suivre les scripts pas à pas depuis la dernière ligne de la pile

[cavo789]

Bonjour Thierry

Deux petites choses :

1. Quand une erreur PHP est rencontrée; sauf exception, c'est l'interpréteur PHP qui affiche l'erreur et qui l'écrit dans le log des erreurs Apache.

Si j'ai un script php qui tente de supprimer un fichier inexistant, c'est PHP lui-même qui va rouspéter. Joomla est donc hors cause.

Exceptionnellement, le développeur PHP peut lui-même "jeter" une erreur avec un throw new Exception mais ce n'est pas le cas ici je pense.

(donc, ne pas croire que "c'est la faute des développeurs de Joomla qui écrivent des messages d'erreurs abscons")

2. Quand tu fais du développement PHP, il est bon d'utiliser un déboggeur. PHP XDEBUG en est un. Tu peux l'intégrer à ton IDE (par exemple Atom ou VSCode) et exécuter ton code (CTRL-F5). Ensuite, tu affiches ta page web et le déboggeur va planter le code et t'afficher le code source lorsqu'il rencontre une exception. Tu pourrais donc, grâce à XDebug, localiser bien plus rapidement les erreurs que de parcourir les fichiers par toi-même.

Bonne prog'

[cavo789]

Complément : notre ami roland_d_alsace est un développeur PHP / Joomla et il a rédigé un tuto sur l'installation de xdebug avec NetBeans; voici son tuto : https://ordi-genie.com/developpement...indows?start=1

Bonne journée.

[roland_d_alsace]

Complément : notre ami roland_d_alsace est un développeur PHP / Joomla et il a rédigé un tuto sur l'installation de xdebug avec NetBeans; voici son tuto : https://ordi-genie.com/developpement...indows?start=1

Bonne journée.

Merci Christophe.

Ce tuto est un peu ancien, et aujourd'hui xdebug est préinstallé avec la plupart des serveurs amp (wamp par exemple).

Je rajouterai qu'en débogage je mets toujours un point d’arrêt dans /plugin/system/redirect/redirect.php à la liste 84 (méthode handleException).

Voir mon article sur le débogage sous Joomla ici : https://ordi-genie.com/joomla/developpement paragraphe : débogage au développement

[kmchen]

Bonjour et merci pour vos réponses.

c'est l'interpréteur PHP qui affiche l'erreur et qui l'écrit dans le log des erreurs Apache

Cavo comme tu peux voir l'exception est rapportée dans everything.php et non apache/error.log et le message "Call to a member function get() on null" qui est la véritable erreur est affichée par joomla dans le navigateur.

J'utilise Xdebug et j'ai depuis débuggé le problème. D'après ce que j'ai pu observer le script Joomla ModuleRenderer.php qui fait un include d'un module tiers qui était à l'origine de l'erreur (utilisation de $jinput->get avec $jinput non défini) récupère (catch) l'exception générée par PHP et en affiche le message d'erreur.

Mais il est bien dommage qu'il omette de spécifier le script et la ligne qui ont généré l'erreur et qui sont mis à disposition par PHP lors du déclenchement d'une exception CF https://www.php.net/manual/en/exception.getline.php. Car si les développeurs Joomla avaient pris la peine de rapporter ces détails Xdebug serait inutile sur des bugs aussi grossiers et j'aurai passé 5s pour chaque bug au lieu de 5mn. Ce n'est pas négligeable quand on est travailleur indépendant et si on réfléchit à l'échelle de la communauté des développeurs Joomla et de ses clients...on pense à l'effet papillon

Je rajouterai qu'en débogage je mets toujours un point d’arrêt dans /plugin/system/redirect/redirect.php à la liste 84 (méthode handleException).

Roland: effectivement c'est la meilleure méthode que j'ai trouvée pour palier à la carence de la gestion d'erreur Joomla.
Je pense que c'est la meilleure réponse qui convient à ce post

[cavo789]

Bonjour

D'après ce que j'ai pu observer le script Joomla ModuleRenderer.php qui fait un include d'un module tiers qui était à l'origine de l'erreur (utilisation de $jinput->get avec $jinput non défini) récupère (catch) l'exception générée par PHP et en affiche le message d'erreur.

Donc, ce n'est ni Joomla (core) qui était à l'origine du problème et l'erreur est bien générée par PHP et non une erreur jetée par Joomla; merci pour cette précision.

Mais il est bien dommage qu'il omette de spécifier le script et la ligne qui ont généré l'erreur et qui sont mis à disposition par PHP lors du déclenchement d'une exception

Mon dernier conseil vu que mes réponses sont très peu utiles : debug_backtrace (https://www.php.net/manual/fr/functi...-backtrace.php). Localise le fichier de Joomla où l'erreur "catchée" est écrite dans un fichier d'erreur et tu n'as qu'à afficher le stack.

Je pense que c'est la meilleure réponse qui convient à ce post

Autrement dit, mes interventions sont peu utiles; dont acte pour les prochaines fois.

[kmchen]

Merci Christophe, tes réponses sont très utiles aussi. Je vais essayer debug_backtrace