Ganf

Moi ce que je retiens c'est : 1- on va lui mettre une pub 2- ça va le faire chier 3- alors on ne va la mettre qu'une fois 4- mais ça va quand même le faire chier 5- alors on va la mettre quand il part comme ça si ça l'emmerde c'est trop tard il sera déjà passé et on perdra pas de visites. Du 1 au 4 c'est compréhensible (tout le monde préfère sans pub mais ça reste encore un des moins mauvais systèmes). Le 5 est une très mauvaise réflexion parce que le visiteur ne reviendra pas, ne conseillera pas le site à un autre .. bref, c'est quasiment comme si tu mettais la popup à la première page visitée au lieu de la dernière. Maintenant, au niveau technique, c'est impossible à faire correctement. - Tu ne peux pas savoir où va l'internaute quand il quitte une de tes pages. Le résultat c'est que soit tu met une popup à chaque fois qu'il change de page, soit tu n'en met pas. Il n'y a pas d'intermédiaire à ma connaissance (sinon ça voudrait dire que tu peux savoir où l'internaute va et ça serait un problème de confidentialité). - Tu te heurteras très vite à tous les anti-popup, qui savent tous virer les popup des onload et onunload. La seule chose possible c'est de faire le contraire : mettre une popup à la première page visitée sur ton site. Là tu peux mettre un cookie pour tracer le fait qu'il a vu la pub et ne pas lui en renvoyer une pour les pages suivantes. Notes que c'est d'ailleurs ce que font la plupart des sites qui mettent des pub un peu trop imposantes. Ils utilisent la première page visitée et pas la dernière. Par contre ça emmerdera tous ceux qui refusent le cookie (ils verront une pub à chaque page) et ça te mettra face aux réalités : tu envoies une popup qui va agacer les gens, ils risquent de ne pas apprécier et de s'en aller. Tu n'auras plus l'excuse du "boaf, de toutes façons il partait".

Question: qu'est ce que tu veux ouvrir ainsi sur toutes tes pages ? Ca va *très* vite être lourd pour tes visiteurs. Sans compter que ce genre de chose est bloqué par n'importe quel filtre à popup qui se respecte (et heureusement). Sinon effectivement, ton code javascript doit être présent ou lié sur toutes les pages du site. Pas moyen d'y couper. Ceci dit, même avec des centaines, il ne doit pas être compliqué de faire une moulinette pour insérer une balise javascript partout. Un rechercher/remplacer sur tous les fichiers devrait faire l'affaire.

Je n'ai pas mes scripts sous la main mais en attendant tu peux déjà t'inspirer de tout ça : http://www.brainjar.com/dhtml/tablesort/default.asp http://webfx.eae.net/dhtml/sortabletable/sortabletable.html http://www.kryogenix.org/code/browser/sorttable/ http://dhtmlkitchen.com/scripts/draglib/Dr...able/index.html

Soit je n'ai pas compris soit tu n'as pas cherché très loin à partir de ce que je t'ai donné. Si tu veux compter comme 2 quand une chaîne apparait deux fois dans le même item de tableau : function countItem($tab, $search) { $found = 0 ; foreach($tab as $value) $found += substr_count($value,$search) ; return $found ; } Si tu ne veux qu'une occurence par item : function countItem($tab, $search) { $found = 0 ; foreach($tab as $value) if (strpos($value,$search)!==FALSE) ++$found ; return $found ; }

function countItem($tab, $search) { $found = 0 ; foreach($tab as $value) if ($value==$search) ++$found ; return $found ; }

\q

J'ai bien compris, mais attention aux principes de programmation quand on les applique à des langages de script. Certaines choses s'inversent assez facilement. Cette astuce de tableau est connue pour être plus rapide en PHP que la suite de elseif (sur une liste d'un nombre conséquent d'éléments). Je n'ai pas cherché pourquoi ici mais je ne serai pas étonné qu'il s'agisse du temps nécessaire à PHP pour aller chercher une variable dans sa table de hash. Ton elseif arrête effectivement la comparaison avant la fin mais en réalité ça n'économise rien. Ce qui coute cher ce n'est pas tant le test, c'est la conversion en code machine et l'analyse pour descendre à la fin de la condition. L'optique tableau fait elle aussi une seule comparaison (et pas une avec chaque élément) mais sera plus simple à interpréter. La règle de base est de toutes façons toujours "ne jamais faire des optimisations de syntaxe". C'est encore plus vrai en langage de script car si tu prend ce genre de langage c'est bien pour favoriser la lisibilité et le code source sur les performances. Il est aussi assez rare qu'une optimisation de syntaxe gagne grand chose sur du code interprété. Argh, en fait il faudrait le placarder partout : "ne jamais faire des optimisations de syntaxe". Quand tu sacrifies la lisibilité pour un quart de microseconde (ça doit être à peu près ce que tu gagnes ici dans les meilleurs jours) ça te retombes toujours sur le coin de la figure. C'est encore plus vrai sur un langage de script où gagner quatre octets de mémoire (cas du tableau) ou 4 opcode (regrouper des cas) n'a strictement aucune influence sur le déroulement global du script (oui, même avec plein de ce genre d'optimisations partout on ne gagnera vraiment pas de quoi payer le développeur qui fait ces optimisations). C'est encore on ne peut plus vrai avec PHP, qui a souvent des effets contraires à ce que la plupart des développeurs attendent. Vous saviez que l'accès à une constante est plus lent que l'accès à une variable en PHP ? qu'une référence ne fait pas gagner en vitesse la plupart du temps contrairement aux autres langages ? De plus je doute fortement que tu aies une quelconque optimisation ici. Que tu utilises un or ou un elseif, les deux s'arrêteront à la première expression vraie. Il n'y a pas plus de calculs dans l'un que dans l'autre. Ce qui me gêne dans la solution de regrouper plusieurs cas dans un elseif c'est la lisibilité et la maintenance. Pour voir ce que fait tel ou tel cas on est obligé de "décoder". Si on a un cas par ligne, avec des syntaxes très très proches pour chaque ligne, l'oeil voit globalement ce qu'il se passe. Si tu as une expression différente dans chaque elseif ça devient moins clair. Si réellement on veut associer plusieurs cas ensemble, alors pour le coup un switch est plus logique (vous voyez ? j'aime bien les switch, ce que je n'aime pas ce sont les switch qui sont avec un break à chaque cas). Mais bon, la lisibilité c'est tout à fait subjectif, si tu trouves ça plus clair libre à toi d'utiliser mais franchement oublies ces questions "d'optimisation"

Euh, je vous en prie, remettez en cause mes codes, d'autant que j'ai l'habitude de faire beaucoup de fautes en première frappe. Visiblement il y en avait une belle (cf post de Dan). _AT_Anonymous: aucune configuration que je connaisse pourrait faire que PHP considère toute variable comme existante. Il peut éventuellement renvoyer une valeur pour une variable inexistante (valeur NULL) mais isset() répondra bien false. _AT_portekoi: la différence c'est que si j'oublie un point virgule j'ai une erreur de syntaxe. Si j'oublie un break non seulement je n'ai pas d'erreur, mais ça peut sembler marcher lors de mes tests, et surtout je ne serai pas capable de voir une quelconque erreur quelques jours après parce qu'il est naturel qu'un switch n'ai pas de break. Il n'y a rien de dramatique mais le privilégie toujours les formes de syntaxe standard, qui facilitent beaucoup moins les erreurs.

_AT_TheRec: je n'ai rien contre le elseif (même si je préfererai probablement faire un elseif par cas plutot que d'utiliser comme toi un opérateur logique pour cumuler les conditions) Je n'ai même rien contre ton switch. Ce qui me gêne c'est le switch donné par portekoi, celui que j'appelle "utilisé à contresens". Le switch est fait pour avoir des clauses globalement cumulables et non exclusives. Il est malheureusement trop utilisé à la place des elseif alors qu'en PHP il n'offre que des désavantages (il n'est pas plus rapide mais par contre il est une horreur en maintenance à cause de la syntaxe différentes des autres structures et du fait qu'un "break" oublié ne se voit pas forcément) Pour la mémoire, franchement, même si tu avais quelques centaine de cas, tu ne verras vraiment pas la différence. On parle là d'un ou deux ko, pas plus. Comme il ne dépassera pas la centaine, on peut largement oublier tout ça. Si je propose cette méthode par tableau c'est qu'elle est nettement plus efficace à maintenir et à manipuler. D'ailleurs, si vraiment tu t'occupes des perfs, passer par un tableau ici s'avère probablement plus rapide qu'une suite de test, même si l'intuition tend à dire le contraire. Avec un bon cache d'opcode mon tableau est quasi considéré comme du statique et je n'ai qu'une résolution d'index de tableau au lieu d'une suite de tests/branchements. J'utilise quelques octets de mémoire mais je les occupe moins longtemps et avec moins de proc. Au final je ne garantis vraiment pas que ma solution est la moins optimisée. Enfin bon, je ne sais même pas pourquoi on parle de mémoire et de perf sur ce genre de code. Si vous en êtes à optimiser à ce point là ce n'est plus en PHP qu'il faut vous pencher. Et franchement j'ai très rarement vu des raisons de se pencher sur ce genre de détails de perf. Sorti de Yahoo et d'une centaine de sites dans le monde, je pense qu'on peut oublier tout ça.

<?php $map = array( '10' => 'cas01.php' , '11' => 'cas01.php' , '200' => 'cas01.php' , '15' => 'cas02.php' , '397' => 'cas02.php' , ); $default = 'cas01.php' : if (isset($map['abv'])) { include($map['abv']); } else { include($default); } Je donne ça pour faciliter la maintenance, coté vitesse je doute que tu fasses vraiment une différence à moins de milliers de lignes, et encore. (et pitié, ne lui conseillez pas l'horrible switch utilisé à contre-sens)

- Tu échappes avec une fonction spécifique SQL quand tu envoies dans la bdd (ça peut être addslashes, mysql_real_escape_string ou d'autres) - Tu échappes avec htmlspecialchars ou htmlentities quand tu envoies ton html Tu ne devrais pas échapper le html avant insertion en base. Tu risquerais de te retrouver avec des problèmes sur les contraintes de taille, avec des problèmes si tu veux utiliser tes données ailleurs que dans du html, ...

Le problème va se poser avec toutes les url qui contiennent un caractère interprétable (en l'occurence un "&"). Il se trouve que tes URL google en ont, que visiblement tes autres URL de test n'en ont pas, mais ça n'a rien de spécifique à google. En gros tout ce qui est à partir le premier "&" dans l'ancienne URL ne sera pas récupéré (parce que PHP interprétera ça comme un nouveau paramètre de l'url actuelle et pas comme la suite de l'ancienne URL)

Sauf que le décodage est déjà fait par PHP, ce qu'il te faut faire c'est l'encodage. On doit pouvoir encoder en js, au pire par une expression rationnelle sortie des tiroirs, mais là pour le coup je n'ai pas de pistes à te donner. en PHP ça serait quelque chose comme $url = 'xxxxx?var='.urlencode($oldUrl) ;

*Toujours* faire des échappements. Tu envoies des données en SQL ? addslashes, mysql_real_escape_string() ou l'équivalent dans ton SGBD. Tu envoies des données en HTML ou XML ? htmlspecialchars() Tu envoies des données dans une URL ? urlencode() Tu envoies des données dans un fichier texte brut ? probablement un iconv() pour gérer les jeux de caractères Si tu as ce genre d'erreur c'est que tu as envoyé une chaîne de texte directement en sortie sans la transformer ou lui appliquer un échappement. Tu ne devrais jamais faire ça. Ici tu as des URL, c'est un codage qui se fait avec urlencode(). La fonction inverse (que tu ne devrais quasiment jamais appeler vu que PHP gère ça tout seul) est urldecode().

comment insères tu la bannière ? qui envoie l'image/iframe, toi ou ton prestataire ? Si c'est toi qui envoie les données de l'image/iframe, une bête entête HTTP "Refresh" devrait suffire. Si c'est toi qui insères le tout mais eux qui fournissent le matériel, tu peux peut être aller retirer l'image pour en remettre une autre via javascript. Si c'est, comme le plus souvent, un javascript de ton prestataire qui fait tout tout seul, ça risque d'être plus complexe et spécifique à ton code (donc pas de solution à te donner ici). Mouais, disons que tu as un contrat en paiement par millier d'affichages, c'est ça ? Il est probable que ce que tu essayes de faire soit moyennement apprécié par ton prestataire, voire interdit. S'il voulait recharger régulièrement il aurait déjà prévu un mécanisme pour ça. Pas la peine de faire semblant d'avoir le visiteur comme motivation. Il n'y a rien de mal à vouloir gagner de l'argent avec son contenu. Maintenant si je me trompe et que tu étais franc la dessus laisses moi te donner un conseil : retire tes publicités, c'est surtout ça que tes visiteurs apprécieront dans leur ensemble. Ca veut dire moins de trucs qui clignotent et agacent ou empêchent de lire, moins de bande passante utilisé, un bandeau supérieur plus petit donc moins souvent du scroll à faire ... Sinon, pour le principe du rechargement toutes les 30s, même si je doute que la remarque porte : Changer de bannière régulièrement (et c'est encore plus vrai si c'est aussi fréquement que toutes les 30s) ça va faire "changer" ta page (couleurs, repères) et réellement déranger ceux qui lisent et s'intéressent au contenu. En général des éléments qui apparaissent/disparaissent/bougent/changent c'est tout sauf une bonne idée. Les bannières sont déjà généralement une horreur de ce coté là (et les pub texte de google ont apporté un "mieux" énorme), pas besoin d'en rajouter en modifiant ça deux fois par minute. Si vraiment tu tiens à recharger les bannières fais au moins le de manière relativement tranquille et laisse là au moins deux minutes. De toutes façons, même pour inciter à cliquer, si tu comptes le temps de lire la pub, qu'elle porte, que l'utilisateur se décide, je gage que quand certains voudront cliquer elle sera déjà partie (et *pan* pour l'idée d'intéresser les visiteurs mais surtout *pan* sur les revenus potentiels).

_AT_Cabiroo: Il cite quelque chose qui dit grosso modo "c'est le droit du webmaster de refuser un lien vers chez lui" et il demande d'ou vient cette affirmation, quel est le texte de loi dans le CPI qui donnerait ce droit. _AT_wadison: C'est tout le fondement de la problématique des liens et pour autant que j'ai pu trouver et qu'on en a discuté ici : ce "droit" n'existe pas (sauf cas spécifiques comme le fait de donner un lien vers une ressource qu'on sait privée et publiée de manière involontaire, faire des liens de manière automatisée et systématique vers toute une série de contenu, etc.). Par contre je ne vois pas d'où vient ta citation.

En même temps ils disent dans le lien que tu donnes que "The main page of your web site should load in 8 seconds or less with a 56K modem.". Ils sont donc plus strict que moi qui parle de 10 secondes. Attention aussi au fait que ce texte semble dater cle de 2002. Depuis 3 ans les débits ont changés, les habitudes des gens aussi. De toutes façons c'est bien simple : es-tu prêt à attendre 15 secondes la page que tu as demandé ? es-tu prêt à attendre ce même temps pour une page lors d'une recherche ? moi non en tout cas (en fait mois déjà plus de quelques secondes je zappe, mais j'ai la chance d'avoir une bonne connexion). Ne pas externaliser les CSS ? pourquoi ? c'est tout le contraire qu'il faut. En externalisant les CSS : - tu perd entre 30 et 200ms parce qu'il faut faire une requête HTTP supplémentaire - tu occupe un slot de téléchargement en plus (ils sont limités sur les navigateurs, entre 4 et 8 par domaine en général) le temps de télécharger la CSS + tu optimises l'utilisation de ta ligne (au lieu de télécharger un fichier de 10ko à 25kb/s tu peux télécharger deux fichiers de 5ko à 2*25kb/s) + tu ne télécharge qu'une seule fois le fichier (les pages suivantes le navigateur utilise le cache et donc n'a pas besoin de retélécharger le fichier), c'est un gain énorme qui se voit dès la seconde page + tu permet au navigateur d'afficher plus vite le contenu (vu qu'il n'a pas 5k de CSS à télécharger avant d'y accéder) et donc de faire le premier rendu rapidement même s'il met du temps à télécharger le reste (ça c'est très important pour que le visiteur ne parte pas) Les avantages compensent largement les inconvénients. Et ça vaut aussi pour le javascript. Pour ce qui est des grosses animations ou graphismes, disons que si tu te débrouilles pour qu'elles soient en fin de la liste des téléchargement et qu'elles ne soient pas nécessaire à la page, ce n'est pas trop grave. Mais oui, dans l'ensemble moins il y en a mieux c'est. Et en général il n'y a pas besoin d'avoir trop de choses pour avoir une page sympa et claire. D'ailleurs la mode est plutot au dépouillement en ce moment.

pardon ? 17 secondes ? 15 secondes ? vous rigolez ? Première piste (je ne sais plus d'ou me viennent ces chiffres mais ils sont courrament utilisés) : Un visiteur passe en moyenne moins de 10 secondes avant de décider si le site est intéressant ou s'il part ailleurs. Ca peut tomber à 5 secondes dans le cas des gens un peu plus aguéris aux recherches Internet. Ce temps comprend le téléchargement et la lecture. Seconde piste : dans une interface, pour assurer uen continuité dans le cheminement il faut en théorie réagir en moins de 100ms (cette règle est plus pour les logiciels classiques que pour Internet, mais si le média change les intuitions de l'utilisateurs et ses capacités de concentration/lecture/cheminement sont assez souvent les mêmes) Pour être plus concret, en considérant que les gens sont un peu plus habitués à attendre sur Internet qu'ailleurs, que les gens en 56k savent qu'ils ont une faible connexion et qu'ils ont à attendre plus que les autres, je donnerai plutot les chiffres suivants : - moins de 5 secondes avant l'affichage du texte et/ou du cadre principal. L'idée est de savoir où on est, savoir de quoi parle la page/le site, savoir si on y trouvera ce qu'on cherche. Ce temps comprend le temps de connexion, de téléchargement et de rendu. Le rendu peut être légèrement plus long si ça s'affiche sur plusieurs pages en défilement vertical mais les premières pages (on va dire les 10) doivent au moins passer dans ce temps. - pour le premier accès au site, moins de 10 secondes pour le rendu complet des éléments standards (images de décoration, interface, menus, exécution des javascripts, fin des animations temporaires qui sont faites à l'affichage de la page, etc.). La seule chose qui n'est pas compté la dedans se sont les éléments des pages "spécifiques", par exemple une page faite pour diffuser une vidéo, une grosse image, un pdf, éventuellement une grosse déco qui ne manquera pas et ne troublera pas si elle n'est pas affichée .... - pour les accès suivants le rendu total (moins la grosse image/vidéo si c'est le but central de la page) doit passer en dessous des 7 secondes. Je donne là des chiffres qui me paraissent déjà importants et qui mériteraient probablement d'être divisés par deux. Je donne aussi là des chiffres qui ne peuvent s'appliquer que aux bas débits (qui savent qu'ils ont à attendre). Ne surtout pas croire que ce sont des temps acceptables pour s'autoriser ça sur du haut débit. Si vous avez des problèmes à tenir ces temps : - compressez vos pages avec un soft du type mod_gzip - faites en sorte que vos scripts utilisent correctement les requêtes conditionnelles HTTP (Etag et date de dernière modification), principalement pour les images, css, javascript et contenus "externes" - passez les gros css et javascript en externe - utilisez fournissez des temps d'expiration dans les entêtes HTTP pour qu'un client ne télécharge pas 50 fois la même image Avec un mod_gzip vous pouvez presque envoyer 150ko sur la page d'accueil en restant dans les bons temps. Avec en plus une bonne gestion HTTP vous pouvez envoyer presque 100ko de contenu "nouveau" (c'est à dire jamais rencontré sur les pages précédentes) par page. Ca laisse tout de même pas mal de possibilités.

Les navigateurs oraux sont très généralement de simples lecteurs d'écran avec parfois un accès direct à l'API du navigateur. Si le navigateur sait gérer le javascript (et il le sait vu que c'est quasiment tout le temps MSIE derrière), alors ton navigateur oral gère le javascript. Le seul point délicat c'est qu'il ne détectera les changements dans la page que suite à un clic ou une action utilisateur. Pas la peine donc de penser à déclencher des choses au survol ou avec des timers complexes. De ce coté là tu t'en fais pour rien à priori. Même les pda devraient savoir faire du javascript Javascript est très pratique pour de l'aide utilisateur ou de la présentation. Il permet de rajouter des effets, du comportement. Par contre il est assez rare qu'il soit nécessaire d'utiliser javascript pour proposer une fonctionnalité essentielle. Pour parler concrêtement, en bas de ce forum c'est un lien "réponse rapide". C'est du javascript, s'il n'est pas là je suppose que la réponse rapide est toujours dépliée. Je perd l'aide utilisateur mais je ne perd aucune fonctionnalité. A l'autre bord certains forums utilisent le javascript pour marquer les messages nouveaux ou anciens. Sans javascript on perd quelque chose d'important pour l'utilisateur, mais on ne perd qu'une aide, le forum reste utilisable. Tant que tu reste dans la philosophie "javascript est une surcouche pour aider l'utilisateur" et pas "javascript remplace HTML", tu ne devrais pas avoir à trop faire de boulot pour que tout soit accessible sans. Quant aux raisons de la désactivation : ça fait sauter beaucoup de pub, mais aussi tous les gadgets et scripts inutiles (les bidules qui suivent la souris, les timers qui font des arbres de noel....). Pas mal de geeks se concentrent sur le contenu et acceptent de se passer de pas mal d'aide javascript si ça leur assure de louper aussi tous les gadgets agacants. Sinon il reste des gens qui ont désactivé le js par erreur ou en lisant un article paranoiaque et qui ne savent pas comment le désactiver. Il y en avait beaucoup il y a un ou deux ans. Maintenant ça devient assez rare, c'est moins à la mode de désactiver js. Javascript c'est très bien. Tant que tu ne l'utilises pas pour remplacer le navigateur ou le HTML, ça devrait poser très peu de problèmes.

Je pense que les principaux moteurs de recherche savent maintenant composer avec ça et ne pas prendre en compte le PHPSESSID. Il faudrait vérifier mais je suis sûr que les gens du forum référencement sauront ce qu'il en est si tu leur pose la question. PHP gère tout seul les SID mais il n'est pas magique. Il reconnait les formulaire, les liens, les images .. à partir d'une série d'attributs/balises qu'il connait. La reconnaissance est très basique. Ca ne marchera pas si tu utilises une balise peu courante, si tu t'amuses à modifier en javascript la cible de tes liens/formulaires/images/applets, ou encore si tu génère du contenu directement en javascript. (pas que PHP soit mal foutu mais il ne peut pas tout prévoir et analiser le js pour savoir ce que ça va faire à l'exécution) Je te propose la lecture d'un article qui résume bien la question du tracking statistique et des possibilités avec PHP : http://frederic.bouchery.free.fr/?2005/02/...us-etes-traques

Je me permet de sortir encore de la problématique initiale mais .. est-ce que réellement c'est une session qui est adaptée à ton cas ? Les processus de recherche de tri et de navigation ne gagnent pas forcément à passer en session. Il faut bien voir que ça empêche par exemple de faire deux recherches paralleles avec des paramètres différents. Or vouloir comparer deux recherches sans perdre le contexte d'une des deux n'a souvent rien de totalement fantasque. Je ne connais pas ton application et ton contexte, mais ça peut être aussi une piste à réfléchir. Tu "devrais" est peut être un peu fort. Disons que je pense qu'il faut éviter d'autoriser les identifiants de sessions dans l'URL si ce n'est pas absolument critique à cause d'un contexte particulier. Maintenant ce sont mes choix hein, d'autres ont des avis différents. Moralement j'ai beaucoup moins de difficulté à retirer une fonctionalité à quelqu'un qui a refusé l'accès de son coté (cookie) qu'à quelqu'un qui n'a pas le choix (handicap quelconque par exemple). J'avoue que je considère que si quelqu'un refuse c'est son choix et plus mon problème, effectivement. Ce qui veut dire que nul part dans ce site tu ne fais d'identification à l'aide de la session, tu ne stockes de données personnelles ... *et* que tu garantis que ça sera toujours ainsi (sinon tu risques une faille dans le futur si tu oublies ou si tu n'as pas le temps de tout refaire). Oui et non. Ca désactive la lecture automatique des SID dans l'URL ou le corps de la requête lors d'un appel à session_start(). C'est effectivement fait pour empecher tout passage de SID ailleurs que dans les cookies. Maintenant rien ne t'empêche de relire la valeur du SID dans $_REQUEST et l'amener manuellement à PHP via session_id(). Ceci dit dans ce cas ça revient à faire la même chose que PHP en t'exposant aux mêmes risques donc autant désactiver use_only_cookie. PHP fait globalement bien le travail du passage du SID. Le problème ce n'est pas que PHP le fasse, c'est que ce soit possible Concernant ini_set() je ne sais pas. Je présume que ça doit marcher si tu changes la valeur avant l'appel à session_start() (et donc que tu n'as pas de session.auto_start activé) mais ça demanderait vérification.

Là on sort de la technique pour passer dans l'opinion mais : Si quelqu'un perd une valeur de recherche ou un ordre de tri de liste, une préférence, c'est par nature plus ou moins acceptable. Je ne veux pas dire que ce n'est pas gênant, mais si je la perd parce que c'est l'utilisateur refuse de stocker la chose, c'est son problème et plus le mien. S'il refuse les cookies il refuse la mémoire HTTP et c'est justement ça qu'il doit théoriquement avoir comme conséquence. Vu le faible nombre qui refusent les cookies et le fait que la plupart d'entre eux savent ce qu'ils font et les implications au niveau des pertes, je juge que ce n'est pas à moi de dégrader quoi que ce soit (si c'était un manque de support et non une désactivation mon avis serait peut être différent). http://blog.dreams4net.com/P3pEtFiltresDeCookies http://www.yoyodesign.org/doc/w3c/w3c.html http://www.p3ptoolbox.org/ Rien d'autre sur le P3P dans les cartons. J'avais fait ça plus en réponse à un fil de forum. A l'époque il n'y avait pas grand chose et je n'ai pas fouillé depuis. En fait cette norme est à mon avis morte née. La seule chose qui reste utile sur ce sujet c'est la recette de cuisine pour passer le filtre MSIE. Tout le reste c'est une belle utopie et une des grandes illusions du W3C : Ca se base sur la bonne foi des déclarant. Sauf que dès que c'est utilisé pour faire du filtrage (quasiment l'unique exploitation que les gens trouveront utile) les développeurs vont mentir pour contourner le filtrage. Merci, ça fait plaisir de voir qu'il est lu et apprécié.

Tout dépend de ce que tu veux faire. Pour les statistiques tu as deux alternatives au marquage par cookie : - l'utilisation d'un webbug qui se base sur les requêtes conditionnelles HTTP pour identifier de façon unique un client - une bête aggrégation de toutes les requêtes venant d'une même ip publique, même ip source, même navigateur qui sont faites à moins de 30 min d'intervalle (ce n'est certes pas super précis mais c'est largement suffisant pour des statistique, de toutes façons le marquage par session n'est pas précis lui non plus dès que le visiteur utilise un proxy ou soft de type "respect de la vie privée") Si c'est pour un login, une gestion des préférences ou un effet "mémoire" (type caddie ou boutique) la bonne question c'est se demander pourquoi le client a désactivé les cookies. Dans quasiment tous les cas c'est un power-user qui a choisit consciement de ne pas se laisser tracer. Dans ce cas là il refuse volontairement les sessions et faire passer l'identifiant dans l'URL c'est aller contre sa volonté. C'est rarement une bonne idée. Certes il risque de louper des fonctionnalités mais en général il sait ce qu'il risque, ou plutot ce qu'il veut. Certes il y a aussi des gens qui ne savent pas ce qu'ils font mais ils sont rares et pour eux la très grande majorité des sites de commerce ou institutionnels ne marcheront pas : il est déjà au courant qu'il y a problème chez lui et une page sur comment activer les cookies sera bien plus utile qu'un passage des identifiants dans l'URL. Après il restera toujours des gens qui seront exclus si tu ne passes pas les identifiants dans l'URL. C'est à toi de voir jusqu'où tu veux pervertir ton modèle et ta sécurité pour des gens qui ont désactivé ou interdit le mécanisme justement fait pour ce que tu veux. Tu en connais beaucoup des gens qui n'ont pas les cookies sans que cela soit fait exprès ?

Bonjour, *Si* le use_trans_sid est activé (ce qui ne devrait jamais arriver, on ne le répetera jamais assez) PHP essaye tout seul de déterminer si le visiteur supporte ou pas les cookies pour savoir s'il fait passer l'identifiant de session par la chaîne de GET ou par un cookie. Le problème c'est que les navigateurs n'annoncent pas à l'avance s'ils acceptent les cookies. Il n'y a qu'une seule possibilité d'auto-détermination pour PHP : Si un identifiant a été reçu par cookie il le renvoit par cookie, sinon si un identifiant a été reçu par GET ou POST il le renvoit via la chaîne de GET. Si aucun identifiant n'a été reçu on ne peut pas savoir ce que supporte ou pas le client, on lui envoie donc l'identifiant par les deux moyens la première fois, on restreindra la seconde suivant ce qu'on aura reçu. Le résultat c'est que quel que soit le support des cookies, la première fois on ne peut pas savoir ce qui marche donc on envoie aussi par l'URL, même si ce n'est pas nécessaire. Je te suggère fortement de mettre le "use_only_cookies" à On et le "use_trans_sid" à Off. Le trans_sid à Off t'évitera : - d'avoir à gérer la transmission des identifiants de session à la main à chaque fois que tu fais des URL de manière non classiques (paramètre d'applet, javascript, xmlhttprequest ..) - d'avoir des divulgations et vols de session à cause de l'entête HTTP "referer" envoyée par les navigateurs - d'avoir des URL imbitables et complexes à copier/coller, transmettre par oral ou envoyer via email pour tes visiteurs. Le only_cookies à On te permettra d'éviter une énorme majorité des fixations de session ou au moins de compliquer la tache des méchants. http://blog.dreams4net.com/SessionsIdentifiantsEtReferants http://blog.dreams4net.com/SessionUseTransSid

Simplement parce qu'en général 4 c'est très facile à avoir. En dessous c'est quasi comme si tu n'avais rien. C'est après que ça devient quelque chose de non trivial. Si tu as 3 c'est AMHA que tu as un problème quelque part. C'etait le concept de vouloir à tout prix garder un PR si faible que je trouvais étrange. Dans ce cas repartir sur de nouvelles URL en corrigeant le pb qui te faisait rester à 3 ça n'aurait pas forcément été plus mauvais.