pour un site, j'utilise les sessions pour mémoriser des données
originairement issues de $_GET et $_POST.
Un truc du style :
foreach ($_POST as $key => $value)
$_SESSION[$key] = $value;
après avoir vérifié les infos et filtrer ce qu'il faut mémoriser.
Or, si cela fonctionnait sous PHP4.4, sous PHP5.2 le contenu de
$_SESSION disparaît alors que la session est bien créee sur le disque et
le cookie bien en place.
J'utilise unset pour virer les variables vides. Par exemple :
unset($_SESSION['km']);
Qu'a-t-il bien pu se passer entre les 2 versions ?
Merci.
PS : mes configs pour php4 et 5 sont identiques.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John GALLET
Bonjour,
Or, si cela fonctionnait sous PHP4.4, sous PHP5.2 le contenu de $_SESSION disparaît alors que la session est bien créee sur le disque et le cookie bien en place.
Rigolo. Même sur un exemple de deux lignes comme par exemple le compteur de "visites" :
http://fr2.php.net/manual/en/ref.session.php exemple 2094
??
Qu'a-t-il bien pu se passer entre les 2 versions ? Changement de comportement par défaut d'un truc idiot.
PS : mes configs pour php4 et 5 sont identiques. Oui mais ça ne veut rien dire, car par exemple session.use_only_cookies
(qui est une connerie) vaut par défaut 1 et a été introduit en 4.3.0 donc il faut bien repointer toutes les valeurs à partir d'un php.ini venant de la distrib de php 5. Et au passage nous donner les versions exactes en 4 et 5.
JG
Bonjour,
Or, si cela fonctionnait sous PHP4.4, sous PHP5.2 le contenu de
$_SESSION disparaît alors que la session est bien créee sur le disque et
le cookie bien en place.
Rigolo. Même sur un exemple de deux lignes comme par exemple le compteur
de "visites" :
http://fr2.php.net/manual/en/ref.session.php
exemple 2094
??
Qu'a-t-il bien pu se passer entre les 2 versions ?
Changement de comportement par défaut d'un truc idiot.
PS : mes configs pour php4 et 5 sont identiques.
Oui mais ça ne veut rien dire, car par exemple session.use_only_cookies
(qui est une connerie) vaut par défaut 1 et a été introduit en 4.3.0 donc
il faut bien repointer toutes les valeurs à partir d'un php.ini venant de
la distrib de php 5. Et au passage nous donner les versions exactes en 4
et 5.
Or, si cela fonctionnait sous PHP4.4, sous PHP5.2 le contenu de $_SESSION disparaît alors que la session est bien créee sur le disque et le cookie bien en place.
Rigolo. Même sur un exemple de deux lignes comme par exemple le compteur de "visites" :
http://fr2.php.net/manual/en/ref.session.php exemple 2094
??
Qu'a-t-il bien pu se passer entre les 2 versions ? Changement de comportement par défaut d'un truc idiot.
PS : mes configs pour php4 et 5 sont identiques. Oui mais ça ne veut rien dire, car par exemple session.use_only_cookies
(qui est une connerie) vaut par défaut 1 et a été introduit en 4.3.0 donc il faut bien repointer toutes les valeurs à partir d'un php.ini venant de la distrib de php 5. Et au passage nous donner les versions exactes en 4 et 5.
JG
Olivier Masson
Rigolo. Même sur un exemple de deux lignes comme par exemple le compteur de "visites" :
http://fr2.php.net/manual/en/ref.session.php exemple 2094
ça fonctionne.
PS : mes configs pour php4 et 5 sont identiques. Oui mais ça ne veut rien dire, car par exemple session.use_only_cookies
(qui est une connerie) vaut par défaut 1 et a été introduit en 4.3.0 donc il faut bien repointer toutes les valeurs à partir d'un php.ini venant de la distrib de php 5. Et au passage nous donner les versions exactes en 4 et 5.
Les sous-versions que j'ai donné (4.4 et 5.2) ne suffisent pas ? Sinon ce sont les dernières dans ces branches (4.4.4 et 5.2.1 je pense.)
J'ai trouvé l'endroit où ça coince, sans avoir trouver la cause et la solution. Lorsque la session est démarrée : session_name('np'); session_start();
dès la page d'accueil est crée le fichier de session sur le serveur avec une entrée (qui est indiquée dès la page d'accueil). Le fichier fait alors 8 octets et contient bien la valeur. Lorsque je fais mon choix dans le formulaire puis valide, les données passent grâce au POST et sont placées dans $_SESSION (les données sont vérifiées) : foreach ($_POST as $key => $value) $_SESSION[$key] = $value;
Un peu plus loin dans la script, après la validation des données, un print_r m'indique bien que les données sont dans $_SESSION.
MAIS, pourtant, le fichier de session ne bouge pas ! Pas un octet de plus ! Evidemment, si je demande l'affichage de la 2e page de résultats, il m'indique que la requête est vide.
Par contre, si je vire le fichier de session crée au départ puis revalide le formulaire, le fichier contient ce qu'il faut (il sera ainsi créer directement avec toutes les valeurs nécessaires). A partir de ce moment, tout fonctionne.
J'imagine que si , dès le départ, je crée les variables de session et les mets à 0 ça pourra fonctionner. Mais ça n'est pas du tout logique (d'autant plus que les session_register sont abandonnées depuis longtemps) et, comme j'utilise unset par ailleurs pour virer les variables non utilisées de la session, le problème se posera probablement plus loin.
Rigolo. Même sur un exemple de deux lignes comme par exemple le compteur
de "visites" :
http://fr2.php.net/manual/en/ref.session.php
exemple 2094
ça fonctionne.
PS : mes configs pour php4 et 5 sont identiques.
Oui mais ça ne veut rien dire, car par exemple session.use_only_cookies
(qui est une connerie) vaut par défaut 1 et a été introduit en 4.3.0 donc
il faut bien repointer toutes les valeurs à partir d'un php.ini venant de
la distrib de php 5. Et au passage nous donner les versions exactes en 4
et 5.
Les sous-versions que j'ai donné (4.4 et 5.2) ne suffisent pas ? Sinon
ce sont les dernières dans ces branches (4.4.4 et 5.2.1 je pense.)
J'ai trouvé l'endroit où ça coince, sans avoir trouver la cause et la
solution. Lorsque la session est démarrée :
session_name('np');
session_start();
dès la page d'accueil est crée le fichier de session sur le serveur avec
une entrée (qui est indiquée dès la page d'accueil). Le fichier fait
alors 8 octets et contient bien la valeur.
Lorsque je fais mon choix dans le formulaire puis valide, les données
passent grâce au POST et sont placées dans $_SESSION (les données sont
vérifiées) :
foreach ($_POST as $key => $value)
$_SESSION[$key] = $value;
Un peu plus loin dans la script, après la validation des données, un
print_r m'indique bien que les données sont dans $_SESSION.
MAIS, pourtant, le fichier de session ne bouge pas ! Pas un octet de
plus ! Evidemment, si je demande l'affichage de la 2e page de résultats,
il m'indique que la requête est vide.
Par contre, si je vire le fichier de session crée au départ puis
revalide le formulaire, le fichier contient ce qu'il faut (il sera ainsi
créer directement avec toutes les valeurs nécessaires). A partir de ce
moment, tout fonctionne.
J'imagine que si , dès le départ, je crée les variables de session et
les mets à 0 ça pourra fonctionner. Mais ça n'est pas du tout logique
(d'autant plus que les session_register sont abandonnées depuis
longtemps) et, comme j'utilise unset par ailleurs pour virer les
variables non utilisées de la session, le problème se posera
probablement plus loin.
Rigolo. Même sur un exemple de deux lignes comme par exemple le compteur de "visites" :
http://fr2.php.net/manual/en/ref.session.php exemple 2094
ça fonctionne.
PS : mes configs pour php4 et 5 sont identiques. Oui mais ça ne veut rien dire, car par exemple session.use_only_cookies
(qui est une connerie) vaut par défaut 1 et a été introduit en 4.3.0 donc il faut bien repointer toutes les valeurs à partir d'un php.ini venant de la distrib de php 5. Et au passage nous donner les versions exactes en 4 et 5.
Les sous-versions que j'ai donné (4.4 et 5.2) ne suffisent pas ? Sinon ce sont les dernières dans ces branches (4.4.4 et 5.2.1 je pense.)
J'ai trouvé l'endroit où ça coince, sans avoir trouver la cause et la solution. Lorsque la session est démarrée : session_name('np'); session_start();
dès la page d'accueil est crée le fichier de session sur le serveur avec une entrée (qui est indiquée dès la page d'accueil). Le fichier fait alors 8 octets et contient bien la valeur. Lorsque je fais mon choix dans le formulaire puis valide, les données passent grâce au POST et sont placées dans $_SESSION (les données sont vérifiées) : foreach ($_POST as $key => $value) $_SESSION[$key] = $value;
Un peu plus loin dans la script, après la validation des données, un print_r m'indique bien que les données sont dans $_SESSION.
MAIS, pourtant, le fichier de session ne bouge pas ! Pas un octet de plus ! Evidemment, si je demande l'affichage de la 2e page de résultats, il m'indique que la requête est vide.
Par contre, si je vire le fichier de session crée au départ puis revalide le formulaire, le fichier contient ce qu'il faut (il sera ainsi créer directement avec toutes les valeurs nécessaires). A partir de ce moment, tout fonctionne.
J'imagine que si , dès le départ, je crée les variables de session et les mets à 0 ça pourra fonctionner. Mais ça n'est pas du tout logique (d'autant plus que les session_register sont abandonnées depuis longtemps) et, comme j'utilise unset par ailleurs pour virer les variables non utilisées de la session, le problème se posera probablement plus loin.
John GALLET
ça fonctionne. Donc c'est un problème de codage et non pas de configuration machine, ni
d'upgrade à PHP 5 en soit.
Les sous-versions que j'ai donné (4.4 et 5.2) ne suffisent pas ? Si, si, ce qu'il manquait c'était des lunettes (aïe non pas la tête).
Un peu plus loin dans la script, après la validation des données, un print_r m'indique bien que les données sont dans $_SESSION.
Est-ce que c'est bien le même identifiant de session ? N'y-a-t-il pas création d'un autre fichier ?
solution. Lorsque la session est démarrée : session_name('np'); session_start();
Commence par virer le session name pour être sûr que c'est pas ça qui fout la grouille et ensuite si tu as un exemple simple et publiable publiquement permettant de reproduire, indique le ici, qu'on puisse lire exactement le code exécuté et si nécessaire le tester nous mêmes.
++a; JG
ça fonctionne.
Donc c'est un problème de codage et non pas de configuration machine, ni
d'upgrade à PHP 5 en soit.
Les sous-versions que j'ai donné (4.4 et 5.2) ne suffisent pas ?
Si, si, ce qu'il manquait c'était des lunettes (aïe non pas la tête).
Un peu plus loin dans la script, après la validation des données, un
print_r m'indique bien que les données sont dans $_SESSION.
Est-ce que c'est bien le même identifiant de session ? N'y-a-t-il pas
création d'un autre fichier ?
solution. Lorsque la session est démarrée :
session_name('np');
session_start();
Commence par virer le session name pour être sûr que c'est pas ça qui fout
la grouille et ensuite si tu as un exemple simple et publiable
publiquement permettant de reproduire, indique le ici, qu'on puisse lire
exactement le code exécuté et si nécessaire le tester nous mêmes.
ça fonctionne. Donc c'est un problème de codage et non pas de configuration machine, ni
d'upgrade à PHP 5 en soit.
Les sous-versions que j'ai donné (4.4 et 5.2) ne suffisent pas ? Si, si, ce qu'il manquait c'était des lunettes (aïe non pas la tête).
Un peu plus loin dans la script, après la validation des données, un print_r m'indique bien que les données sont dans $_SESSION.
Est-ce que c'est bien le même identifiant de session ? N'y-a-t-il pas création d'un autre fichier ?
solution. Lorsque la session est démarrée : session_name('np'); session_start();
Commence par virer le session name pour être sûr que c'est pas ça qui fout la grouille et ensuite si tu as un exemple simple et publiable publiquement permettant de reproduire, indique le ici, qu'on puisse lire exactement le code exécuté et si nécessaire le tester nous mêmes.
++a; JG
Olivier Masson
Est-ce que c'est bien le même identifiant de session ? N'y-a-t-il pas création d'un autre fichier ?
Oui. Non.
Commence par virer le session name pour être sûr que c'est pas ça qui fout la grouille et ensuite si tu as un exemple simple et publiable publiquement permettant de reproduire, indique le ici, qu'on puisse lire exactement le code exécuté et si nécessaire le tester nous mêmes.
C'est pas le session_name. Pour le code, pas évident. Mais j'ai trouvé l'origine : typage des variables de sessions. En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant ctype (chouette, quelle bonne idée de changer et de le dire dans une longue liste de changelog :>) :
"Appelées avec un argument de type chaîne, elles vérifieront chaque caractère de la chaîne, et ne retourneront TRUE que si chacun satisfait les critères requis. Appelées avec une chaîne de caractères vide, le résultat sera toujours TRUE dans PHP < 5.1 et FALSE depuis 5.1."
La nouvelle valeur me semble plus logique mais peut-être que j'utilisais le comportement précédent...
Est-ce que c'est bien le même identifiant de session ? N'y-a-t-il pas
création d'un autre fichier ?
Oui. Non.
Commence par virer le session name pour être sûr que c'est pas ça qui fout
la grouille et ensuite si tu as un exemple simple et publiable
publiquement permettant de reproduire, indique le ici, qu'on puisse lire
exactement le code exécuté et si nécessaire le tester nous mêmes.
C'est pas le session_name. Pour le code, pas évident.
Mais j'ai trouvé l'origine : typage des variables de sessions.
En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant
ctype (chouette, quelle bonne idée de changer et de le dire dans une
longue liste de changelog :>) :
"Appelées avec un argument de type chaîne, elles vérifieront chaque
caractère de la chaîne, et ne retourneront TRUE que si chacun satisfait
les critères requis. Appelées avec une chaîne de caractères vide, le
résultat sera toujours TRUE dans PHP < 5.1 et FALSE depuis 5.1."
La nouvelle valeur me semble plus logique mais peut-être que j'utilisais
le comportement précédent...
Est-ce que c'est bien le même identifiant de session ? N'y-a-t-il pas création d'un autre fichier ?
Oui. Non.
Commence par virer le session name pour être sûr que c'est pas ça qui fout la grouille et ensuite si tu as un exemple simple et publiable publiquement permettant de reproduire, indique le ici, qu'on puisse lire exactement le code exécuté et si nécessaire le tester nous mêmes.
C'est pas le session_name. Pour le code, pas évident. Mais j'ai trouvé l'origine : typage des variables de sessions. En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant ctype (chouette, quelle bonne idée de changer et de le dire dans une longue liste de changelog :>) :
"Appelées avec un argument de type chaîne, elles vérifieront chaque caractère de la chaîne, et ne retourneront TRUE que si chacun satisfait les critères requis. Appelées avec une chaîne de caractères vide, le résultat sera toujours TRUE dans PHP < 5.1 et FALSE depuis 5.1."
La nouvelle valeur me semble plus logique mais peut-être que j'utilisais le comportement précédent...
John GALLET
Bonjour,
Mais j'ai trouvé l'origine : typage des variables de sessions. En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant ctype
J'aurais cherché un moment, jamais utilisé cette extension.
La nouvelle valeur me semble plus logique mais peut-être que j'utilisais le comportement précédent...
Conseil : prends le temps de comprendre complètement pourquoi ça tombe en marche.
a++; JG
Bonjour,
Mais j'ai trouvé l'origine : typage des variables de sessions.
En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant
ctype
J'aurais cherché un moment, jamais utilisé cette extension.
La nouvelle valeur me semble plus logique mais peut-être que j'utilisais
le comportement précédent...
Conseil : prends le temps de comprendre complètement pourquoi ça tombe en
marche.
Mais j'ai trouvé l'origine : typage des variables de sessions. En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant ctype
J'aurais cherché un moment, jamais utilisé cette extension.
La nouvelle valeur me semble plus logique mais peut-être que j'utilisais le comportement précédent...
Conseil : prends le temps de comprendre complètement pourquoi ça tombe en marche.
a++; JG
Bruno Baguette
Bonjour,
Mais j'ai trouvé l'origine : typage des variables de sessions. En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant ctype
J'aurais cherché un moment, jamais utilisé cette extension.
Tu devrais y jeter un oeil :-)
ctype est rudement pratique pour valider des données provenant de $_REQUEST avant de poursuivre le traitement. ctype_digit, par exemple, est plus efficace que is_numeric quand on veut vérifier un entier numérique.
Mais te connaissant, je pense que tu as déjà toute une chiée de fonctions de contrôle, et des sévères :-)
-- Bruno Baguette -
Bonjour,
Mais j'ai trouvé l'origine : typage des variables de sessions.
En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant
ctype
J'aurais cherché un moment, jamais utilisé cette extension.
Tu devrais y jeter un oeil :-)
ctype est rudement pratique pour valider des données provenant de
$_REQUEST avant de poursuivre le traitement. ctype_digit, par exemple,
est plus efficace que is_numeric quand on veut vérifier un entier numérique.
Mais te connaissant, je pense que tu as déjà toute une chiée de
fonctions de contrôle, et des sévères :-)
Mais j'ai trouvé l'origine : typage des variables de sessions. En fait, en plus de mon code, cette nouveauté dans PHP 5.2 concernant ctype
J'aurais cherché un moment, jamais utilisé cette extension.
Tu devrais y jeter un oeil :-)
ctype est rudement pratique pour valider des données provenant de $_REQUEST avant de poursuivre le traitement. ctype_digit, par exemple, est plus efficace que is_numeric quand on veut vérifier un entier numérique.
Mais te connaissant, je pense que tu as déjà toute une chiée de fonctions de contrôle, et des sévères :-)
-- Bruno Baguette -
Olivier Masson
J'aurais cherché un moment, jamais utilisé cette extension.
Ah ? Pourtant les ctype_ sont bien. Je n'ai jamais fait de bench pour voir sa vitesse de traitement, mais c'est le genre de manip que j'ai arrêté de faire (parce que gagner 0.1 seconde sur 10000 opérations, ça n'a pas vraiment d'intêret en PHP, du moins pour moi.)
Conseil : prends le temps de comprendre complètement pourquoi ça tombe en marche.
Certes. J'ai pour habitude, même si mon niveau en progra est bien faible, de faire au mieux, de bien vérifier, etc. Et un défaut que j'ai choppé à cause de PHP est de ne pas suffisamment faire attention au type de variable ("à cause" car rien n'oblige à déclarer le type en PHP). Me suis déjà fait avoir avec strtr sur une égalité == car ce béta renvoie 0 si la chaîne recherchée est en première place.
J'aurais cherché un moment, jamais utilisé cette extension.
Ah ? Pourtant les ctype_ sont bien. Je n'ai jamais fait de bench pour
voir sa vitesse de traitement, mais c'est le genre de manip que j'ai
arrêté de faire (parce que gagner 0.1 seconde sur 10000 opérations, ça
n'a pas vraiment d'intêret en PHP, du moins pour moi.)
Conseil : prends le temps de comprendre complètement pourquoi ça tombe en
marche.
Certes. J'ai pour habitude, même si mon niveau en progra est bien
faible, de faire au mieux, de bien vérifier, etc.
Et un défaut que j'ai choppé à cause de PHP est de ne pas suffisamment
faire attention au type de variable ("à cause" car rien n'oblige à
déclarer le type en PHP).
Me suis déjà fait avoir avec strtr sur une égalité == car ce béta
renvoie 0 si la chaîne recherchée est en première place.
J'aurais cherché un moment, jamais utilisé cette extension.
Ah ? Pourtant les ctype_ sont bien. Je n'ai jamais fait de bench pour voir sa vitesse de traitement, mais c'est le genre de manip que j'ai arrêté de faire (parce que gagner 0.1 seconde sur 10000 opérations, ça n'a pas vraiment d'intêret en PHP, du moins pour moi.)
Conseil : prends le temps de comprendre complètement pourquoi ça tombe en marche.
Certes. J'ai pour habitude, même si mon niveau en progra est bien faible, de faire au mieux, de bien vérifier, etc. Et un défaut que j'ai choppé à cause de PHP est de ne pas suffisamment faire attention au type de variable ("à cause" car rien n'oblige à déclarer le type en PHP). Me suis déjà fait avoir avec strtr sur une égalité == car ce béta renvoie 0 si la chaîne recherchée est en première place.
John GALLET
ctype est rudement pratique pour valider des données provenant de $_REQUEST avant de poursuivre le traitement. ctype_digit, par exemple, est plus efficace que is_numeric quand on veut vérifier un entier numérique.
C'est à dire "efficace" ? En termes de perfs ou en termes de faux positifs ?
Mais te connaissant, je pense que tu as déjà toute une chiée de fonctions de contrôle, et des sévères :-)
Depuis décembre 1999... PHP 3.04 de mémoire, donc pas grand chose comme fonctions toutes prêtes pour ce faire. Mais justement, les choses évoluent parfois (rarement mais on sait jamais...) dans le bon sens et des trucs que je fais "à la main" ont peut-être depuis été codés intelligement donc ça n'empêche pas de vérifier de temps en temps.
JG
ctype est rudement pratique pour valider des données provenant de
$_REQUEST avant de poursuivre le traitement. ctype_digit, par exemple,
est plus efficace que is_numeric quand on veut vérifier un entier numérique.
C'est à dire "efficace" ? En termes de perfs ou en termes de faux positifs
?
Mais te connaissant, je pense que tu as déjà toute une chiée de
fonctions de contrôle, et des sévères :-)
Depuis décembre 1999... PHP 3.04 de mémoire, donc pas grand chose comme
fonctions toutes prêtes pour ce faire. Mais justement, les choses évoluent
parfois (rarement mais on sait jamais...) dans le bon sens et des trucs
que je fais "à la main" ont peut-être depuis été codés intelligement donc
ça n'empêche pas de vérifier de temps en temps.
ctype est rudement pratique pour valider des données provenant de $_REQUEST avant de poursuivre le traitement. ctype_digit, par exemple, est plus efficace que is_numeric quand on veut vérifier un entier numérique.
C'est à dire "efficace" ? En termes de perfs ou en termes de faux positifs ?
Mais te connaissant, je pense que tu as déjà toute une chiée de fonctions de contrôle, et des sévères :-)
Depuis décembre 1999... PHP 3.04 de mémoire, donc pas grand chose comme fonctions toutes prêtes pour ce faire. Mais justement, les choses évoluent parfois (rarement mais on sait jamais...) dans le bon sens et des trucs que je fais "à la main" ont peut-être depuis été codés intelligement donc ça n'empêche pas de vérifier de temps en temps.
