Reprise du message précédent :

C'est même pas du php ça.
Le php, c'est

ou

 
Si ... du php qui marchera pas bien, certes, mais du php quand même

Ouais je l'ai changé après, mais curieusement ça marchait.
 
------- SINON ------
 
Est-ce qu'on peut modifier la session d'un utilisateur à partir d'un autre ?

 
je sais . mais deja qu'il 'a fallut 14 mois pour reussir a faire passer a php5 , jepense que php6 ce sera pour mes petits enfants

normalement,non ( hors bug )

En fait j'ai ma banque qui se connecte pour me donner une confirmation de paiement sur la commande de l'user X.
Donc je voudrais à ce moment vider le panier de session de cet user X. Hors je ne suis pas connecté en tant qu'user X.
 
Pas possible ça ?

 
Tant que X ne visite pas il n'y a aucune utilité à vider son panier, donc pas besoin de le faire immédiatement.
 
Tu laisse en base une info qui dit qu'il faut vider le panier de l'utilisateur X à sa prochaine visite.
A chaque visite de X, tu check cette même info, si elle dit qu'il faut vider le panier, tu le fait avant toute chose.

X est justement en ligne, puisqu'il vient de faire une commande

Aucune importance, tu ajoutes un flag pour cette task en DB, et au prochain hit qu'il fait sur une page ben tu lui dégages sont panier et tu fais ce que tu as à faire.

Ouais bin c'est le plan B, mais le plan A était plus cool je trouve

Le plan A il est complètement con
 
(puis si t'es pas content, ben tu stockes tes paniers en DB comme ça tes users peuvent les garder d'une session à l'autre, comme chez amazon )

Ben désolé ce code fait pas ce que t'as demandé au début
Le Pragme et le Content-Type sont des headers HTTP.
Si tu fais un echo ça n'affecte pas les headers HTTP mais le body de la réponse HTTP.
Donc ton bout de code là il fait n'importe quoi puisqu'il balance dans le body HTTP des choses qui sont censées être dans le header
 

Je sais bien, mais bon le register_globals c'est vraiment mal donc si jamais t'as du temps devant toi essaie de faire sauter ça
 

Salut les gens :
 
Quelqu'un sait comment hacker ce souci :
 
Quand on fait du fade in/out, sous FF il y a la police, qui change d'état bold/normal, légérement.
 
J'aimerais y pallier.
 
j'avais trouvé ça :
 

 
Mais après sous Safari 1.3 jai un bug d'affichage de malade.
Donc y a d'il dautre soluce ?

j'ai un script qui fait du fade in / fade out.
 
voici un morceau de code si ça peu t'aider:
 

function setOpacity(opacity, theID) {
 
    var object = document.getElementById(theID).style;
 
    // If it's 100, set it to 99 for Firefox.
 
    if (navigator.userAgent.indexOf("Firefox" ) != -1) {
        if (opacity == 100) { opacity = 99.9999; } // This is majorly retarded
    }
 
    // Multi-browser opacity setting
 
    object.filter = "alpha(opacity=" + opacity + " )"; // IE/Win
    //object.KhtmlOpacity = (opacity / 100);            // Safari 1.1 or lower, Konqueror
    //object.MozOpacity = (opacity / 100);              // Older Mozilla+Firefox
    object.opacity = (opacity / 100);                 // Safari 1.2, Firefox+Mozilla
 
}

function setOpacity(opacity, theID) {
 
    var object = document.getElementById(theID).style;
 
    // If it's 100, set it to 99 for Firefox.
 
    if (navigator.userAgent.indexOf("Firefox" ) != -1) {
        if (opacity == 100) { opacity = 99.9999; } // This is majorly retarded
    }
 
    // Multi-browser opacity setting
 
    object.filter = "alpha(opacity=" + opacity + " )"; // IE/Win
    //object.KhtmlOpacity = (opacity / 100);            // Safari 1.1 or lower, Konqueror
    //object.MozOpacity = (opacity / 100);              // Older Mozilla+Firefox
    object.opacity = (opacity / 100);                 // Safari 1.2, Firefox+Mozilla
 
}

 
Et ce script n'a pas de soucis avec le contenu écrit ??
 
Vais tester....

if (navigator.userAgent.indexOf("Firefox" ) != -1)

C'est quoi ce caca?

 
J'aime pas trop non plus, je peux faire quoi comme test, pour être sur c'est FF ?

Pour Gecko :

 
Pour ie 6/7 :

(a coupler avec window.XMLHttpRequest)
 
Pour opera, ça existe déja (window.opera)
 
Y'a que webkit que j'ai jamais testé, mais y'a surement un objet propre/methodes

Oki thx

Lol bis :  
 
http://www.developpez.net/forums/s [...] p?t=421380

C'est déja le cas
Seulement comme c'est encore plus mieux chez nous, on a aussi un panier de session pour les non-loggés

J'ai rien demandé de précis au début j'ai juste quoté la doc de ma banque, qui ne parlait même pas de headers ni de HTTP, et pis bon mon code c'est ptet n'importe quoi mais c'est ce que veut recevoir la banque (je l'ai chopé dans leurs kits tout faits) Alors va plutot insulter le credit mutuel pour pas les citer

Das ist scheisse ! Entre les headers et le contenu (document falisifie), il faut *2* retour chariots, pas un seul

cf ma réponse    

Tu noteras que pour son 1ere point sur l'image, ta réponse c'est de la bouze

Et javascript inventa l'objet image ( c'est pas un objet primitif rassure toi) et son attribut "complete".

Mais c'est *pas* des headers ²

Pour les paniers, pourquoi vous les videz pas juste avant d'envoyer le client sur le serveur de paiement (de la banque) ? S'il en est à payer, c'est qu'il a validé ces achats et donc qu'il a finis de choisir les produits. Le panier n'a donc plus de raison d'être.

- Il peut faire "annuler"
- Son PC peut planter pendant le paiement, ou autre (timeout dépassé etc)
- Je ne vide le panier qu'une fois que c'est payé, comme chez leclerc quoi, ça parrait logique.

Pragma et Content-Type à ton avis c'est quoi ?  

du texte ...

Mais je m'en fout moi, la banque elle en fait ce qu'elle veut après, elle s'en sert sûrement de headers ou quoi que ce soit, si ça se trouve elle génère un autre fichier à partir de ma réponse, je m'en fout moi, du moment qu'elle me FILE mon puTAIN de FRIC

C'est une façon de voir.
Donc en fait, si ton bonhomme ne paye jamais non seulement tu te retrouves avec une commande non validé (puisque pas payé) mais en plus tu te retrouves avec un panier qui peut très bien ne plus jamais être utilisé. (donc obligé d'avoir une moulinette de nettoyage des paniers fantômes) De toute manière, s'il refuse de payer (cas du "annuler" ) il y a peu de chance qu'il repasse par ce que soit il n'avait pas vraiment envie d'acheter (sinon pourquoi annuler) soit il retrouve plus sa carte (et s'il la retrouve plus, il aura du mal à te payer).
Si le serveur de ta banque renvoie le visiteur sur ton site sans passer par une page intermédiaire lui disant que le paiement c'est bien passé, je serais d'accord avec toi. Mais vu comment sont fait les serveurs de la plupart des banques rien ne te permet de savoir que le bonhomme reviendra sur ton site à part s'il ne voit pas arriver rapidement son colis (sauf sites de vente d'objets immatériels évidemment)
En passant, ça t'arrive souvent d'avoir des clients qui plantent ou ont des problèmes de connections entre le moment où la commande est créé et celle où le client à payé? Là où j'étais avant, ça a du arriver une seule fois en près de deux ans. Par contre, des faux acheteurs (commande non validé et "client" injoignable) qui n'ont jamais repassé la moindre commande, on en a eu chaque mois.

De mon côté c'est :
 
- remplissage de panier
- on clique sur "Valider la commander"
=> transfert du panier dans la table des commandes
=> vidage du panier
=> redirection vers site de paiement
 
Si le client fait "annuler" ... ben il a annulé la commande, basta
S'il ferme son navigateur, la commande reste "en attente de paiement" pendant une heure, après ça, delete automatique

S'il est arrivé sur la banque, c'est qu'il est inscrit sur le site. Donc pas de "panier fantome".

Si il retrouve plus sa carte, peut-être qu'il la retrouvera dans 1 semaine, et son panier sera toujours là

Ca tombe bien c'est le cas

Pas de faux acheteurs puisque inscription obligatoire. Si la commande n'est pas validée au bout de 24h, ça jarte.

Quant aux pb de connection etc, c'est juste des ex de cas parmi d'autres, c'est un problème de propreté : ça me parait logique que le panier ne se vide que quand le mec a payé, je vois pas le problème là.

Inscrit sur le site veut il forcément dire payeur? Tant qu'il n'a pas payé au moins une fois, comment peux tu être sur qu'il sera vraiment un client? S'il considère que finalement le total est trop cher, comment peux tu être sur qu'il reviendra? S'il ne revient pas, son panier que tu lui gardes précieusement "au cas où" ne sert donc à rien et est donc un "panier fantôme". Quelque soit la boutique en ligne ouverte au public, c'est un cas qui arrivera forcément un jour ou l'autre.
 

Et si les produits changent (fin de série ou produit non réédité par exemple) son panier ne sera plus complètement valide et ça fera un cas de plus à gérer dans ton système (d'un autre côté, il vaut mieux le gérer dès le départ au cas où). En plus s'il repasse une semaine après comment peux-tu savoir qu'il voudra la même chose et pas "celui ci non, celui là non plus et je vais prendre ça à la place"? On pense parfois simplifier la vie des gens tout en la leur compliquant.
 

Inscription validé comment? Par mail? Et même si l'inscription est validé, qui te dit qu'il t'a donné son vrai nom, sa véritable adresse postale et son vrai numéro de téléphone? Tant qu'il n'a pas payé son premier achat, c'est des données non validable. Qu'est ce qui te permet alors d'être certain que la boutique ne sera jamais visité par quelqu'un qui ira jusqu'à la page de paiement "juste pour voir" ou "pour faire chier" voire simplement "par ce que je m'ennuyais"? Comme tu dis, si la commande n'est pas payé au bout de 24 heures, tu la supprimes, c'est donc bien que tu géres le cas de ce que j'appelle les "faux acheteurs" : ceux qui vont jusqu'à la page de paiement sans jamais payer. Evidement, ça se gère de la même manière que les vrai clients qui n'ont pas pu payer pour telle ou telle raison.
 

Moi, ça me parait simplement plus propre de vider le panier quand on fait payer la commande. Comme dans un vrai magasin en quelque sorte. Avoir des paniers qui trainent un peu partout et devoir les vider à coup de moulinettes, je trouve ça assez crade. Mais bon, c'est vrai que t'es dans un cas particulié où t'es certain que l'acheteur repassera après avoir payé alors tu peux te permettre de laisser trainer quelques minutes des paniers remplis. Par contre, le jour où vous vous mettrez à vendre des produits physiques, là vous risquerez de voir s'accumuler des paniers jamais vidé alors qu'ils correspondent à une ancienne commande déjà livré. A ce moment là, tu sera obligé de créer une moulinette pour supprimer ces paniers là ou de les vider un peu plus tôt dans les étapes.

Dites-voir les PHPeurs, question optimisation/performances : Dans mon frameschmitt, après les require/include, c'est les tests d'existence de fichier qui prennent le plus de temps (is_file/is_dir etc.).
 
Est-ce normal qu'un test d'existence de fichier prend autant de temps ? J'ai même dû faire un fichier avec la liste des fichiers existants juste pour pas avoir à faire un is_file.

omega2 > c'est pas faux, je verrais tout ça quand ça sera en production.

 
Il me semble que le client passe avant la présence de quelques paniers fantômes qui trainent de ci de làvdans un db. Si on prends l'exemple d'amazon, tu peut garder ton panier super longtemps et pas te le faire supprimer le lendemain, ça permet d'accumuler tranquillement des trucs dedans avant de passer commande, le dernier panier que j'ai payé je l'avais commencé y'a 2 mois. Si tu l'avais vidé pour des raisons techniques j'aurais pas acheté les trucs choisis y'a 2 mois, simplement parceque je les aurais oublié depuis le temps.
( Il me semble qu'ils stockent les paniers au minimum un mois après la dernière visite, même non logué ).
 
 

 
Pouvoir changer son panier à tout moment et changer d'avis c'est aussi une bonne fonctionnalité et pas une complexité inutile, il s'agit de dépenser ses thunes on est donc parfois hésitant, ou alors on se rends compte tardivement qu'un produit a un délai de 4 semaines alors que les autres sont en stock et ça va ralentir toute la commande, on peut vouloir le virer au dernier moment. Ou rajouter un truc auquel on pense subitement (genre un cable quand on achète du matos, ou des piles, ou ....).
 
Enfermer le client dans un tunnel de validation, c'est plus simple techniquement mais je suis pas sur que ce soit le plus agréable ni le plus pratique pour lui

Ouais d'abord
Merci

0x90 > C'est pas con, je dois juste faire partie de ces acheteurs qui comparent les prix de plusieurs sites avant de choisir où j'achète et qui se fait donc chier à virer les restes qui trainent dans les paniers de mon achat précédent.
Au fait, la fnac et quelques autres sites on un truc qui nous mettrait tous d'accord : une "sélection" personnelle de produit. C'est simplement une liste dans laquelle on met les objets qu'on compte acheter plus tard. Je trouve ça mieux que les paniers quasi-éternel vu qu'au moins le panier ne contient que ce qu'on compte acheter dessuite et pas des trucs qu'on n'achètera que dans 6 mois ou qu'on pensait acheter trois mois plus tôt mais qu'on a finalement pas pris. Ensuite dans la page du panier, on a notre liste de produit avec les liens "Ajouter au panier" correspondant à chaque produit qu'on a mis dans notre "sélection".

Une Wishlist, j'en ai une aussi

Quel est le meilleur moyen d'envoyer une requête POST sans formulaire ?