Geckozone

Bonjour,

Je sus en train de réécrire un site de A jusqu'à Z.
Les utilisateurs du site s'inscrivent et remplissent une fiche qu'ils peuvent modifier à leur gré.
Ils se connectent à l'aide d'un identifiant et d'un mot de passe (rien que de très ordinaire).
Mon problème se situe justement au niveau de la modification des données par l'utilisateur.
Toutes les données saisies lors de l'inscription peuvent être modifiées et complétées : certaines informations sont facultatives, d'autres sont obligatoires. Il y a du texte, des textarea, des cases à cocher, des listes déroulantes, des boutons radio,.. bref, un peu de tout.
Le principe est le suivant : une fois connectée (je vérifie bien sûr que c'est le cas), la personne accède à sa fiche (extraction des données préalablement enregistrées). Elle peut les modifier à son idée à l'aide du formulaire qui ressemble à ça : Lorsque c'est fait, elle peut visualiser le résultat (si des données obligatoires sont manquantes ou erronnées, on revient au formulaire). J'affiche par exemple : La valeur de session est obtenue tout bêtement à partir de la donnée passée en POST : (filtre est une petite fonction toute bête qui nettoie les données et que j'ai utilisée dans d'autres programmes, je l'ai déjà utilisée à plusieurs reprises sans aucun souci).

Je précise que lorsqu'on visualise les données, tout s'affiche absolument normalement (ce qui veut dire que toutes les valeurs de sessions sont bien créées), aucune donnée n'est perdue. Il n'y a évidemment aucun unset, aucun session_destroy().
Mais lorsqu'on revient au formulaire (bouton « modifier »)... Tout fonctionne parfaitement avec Opera, les valeurs de session sont toutes bien présentes. Idem avec IE7. J'étais contente... jusqu'à ce que je teste avec Firefox 2.0.0.11...
Sous Firefox, toutes les informations facultatives sont perdues (c'est-à-dire toutes les données qui peuvent éventuellement être à blanc). En clair, Firefox, et lui seul, perd certaines valeurs de session !
Si quelqu'un peut m'aider à démêler cet imbroglio, je lui en serait très reconnaissante, parce que là, j'avoue ne pas comprendre du tout ce qui se passe !

Message envoyé avec : Opera/9.25 (Windows NT 5.1; U; fr)

As-tu vérifié les valeurs (value ou contenu de textarea) ? Sont-elles présentes ? S'agit-il d'un "oubli" de Firefox ou bien d'une "rémanence" dans Opera/IE ?

Sinon, je ne vois pas trop ce que ces informations font dans une session...

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.11) Gecko/20071204 Firedragon/7.10 Firefox/2.0.0.11

En fait, pour le navigateur la "session" n'existe pas (c'est une abstraction offerte par PHP), tout ce qu'il voit ce sont des valeurs dans des champs de formulaires et éventuellement des cookies.

Il faut donc effectivement commencer par regarder à quoi ressemble code source transmis à Firefox lors du réaffichage du formulaire : les champs sont-il vraiment remplis à partir de tes variables de session en PHP, ou plutôt à partir de l'historique d'Opera ou IE qui se souviennent des dernières valeurs entrées dans un champ portant le même nom ? Tu peux peut-être aussi t'aider d'outils comme Firebug pour observer ce qui passe réellement sur le réseau à chaque requête.

Est-ce que la série de pages en question est accessible quelque part ? C'est souvent plus facile pour avoir une idée générale du comportement du site et ne pas répondre à côté de la plaque

J'ai trouvé la solution à mon problème ! Il n'en reste pas moins que tout ceci est très bizarre.
Parmi les informations du formulaire, il y a 4 champs qui correspondent à des url de photos.
Au moment de l'affichage des données entrées, j'avais :
Dans le cas où il n'y avait pas d'image (ce champ n'est pas obligatoire), j'avais remarqué que Tidy signalait qu'il n'aimait pas ce src vide.
Donc histoire d'avancer un peu en attendant de trouver une solution à mon problème, j'ai modifié mon code comme ceci :
Et là, miracle, je ne perds plus aucune donnée !
Alors certes mon problème est résolu, mais cela n'explique pas pourquoi, lorsqu'il y a un src="" , Firefox part en vrille et perd des valeurs de session qui n'ont rien à faire avec ce champ image !
Pour Calimo, le stockage de contenu de formulaire dans des valeurs de session est une manière archi-classique de conserver des données d'une page à une autre.
En tous cas, je vous remercie tous les deux de votre aide, mais j'aimerais bien savoir pourquoi Firefox a ce comportement bizarre dans un cas comme celui-ci.

Message envoyé avec : Opera/9.25 (Windows NT 5.1; U; fr)

Nounou Ogg a écrit :

Code : Tout sélectionner

<tr><td class="col1facdesc">Titre, adresse<br>1ère image (30%)</td>
<td class="col3desc">';
if ($_SESSION['img1']!='')
{echo stripslashes($_SESSION['timg1']).'<br>'.$_SESSION['img1'].'<br><br><img src="'.$_SESSION['img1'].'" width="30%" alt="photo1">';}
else
{echo '&nbsp;';} echo '</td></tr>

Et là, miracle, je ne perds plus aucune donnée !
Alors certes mon problème est résolu, mais cela n'explique pas pourquoi, lorsqu'il y a un src="" , Firefox part en vrille et perd des valeurs de session qui n'ont rien à faire avec ce champ image !

Comme l'a dit Benoit, Firefox n'a pas accès au php et aux sessions. Il faut donc voir le HTML qui est effectivement généré.
Sans ça, tu ne pourras pas trouver la clé de ton problème.

Nounou Ogg a écrit :Pour Calimo, le stockage de contenu de formulaire dans des valeurs de session est une manière archi-classique de conserver des données d'une page à une autre.

Mais pas dans ce genre de cas... ou alors je n'ai rien compris !
Comme le formulaire est soumis, validé, et réaffiché, tu as toutes les infos dans $_REQUEST, donc tu n'as pas besoin de t'en**** (et d'en**** le visiteur au passage) avec des sessions et des cookies...

Les sessions c'est justement pour conserver les données si le formulaire n'est pas réaffiché (genre un multi-formulaire ou si le visiteur remplit des champs ici et là dans le site).

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.11) Gecko/20071204 Firedragon/7.10 Firefox/2.0.0.11

calimo a écrit :Comme l'a dit Benoit, Firefox n'a pas accès au php et aux sessions. Il faut donc voir le HTML qui est effectivement généré.
Sans ça, tu ne pourras pas trouver la clé de ton problème.

Je n'y ai rien trouvé d'étrange, et Tidy non plus. Les valeurs de sessions correspondant à des données facultatives étaient à blanc (vides), c'est tout.

calimo a écrit :Mais pas dans ce genre de cas... ou alors je n'ai rien compris !
Comme le formulaire est soumis, validé, et réaffiché, tu as toutes les infos dans $_REQUEST, donc tu n'as pas besoin de t'en**** (et d'en**** le visiteur au passage) avec des sessions et des cookies...
Les sessions c'est justement pour conserver les données si le formulaire n'est pas réaffiché (genre un multi-formulaire ou si le visiteur remplit des champs ici et là dans le site).

L'utilisateur entre des données dans le formulaire. Lorsqu'il a finit, il affiche une autre page contenant ces mêmes données. S'il n'est pas satisfait, il revient au formulaire (et ce qu'il a saisi précédemment ne doit en aucun cas être perdu). Ensuite, il réaffiche ses informations. Quand il est satisfait de sa saisie, il accède à une autre page qui enregistre ses données dans la table SQL kivabien. Honnêtement, avec register_globals à off, je ne sais pas faire ce que je fais autrement qu'avec des valeurs de session. Mais je reconnais volontiers que j'ai beaucoup à apprendre en PHP.

Ça me semble une utilisation raisonnable des sessions, je ne sais pas en quoi ça gêne calimo. Mais le fait est que la manière dont tu stockes ces données du côté serveur est totalement indépendante de ton problème. Tu les aurais mises dans un fichier XML ou dans une table temporaire ça serait probablement revenu au même. Si c'était un problème de session tu le verrais aussi avec d'autres navigateurs.

C'est soit dans l'arbre DOM généré par Firefox d'après le code que tu lui envoies (si tu avais un input type image, le fait que le champ src soit vide pourrait être significatif), soit dans les noms ou valeurs de champs de formulaires. Il peut y avoir plein de raisons pour qu'il y en ait une qui ne passe pas, par exemple une différence dans la casse, ou encore une balise mal fermée ou mal imbriquée qui fait que ça sort du formulaire.

Pense aussi à bien vider ton cache dans chacun des navigateurs entre tes tests, si ça se trouve ils font tous la même chose (en bien ou en mal).

Benoit a écrit :Ça me semble une utilisation raisonnable des sessions, je ne sais pas en quoi ça gêne calimo. Mais le fait est que la manière dont tu stockes ces données du côté serveur est totalement indépendante de ton problème. Tu les aurais mises dans un fichier XML ou dans une table temporaire ça serait probablement revenu au même. Si c'était un problème de session tu le verrais aussi avec d'autres navigateurs.

C'est bien ça qui me surprend : normalement, l'exécution du PHP se fait côté serveur, et j'ai du mal à comprendre ce que vient faire là-dedans le choix du navigateur. Or c'était très clair : le problème n'existait qu'avec Firefox, pas avec IE7 ni Opera.

Benoit a écrit :C'est soit dans l'arbre DOM généré par Firefox d'après le code que tu lui envoies (si tu avais un input type image, le fait que le champ src soit vide pourrait être significatif), soit dans les noms ou valeurs de champs de formulaires. Il peut y avoir plein de raisons pour qu'il y en ait une qui ne passe pas, par exemple une différence dans la casse, ou encore une balise mal fermée ou mal imbriquée qui fait que ça sort du formulaire.

Rien de bizarre au niveau des balises, d'ailleurs Tidy ne trouve rien à redire (une extension de Firefox que je trouve extrêmement utile !).
Ce qui est étrange, c'est qu'un src="" provoque la perte de valeurs d'autres valeurs de session (comme je l'ai dit, toutes celles qui sont facultatives, c'est-à-dire que l'utilisateur peut éventuellement les laisser à blanc). Avant que je rajoute la possibilité d'ajouter des images, tout marchait comme sur des roulettes, et, si aucun src n'était laissé à blanc, il n'y avait aucun problème. Mais qu'un src soit laissé à blanc, et là, Firefox connaissait le problème que j'ai décrit.

Benoit a écrit :Pense aussi à bien vider ton cache dans chacun des navigateurs entre tes tests, si ça se trouve ils font tous la même chose (en bien ou en mal).

C'est quelque chose que je fais régulièrement, et/ou je vérifie que mon code source correspond bien à la dernière version que j'ai chargée.
Au passage, il n'y a guère que Firefox qui me cause des soucis de cache. Une petite mésaventure qui m'arrive régulièrement : je teste un programme dans Firefox, je décide de faire une modif. Je sors proprement (retour au menu principal de mon site, déconnexion, même, mais je ne ferme pas Firefox). Je charge sur mon FTP la nouvelle version du programme et je recommence mon test avec Firefox. Je constate que rien n'a changé... je vérifie dans le code source : aucun changement par rapport à la version précédente. Si je vide le cache et que je recommence, évidemment, j'ai la nouvelle version du programme. Mais c'est un souci que je n'ai jamais avec Opera (dont j'utilise pourtant le cache). Pour IE7, je l'utilise trop peu pour avoir un avis...

Pas de solution mais juste une astuce : pour ignorer le cache dans Firefox il suffit de laisser la touche majuscule enfoncée lorsqu'on appuie sur Actualiser.

bonjour, ... tiens on parle de variables de session ici ...
un bon truc que m'avait donné Calimo pour un de mes problèmes

Je replanche d'ailleurs de nouveau un peu la-dessus et je me demande
si çà ne résoudrait pas cet autre problème ...

En fait ce formulaire est réservé aux forums dvd-cinéma ...
et comme il est utile à plusieurs forums et qu'il n'est pas terminé

j'intégre le formulaire dans le forum avec du javascript produit par du php

Est ce que les variables de session sont aussi disponibles à ce moment là ?

Si je me souviens bien ... un variable de scession c'est quand un internaute a son browser ouvert sur un site !? ...

Et comment çà se passe alors avec les browsers disposant d'onglets ?
d'un site à l'autre c'est possible de lire les variables de session de l'autre ??

.... je suis à nouveau dans le flou

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12