Je ne sais pas si PDO améliore en quoi que ce soit la lisibilité ou les performances du site mais, en cas d'erreur de connexion à la base, plutôt que d'afficher un message explicite, il envoie une page grise avec erreur 500
(exemple: fichier config_privee.php manquant)
J'ai mis un moment hier soir à debugger à l'aveugle avant de découvrir le coupable
[solution de contournement] non affichage Erreurs 500
-
Dominique
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
[solution de contournement] non affichage Erreurs 500
Modifié en dernier par Dominique le 05 mars 2013, 13:34, modifié 1 fois.
Dominique http://chemineur.fr
-
sly
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
Sur ce coup, PDO n'y est pour rien.
Le problème rejoins en fait celui là :
http://www.refuges.info/forum/viewtopic.php?t=5154
Ce qui me rappel maintenant pourquoi j'avais forcé l'affichage du debug pour http://dom.refuges.info et aussi pour http://sly.refuges.info en amont dans la config de apache.
Je ne sais pas quoi faire pour améliorer, j'expose les faits :
- WRI va passer à php 5.4.4 et le forum n'est que moyennement compatible, il déclenche des warning, des notices en pagaille, mais ça marche quand même, à condition de ne pas afficher ces erreurs
- Si on active et force l'affichage d'erreurs au niveau du serveur (config global dans le php.ini) on va avoir le site de production qui affiche potentiellement des erreurs -> pas bon
- Si on désactive complètement l'affichage d'erreur au niveau global, le debug devient pénible car plus aucune erreurs ne s'affiche (mais log dans un fichier du serveur)
- Si on active site par site (dom,sly,yip activé) et www (non activé) on ne règle pas le problème du forum qui balance trop d'erreurs
- Si on veut ruser comme j'ai fais ici https://github.com/sletuffe/www.refuges ... php.modele on bidouille au niveau du code pour activer sur demande l'affichage des erreurs partout sauf la zone forum on tombe dans ce problème :
"What you have is a parse error. Those are thrown before any code is executed. A PHP file needs to be parsed in its entirety before any code in it can be executed. If there's a parse error in the file where you're setting your error levels, they won't have taken effect by the time the error is thrown.
Either break your files up into smaller parts, like setting the error levels in one file and then includeing another file which contains the actual code (and errors), or set the error levels outside PHP using php.ini or .htaccess directives."
En clair, les include("existe pas") les parse erreurs, et les erreurs 500 ne sont plus affichées
- Il faudrait alors "activer en amont pour dom,sly,yip" puis désactiver pour le forum mais ça ne marche pas car le "en amont" à précédence sur le "dans le code"
Le problème rejoins en fait celui là :
http://www.refuges.info/forum/viewtopic.php?t=5154
Ce qui me rappel maintenant pourquoi j'avais forcé l'affichage du debug pour http://dom.refuges.info et aussi pour http://sly.refuges.info en amont dans la config de apache.
Je ne sais pas quoi faire pour améliorer, j'expose les faits :
- WRI va passer à php 5.4.4 et le forum n'est que moyennement compatible, il déclenche des warning, des notices en pagaille, mais ça marche quand même, à condition de ne pas afficher ces erreurs
- Si on active et force l'affichage d'erreurs au niveau du serveur (config global dans le php.ini) on va avoir le site de production qui affiche potentiellement des erreurs -> pas bon
- Si on désactive complètement l'affichage d'erreur au niveau global, le debug devient pénible car plus aucune erreurs ne s'affiche (mais log dans un fichier du serveur)
- Si on active site par site (dom,sly,yip activé) et www (non activé) on ne règle pas le problème du forum qui balance trop d'erreurs
- Si on veut ruser comme j'ai fais ici https://github.com/sletuffe/www.refuges ... php.modele on bidouille au niveau du code pour activer sur demande l'affichage des erreurs partout sauf la zone forum on tombe dans ce problème :
"What you have is a parse error. Those are thrown before any code is executed. A PHP file needs to be parsed in its entirety before any code in it can be executed. If there's a parse error in the file where you're setting your error levels, they won't have taken effect by the time the error is thrown.
Either break your files up into smaller parts, like setting the error levels in one file and then includeing another file which contains the actual code (and errors), or set the error levels outside PHP using php.ini or .htaccess directives."
En clair, les include("existe pas") les parse erreurs, et les erreurs 500 ne sont plus affichées
- Il faudrait alors "activer en amont pour dom,sly,yip" puis désactiver pour le forum mais ça ne marche pas car le "en amont" à précédence sur le "dans le code"
-
Dominique
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
-
sly
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
C'est dingue comme simplement exposer les faits, puis se relire, te fais trouver la bonne solution !
J'ai rajouté sur git un fichier "htaccess.modele.txt" On le copie au nom ".htaccess" et on décommente la dernière ligne et hop !
Les erreurs php sont valable "en amont" donc parse error et 500 sont bien affichées, mais le code choisi, pour le forum, ne n'afficher que les erreurs graves donc tout devrait bien le faire.
Attention, l'opération de "cp htaccess.modele.txt .htaccess" est obligatoire pour que votre version du site fonctionne et doit être faite au prochain "git pull"
J'ai rajouté sur git un fichier "htaccess.modele.txt" On le copie au nom ".htaccess" et on décommente la dernière ligne et hop !
Les erreurs php sont valable "en amont" donc parse error et 500 sont bien affichées, mais le code choisi, pour le forum, ne n'afficher que les erreurs graves donc tout devrait bien le faire.
Attention, l'opération de "cp htaccess.modele.txt .htaccess" est obligatoire pour que votre version du site fonctionne et doit être faite au prochain "git pull"