Discussion :

[boteha]

Bonjour,

Sur un site marchand de moyenne importance, le panier est une variable de SESSION et cette variable n'est enregistrée dans la base SQL que lorsque le client décide de payer.

Tout ajout au panier modifie le variable en SESSION.

Par ailleurs, à chaque fois qu'il y a besoin de cette variable, celle-ci est testée (isSet) et en cas de perte un message d'excuse est envoyé au client.

De temps en temps (rarement heureusement...) il arrive que tout ajout au panier provoque ce message.
Donc, cette variable n'arrive pas à se créer.

Si le client nous appelle, nous lui demandons de changer de navigateur et le problème disparaît.

Personne ne comprend trop d'où provient le problème...

Le serveur (mutualisé) nous conseille d'enregistrer les variables de SESSION dans mysql avec la biblitohèque adéquate.
Qu'en pensez-vous ?

Plus simplement, est-ce que l'emploi d'une fonction :
session_regenerate_id
en cas de perte de la variable de panier pourrait résoudre la chose ?

Merci d'avance.

[fredd_75]

Je n'ai pas de solutions veritablement pour cela il faudrais que je regarde le code, je peux juste emettre des hypothese et te proposer de verifier les points suivant.

Toutes les pages permettant l'enregitrement dans la variable (donc le panier) de session ont elles bien un "session_start()" en PREMIERE ligne de la page de code? surtout pas de code html avant cette ligne ....

Le fait de changer de navigateur ne resolu pas le probleme ce qui signifie une reconnexion au serveur donc on repart a zéro mais on ne resout pas le probleme de session perdu !!

Lorsqu'il perd les variable du panier l'internaute perd t-il aussi sa connexion? qui doit etre aussi en session....

Voir aussi avec les parametres du systeme linux On appelle ça l'expiration de vie de session, elle dure qu'un nombre de minutes limitées (parfois 5, parfois plus, parfois moins), c'est à dire que la variable session est détruite au bout d'un certain temps d'inactivité ... demande au administrateur de l'hebergeur la valeur de cette dureé de vie...

oui test avec le regenerate si tu veux pour voir tiens nous au courant !!!!
Fred75

[boteha]

Bonjour,

Merci beaucoup de ton intérêt.

Toutes les pages permettant l'enregitrement dans la variable (donc le panier) de session ont elles bien un "session_start()" en PREMIERE ligne de la page de code? surtout pas de code html avant cette ligne ....

Aucun problème de code.
Il y a des commandes tous les jours et ce problème ne revient à nos oreilles qu'une fois tous les trois mois. On peut penser que la panne est plus fréquente, mais quand même rare.

Le fait de changer de navigateur ne resolu pas le probleme ce qui signifie une reconnexion au serveur donc on repart a zéro mais on ne resout pas le probleme de session perdu !!

Changer de navigateur résout toujours le problème (je veux dire quand le client change de navigateur sur le même ordinateur). Il semble probable que le problème provient du navigateur client.

Lorsqu'il perd les variable du panier l'internaute perd t-il aussi sa connexion? qui doit etre aussi en session....

Non.
Tout marche sauf que chaque tentative d'ajout au panier provoque le même message de perte du panier.

Voir aussi avec les parametres du systeme linux On appelle ça l'expiration de vie de session, elle dure qu'un nombre de minutes limitées (parfois 5, parfois plus, parfois moins), c'est à dire que la variable session est détruite au bout d'un certain temps d'inactivité ... demande au administrateur de l'hebergeur la valeur de cette dureé de vie...

Effectivement, on a vu avec l'hébergeur.
Les variables de session étaient flinguées toutes les demi-heures
Maintenant, c'est juste une fois par jour à 4h30 du matin.

oui test avec le regenerate si tu veux pour voir tiens nous au courant !!!!

Le problème est que ce bug est irrationnel et inexpliqué, donc impossible à reproduire....

[fredd_75]

effectivement c'est bizarre, et on ne peut jamais résoudre un problème que l'on ne peut pas générer... lol

Je ne peux pas plus t'aider malheureusement il faudrais que je vienne caremment dans ta boite ^^

Bon courage et tiens moi au courant si tu resout..

[boteha]

Merci de ta réponse.

Avez-vous entendu parler de navigateurs qui ne voudraient pas lire une variable de session ?

Je ne sais même pas si le navigateur est concerné par les variables de session, je suppose que non...

Si perte du panier, je vais ajouter quelques lignes pour détruire toute la session du client en cours et la régénérer comme s'il y avait une nouvelle connexion.

Je vous tiens au courant.

[fredd_75]

non les variable de session ne sont geré que sur le serveur. Le navigateur n'a rien a voir avec la perte de variable en session.

Le mieux serais de pouvoir determiner a partir de quel morceau de code il y a perte, il doit y avoir un morceau de code qui vide la variable ou il passe dans cette boucle que dans certaine condition .... determine le chemin de passage, l'acheminement de mise en panier et tu peux mettre des fopen (invisible coté internaute ) afin de determiner ou passe cette mise en panier.

[boteha]

Bonjour,

Après ré-examen du code, le message d'alerte n'est pas provoqué par l'absence d'une variable de SESSION, mais de $_POST...

L'ajout au panier se fait par un formulaire method="POST" et $_POST est testé en premier.

Pensez-vous que le bug provient du navigateur client ou du serveur ?

Je rappelle que ce bug est permanent jusqu'à ce que le client change de navigateur.

Voyez-vous un moyen d'y remédier ?

Merci d'avance.

[rfufu]

Bonjour,

Un petit retour de la part d'un mec qui bosse également dans le e-commerce, pour un gros site...

1/ Pour la gestion des sessions, tu parles de base de données.
Après expérience, c'est une bonne chose de conserver les sessions à mesure qu'elle sont utilisée, mais je ne conseil pas la base de données utilisé pour le reste de l'appli. e.g. memcache, mcache, sharedanced...
Cela permet de ne pas perdre les sessions en cas de redémarrage d'apache et de ne pas surcharger la base de données.

2/ Les variables de session sont en réalité la mise en relation entre le client et le serveur pour qu'une série de données soient dédié à ce client.
Cette vérification du client se fait d'après plusieurs critères, dont au minimum :
- 1 coockie nommé par défaut PHPSESSID. C'est une bonne idée de changer le nom par défaut (ini_set ( "session.name", "newname" );)
- le user-agent (ici un petit article pour éviter le Session Hijacking : http://phpsec.org/projects/guide/4.html)

3/ La porté des cookies (et notamment celui de session) est importante en cas de changement de sous domaine au cours de la navigation.
Par exemple, si tu veux passer de www.monsite.tld à ssl.monsite.tld sans perdre de session, la porté de tes cookies devra être sur .monsite.tld et non www.monsite.tdl en utilisant par exemple ini_set('session.cookie_domain', '.monsite.tld');

4/ Concernant ta variable $_POST, comment est-elle alimentée et comment est-elle testée ?
Si le bug se fixe lorsque le client change de navigateur, c'est que le problème ne vient pas du serveur, mais du code de l'applicatif qui doit faire mal quelque chose.

[boteha]

Bonjour,

Merci de tes infos.

4/ Concernant ta variable $_POST, comment est-elle alimentée et comment est-elle testée ?

Le test est des plus simples :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if (Empty ($_POST))
{
Appelle une fonction qui envoie un message d'erreur'
}

Comment est-il alimentée, je ne comprends pas ta question, il y a un formulaire...

Si tu veux voir en vrai :

www.touslescables.com


Je répète que je pense que ce problème ne provient pas de notre code PHP, mais qu'il y a peut-être moyen de faire quelque chose pour fixer ces bugs rares mais énervants.

[rfufu]

Alors j'ai regardé un peu le site et j'ai deux remarques à faire.

1/ tes balises de soumission portent le même nom et tu as plusieurs formulaires (et dont certains appellent le même script). Par exemple, si une balise de formulaire n'est pas bien fermée, le formulaire validé peut très bien ne pas être celui souhaité.
Et pour info, dans ce cas, le comportement n'est pas identique sur tous les navigateurs car certain navigateur corrigent eux même une partie de code dans lequel il y a des erreurs.
Je pense qu'indiquer des noms différents peut permettre un filtrage plus fin.

2/ D'autre part, ton test est très global comme tu le dis, et de plus, il faut faire attention à la fonction empty. Pour ce genre de test, je préfère !isset() car si tu as par exemple une quantité 0, tu as une valeur 0, et pourtant empty te renvérra vrai.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
<?php
$toto = 0;
if(empty($toto)){
	echo "empty dit que toto n'existe pas\n";
} else {
	echo "empty dit que toto existe\n";
}
if(!isset($toto)) {
	echo "isset dit que toto n'existe pas\n";
} else {
	echo "isset dit que toto existe, mais est peut-être null ou égal à zéro\n";
}

reverra :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
empty dit que toto n'existe pas
isset dit que toto existe, mais est peut-être null ou égal à zéro

e.g.
A mon sens, un test de ce genre serait préférable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<input type="submit" id="addToCart" name="addToCart" [...] />
if(!isset($_POST['addToCart']) {
	[...] // error handler
}

Question pour faire avancer le chmilblick:
Est-ce qu'il y a un point commun lors de l'apparition du bug ?
Sont-ils observés sur les mêmes fiches produits ou sur le même navigateur ?

J'espère avoir été assez clair dans mes explications... Ça me parait fouillis... :/

[boteha]

Merci de tes remarques.

Est-ce qu'il y a un point commun lors de l'apparition du bug ?
Sont-ils observés sur les mêmes fiches produits ou sur le même navigateur ?

Non, justement, cela n'a rien à voir avec les produits ni avec les navigateurs.
Bug constaté avec Safari, IE, etc... Je suppose les navigateurs coupables d'être un peu pleins de virus mais je n'ai pas de preuve.
Peut-être un bug du serveur, c'est un mutualisé.

Encore une fois ce bug est très rare et apparemment irrationnel.

Je connais la différence subtile entre Empty et isSet.

Le test pourrait être plus précis, tu as raison.
Cela dit, pour les ajouts au panier, Empty me semble plus juste que isSet car ajouter au panier une valeur nulle donnerait un résultat pas terrible...

Pour les form, mes balises sont bien fermées, je ne pense pas que le problème puisse venir de là (mais merci de tes suggestions, je vais y réfléchir).

La question est de savoir s'il est possible de corriger le bug quand il se produit.
Si c'était une variable de Session, il y avait des pistes dont on a discutées, mais, quand un navigateur a perdu $_POST, y a-il quelque chose à faire pour que la transmission de $_POST soit correcte quand le client, après avoir lu le message d'erreur, réessaye son ajout au panier ?