manmachine

Si tu perd ta session àléatoirement cela vient peut etre d'un lien quelque part sur le site qui ne passe pas l'id de session dans l'url . C'est pour ca ( et pour plein d'autre raisons ) qu'il est préférable d'utiliser les cookies .

Je vois que tu utilise oscommerce , pour savoir si ta session passe par un ccokie ou pas il te suffit de regarder les urls si l'identifiant de session y figure c'est que tu n'utilise pas les cookies.

On bon conseil oublie innerHTML et opte pour les méthodes normalisé du DOM. Ca t'éviteras bien des galères.

Tiens, et en quoi $_REQUEST serait'il moins sécurisé qu'un $_GET ou un $_POST ?

Si tu veux conserver ton lien en dur type <a href="http://domaine.ltd">mon lien</a> tu ne peux pas opter pour un script qui comptabilisera le clic coté serveur. pour ca du dois avoir un lien en "moux" avec redirection apres l'incrémentation en base de données. Pour garder ton lien en dur le mieux est donc d'utiliser du javascript avec l'objet httprequest, en assignat un gestionnaire d'évenement onclick , sur ton lien.

Il plusieurs méthode mais la plus répandues reste celle ci 1 - ton client n'est pas loggé : - tu stock les informations de son panier dans la session 2- ton client est loggué - Si il a rempli son panier en etant pas loggué tu enregistre les informations de son panier en base de données, ce qui permet de le sauvergardé pour sa prochaine visite. - Tu recré le panier à partir des informations de la bdd Pour la table panier c'est pluto simple : id du client | id du propduit | date d'ajout | etc ...

Bonsoir, si un mail est envoyé individuellement que l'adresse mail du destinataire existe vraiment et que tu indique un return-path alors il n'y a aucune raison pour qu'il soit considérer comme du spam. Si certains serveurs ce font blacklister c'est parceque soit effectivement ils spam , soient ils sont utilisé comme relais par des spammeurs ou bien que des spammeur exploite une faille d'un formulaire de contact d'une page web par exemple . Il faut aussi pensé au règle de base afin d'éviter des plaintes : - pas d'envois de mails à des gens qui ne sont pas inscrit - laisser un possibilitée de désincription Bref si tu fais les choses dans les règles pas de soucis tu peu tres bien utiliser ton propre serveur.

Les causes peuvent etre multiple , ou ce trouve le fichier que essais d'ouvrir ? n'y a t'il pas un .htacces qui empeche sont ouverture si le user-agent n'est pas autorisé etc ... etc ... Tu dois donc commencer par tester que tu arrive bien à récupérer le fichier avant tout.

Non il ya de très bons decompilateurs de swf qui retranscrivent tres bien l'AS , il faut absolument éviter d'incorporer des données sensible dedans.

Question bète mais es tu sur que le fichier s'ouvre bien ? Enleve les @ pour commencer , ensuite si il s'ouvre bien essais d'augementer le nombre d'octets par ligne " 4096" par exemple .

Oui le empty peut faire l'affaire mais vu que dldstyle ne nous présente qu'un petit bout de code je ne sais pas exactement comment il traite cette variable donc je sécurise le test au mieux . il faudrait avoir plus d'infos sur le code de dldstyle pour déterminé si un empty suffit

En fait les solutions "maisons" des banques sont en général basé sur ATOS/SIPS , elles comportent elles aussi des backoffices . La différence entre PAYBOX et les solutions des banques est a mon avis , le prix , les commissions etc .. De plus les banques sont parfois frileuses et refusent tout simplement de fournir une solution de paiement electronique aux petits businness alors que paybox fournira le service plus facilement . J'ai déjà installer toute sorte de solutions dont PAYBOX, a priori la grande différence est vraiment le cout des transactions et de l'abonnement au service mais je n'ai pas de comparatif à te fournir d'autant plus que c'est le genre que tu peux négocier avec un banquier .

Tu peux executer des scripts PHP via javascript en utilisant l'objet "XML httpRequest" , (objet utilisé en AJAX) .

Ton problème vient tu fait que tu fais des unset sur les clés du tableau unset($_SESSION['panier'][$key]); donc ta variable $_SESSION['panier'] est elle toujours présente . donc lorsque tu teste sa présence if (!isset($_SESSION['panier'])) { echo "<p>IL EST VIDE CE PANIER B***** donc je peux faire session_unset() et session_destroy() </p>"; } else { echo "<p>Normalement il n'est pas vide</p>"; } ta variable existe bien il te répond s donc " Normalement il n'est pas vide " alors qu'il l'est peut etre . tu dois donc tester si il sagit d'un tableau et la taille de delui ci. if ( is_array($_SESSION['panier']) && sizeof($_SESSION['panier']) > 0 ) { echo "<p>Normalement il n'est pas vide</p>"; } else { echo "<p>IL EST VIDE CE PANIER B***** donc je peux faire session_unset() et session_destroy() </p>"; }

Salut, La réponse est simple il n'est pas possible de ne pas recharger une animation flash ( ou n'importe quel élément d'ailleur ) à chaque changement de page sans passer par des frames / iframes ou alors des solutions "type" Ajax . L'include PHP est traiter coté serveur qui renvoi donc une page html au navigateur comme si il sagissait d'un seul page. Si je comprend bien ton problème ce qui te gène est que ton menu à une sorte d'intro et que la jouer à chaque fois est pénible . Pour ca tu peut utiliser une variable que tu passe à ton objet flash apres le premier chargement de ta page pour qu'il ne joue plus cette intro par exemple. Soit en utilisant les cookies , les sessions ou en passant un parametre en mode GET de page en page .

tu peux aligner autant de div que tu veux 1 - en les placant en absolut et en leur donnant les bonnes coordonnées exemple .mondiv { position:absolute; top:0px; left: 10px; } ou bien en les sortant du flux a l'aide de l'instruction float <div class="box 1">contenu</div> <div class="box 2">contenu</div> <div class="box 3">contenu</div> en css .box { float:left; } ensuite pour restitué le flux sur l'element suivant ces 3 div tu met .tonselecteur { clear:both; }

Il ya aussi osCSS , une adpatation de oscommerce respectant les standards XHTML et CSS avec un system de template basé sur le CSS, que je developpe.

Le module de base ne fonctionne pas bien , télécharge en un plus récent dans les contributions http://www.oscommerce.com/community/contributions ensuite pour que le commande soit valider sur ton shop il faut impérativement que le client clique sur le bouton retour à la boutique une fois le paiment effectué , sinon tu n'as pas de retour de la part de paypal . C'est une des grandes faiblesses de paypal . Priviligie une solution de paiment avec un retour en socket http.

c'est vrai que j'aurais du nuancer mes propos, mais c'etait en réaction a la question des scripts clé en main. Car si ils vont prendre des part de marché c'est bien dans ce domaine . Biensur dire qu'il n'y a pas d'avenir avec des languages est exagéré .Mais ca sera de plus en plus dur de s'y faire une place.

Biensur ya de l'avenir , les solutions clé en main on toujours 1 voir 3 trains de retard par rapport aux nouvelles technologies . C'est sur que si tu reste au stade du PHP/SQL tu n'auras pas grand avenir dans le métier mais si tu suis de pret les avancées ( notament dans la POO) ,tu auras toujours du boulot .