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).