Page 1 sur 1

Différence local / serveur distant

Posté : 27 déc. 2006, 14:30
par Flashball
Salut,

Je continue avec mes déboires pour ma mise en ligne de mon site de covoiturage en Ariège.

J'ai plein d'erreurs que je n'avais pas en local, et sur beaucoup d'écrans (recherche multi-critères, connection, inscription, etc.).

Quelqu'un peut-il m'expliquer d'où proviennent ces différences et comment les régler? Si je dois redévelopper l'appli (ou du moins la redébugguer différemment) après chaque mise en ligne, çà risque d'être compliqué... :?

Merci,

Flashball

Posté : 27 déc. 2006, 15:38
par Ajoloca
Bonjour,

Il faut se mettre en tête que quand on développe il-y-a des règles à respecter.
C'est pas parce que certaines configurations sont plus permissives que d'autres qu'il faut utiliser la méthode la plus permissive.

Quand à tes erreurs, tu peux donner des exemples ou tu veux que l'on serve de béta-testeurs ?

Posté : 27 déc. 2006, 15:53
par Flashball
ok, désolé

Je crois que je vais récupérer la "config moins permissive" de mon hébergeur, sinon çà risque d'être compliqué.

Ensuite, par exemple, vous pouvez essayer la recherche multicritères par défaut (http://enroute09.org/searchroutes.php5). L'erreur me raconte que "tabDays" n'est pas défini: effectivement, cette variable sert uniquement lorsque l'on coche "trajet régulier". En local, celà ne pose pas de soucis. Cette configuration m'oblige donc à poster même les variables qui ne me servent pas sous peine d'erreur?

L'autre truc, c'est que dès qu'une erreur survient, j'ai droit au "Cannot modify header information", ce qui est gênant: j'avais prévu une page d'erreur spécifique lorsqu'une exception se déclenche. Il n'y a donc pas d'exceptions mais l'appli s'arrête sur une page pas cool du tout!

Posté : 27 déc. 2006, 16:09
par Ajoloca
Re,
Tu dois procéder par étapes.
Résoudre une erreur après l'autre.
Je suppose que ton PB de variable non définie vient du fait que ta config (locale) tu as activé les directives du style "register_globals", "register_long_arrays" qui ne sont pas activées chez ton hébergeur.

Dans la prochaine version de PHP (la 6) elles ne seront plus activées et plus de possibilité de le faire.

Posté : 27 déc. 2006, 18:53
par Flashball
Les variables citées sont désactivées dans ma configuration locale...

Je vais lancer un phpinfo() des deux côtés pour en apprendre plus.

Posté : 27 déc. 2006, 18:56
par Ajoloca
Les deux serveurs sont les mêmes (APACHE, IIS, etc) ?

Posté : 27 déc. 2006, 19:04
par Flashball
Chez mon hébergeur (hebergeur-discount, j'ai pris le 1er que j'ai trouvé pour parler franchement!), il s'agit d'une plate-forme Win NT / IIS (je viens de m'en apercevoir).

Plus de détail sur leur config php sur http://enroute09.org/phpinfo.php5. En local, j'ai installé PHP 5.1.4 / Apache 2.0.58 avec la config par défaut, je n'ai rien modifié.

Posté : 27 déc. 2006, 20:05
par Flashball
La plupart des erreurs étaient dûes au fait de ne pas tester avec isset() certaines variables. J'avais aussi qq erreurs dûes à l'instruction "print_r($var, true)" sur laquelle j'avais omis le 2ème paramètre à "true". Un des aspects les plus gênants étaient d'avoir d'horribles erreurs PHP qui apparaissent à l'écran, alors que j'ai mis en place tout un système à base d'exceptions et de redirection vers une page d'erreur plus sobre. Hélas, ce genre d'erreur n'est pas interceptée, et c'est bien dommage.

Voilà, je peux partir en vacances maintenant, merci pour votre aide.

Posté : 27 déc. 2006, 20:13
par Ajoloca
Re,
Si ce que tu veux c'est de supprimer les messages d'erreur PHP tu peux le faire en utilisant une directive PHP.

Comme tu n'as pas accès au fichier de configuration tu devras passer par un fichier .htaccess.

Si tu emploie cette technique n'oublie pas d'activer (si c'est pas fait) le fichier de log des erreurs dans le même .htaccess.

Mais le temps de faire les premiers tests je te le déconseille.

Sinon, montre comment est ta gestion d'erreurs.
Peut être que c'est encore jouable, de pouvoir la conserver.

Posté : 27 déc. 2006, 20:41
par Flashball
Ok, je vais me renseigner un peu plus sur ce fichier ".htaccess" - après les vacances...

Ma gestion d'erreur en résumé: toutes les exceptions remontent jusqu'à la classe la plus haute (FrontController - modèle MVC) qui les "catch" toutes. Je m'envoie un mail d'alerte dans ce cas: le but c'est bien sûr d'être tout de suite prévenu en cas de gros souci sur un site.

Parallèlement, je me suis mis en place des classes de tracage (dans des fichiers logs) avec deux niveaux: un tracage de développement (toutes les E/S des méthodes et tous les passages clefs) et un tracage de production (les exceptions uniquement).

Je trouve juste dommage que PHP ne renvoit pas toutes les erreurs sous forme d'exceptions, mais ca viendra peut-être dans une future version. Mais en attendant, ca m'empêchera de dormir complètement sereinement, car je ne suis pas sûr d'être au courant au cas où une erreur se produit - à moins de compter sur un mail d'insulte!