captain_torche

Va falloir rester sur le bon vieux démarrer->programmes Y'aurait peut-être un moyen de biaiser, mais c'est du rafistolage de bourrin : ton lien appelle une page, qui contiendra en header un content-type correspondant à access, et qui contiendrait une base vide. Maintenant, les soucis : - La page appelée serait vide - Je ne connais pas le content-type d'access - Je sais encore moins générer un MDB (même vide) - Le logiciel ne s'ouvrirait pas automatiquement, il y aurait une fenêtre de demande d'ouverture ou d'enregistrement

Pas que je sache, non. C'est pour un intranet ?

Sauf que je demandais s'il s'agissait réellement d'un problème, ou si le fait de pouvoir isoler la variable dans l'url de l'image, était en soi un test de turing suffisant.

La commande Exec, n'a pas pour vocation d'ouvrir un programme sur le poste client, mais d'exécuter une commande sur le serveur. Ca pouvait marcher en local, avec easyPHP, vu que le serveur et le client sont une seule et même machine, mais ça ne marchera pas en distant.

Dans le script final, bien sûr, tu n'oublieras pas de ne pas lister les entrées './' et '../'. Edit : Dan, il y a une raison précise pour laquelle tu utilises print ou echo ?

J'ai pas de bench sous la main, mais je doute que lister 100 fichiers, soit si lent que ça.

Là, ce n'est pas dû à la fonction, mais au fait qu'au bout de 10 secondes, le script ait enclenché une sécurité lui permettant de ne pas boucler infiniment. Tu es sûr d'avoir des fichiers du type bancdaacc_X.jpg (où 1<X<20) ? Sinon, personnellement, je te conseillerais une autre méthode : - Chaque catégorie de bannières dans un sous-répertoire spécifique - Avec readdir, tu listes tous les fichiers de ton dossier dans un array - avec array_rand, tu choisis un de ces fichiers au hasard - et tu affiches l'image retournée. Ca t'évitera de faire des boucles 'à vide'.

Tiens, d'ailleurs, je me demandais (pardon pour la digression) : Plutôt que de mettre image.php?code=code (ce qui laisse le code en clair dans le source), ne vaut-il pas mieux générer l'image, hasher le code, et ne retourner que la valeur hashée ? Ou bien, le fait de regarder dans le source et trouver l'équivalent textuel du code, consiste-t'il en lui-même un test de turing suffisant ?

Essaye de tester l'existence de l'image avec file_exists.

Zapman : je pense que tes gains de positionnement, sont effectivement dûs à la refonte de ton site, mais je doute que la place des liens dans la page soit prépondérante. Si tu as bien séparé contenu et présentation, le cod crawlé par les robots y a beaucoup gagné en pertinence, d'où le meilleur positionnement.

Ca serait éminément plus simple, si tu nous donnais le code de tes ancres.

Je ne pense pas qu'il soit nécessaire de t'inquiéter outre mesure. Cette pratique (une redirection vers ton site), ne peut pas t'enlever de l'audience, ni véritablement nuire à ton site (à moins qu'il y ait un risque de duplicate content dans les moteurs). Ne t'attends pas non plus à une réponse extrèmement rapide : trois mails en deux jours, c'est beaucoup ! Laisse-leur le temps de constater la redirection, et de l'annuler le cas échéant.

Je sais bien que, dans un monde parfait (avec les fleurs partout et les bisounours), ça devrait se passer comme ça. Mais, pour l'instant, tous ne le font pas (et encore heureux qu'il y en ait qui le fassent). Ces pratiques sont vouées à disparaitre à plus ou moins long terme, mais comme l'a cité un autre hubber; une mise en page archaique permet également de justifier la facturation de la refonte du site. Ces entreprises partent d'une logique commerciale : pourquoi donner au client un truc super-performant; léger et accessible (et qu'on ne sait pas faire), alors qu'on peut lui livrer quelque chose qu'on a les compétences de faire, qui est horrible niveau accessibilité, mais qui correspond tout de même à ce qu'attendait le client. Ensuite, d'un niveau purement éthique, c'est une position discutable, mais c'est le côté commercial qui prime. D'autant que parfois, le client exige une prestation, qui implique automatiquement un déni de l'accessibilité (site full-flash, par exemple, parce qu'il veut des textes en mouvement).

Les grosses agences seront bien obligées, tôt ou tard, de se conformer aux standards. Mais il faudra attendre, malheureusement, un intérêt des entreprises pour ses standards, et leurs avantages (maintenance, évolutivité, accessibilité, etc), avant que le secteur ne bouge réellement. Car oui, tant que le client ne demande pas à avoir un site accessible, pourquoi le lui en faire un ?

<td colspan="2"><input type="image" src=&quot;http://www.votrevoyage.be/images/layout_19.gif" class="button_make_search_annuaire"></form></td> Comme tu peux le voir dans le bout de code que tu as donné, le formulaire se referme dans une cellule (alors que tu l'ouvres dans une autre). Si tu veux tenter de retrouver quelque chose de plus propre, je te conseille d'englober toute la ligne (tr) avec les balises de formulaire.

Ha, je n'ai pas dit que la différence était flagrante Ca va surtout dépendre du type de chaîne que tu auras à traiter. Bon, je viens de retrouver mes sources : http://www.phpdebutant.org/article147.php

On voit tout de même de plus en plus de clients demander des sites accessibles (même si ça reste encore trop marginal). Personnellement, j'ai bossé pendant trois ans dans une petite web-agency, et même si c'était il y a trois ans, je doute qu'on soit passés très vite aux standards : une formation en interne est impossible à envisager (surtout quand on n'a que deux intégrateurs), et il aurait fallu qu'au moins l'un des deux se forme à titre personnel, et réussisse par lui-même à argumenter pour faire évoluer les méthodes de l'entreprise. De plus, les délais obligent à aller au plus rapide, et ne pas perdre de temps à apprendre de nouvelles technologies. J'en ai fait, là-bas, du <span class="titre"> ! Mais on sortait également de la "balkanisation du web", et toutes les méthodes aguerries qu'on possédait, servaient à contourner les bugs respectifs de netscape 4.7 et IE 5, ce qui nous donnait tout de même pas mal de boulot.

Pour faire rapide : Les .= signifient une concaténation. C'est une manière plus rapide que d'écrire $string = $string.$new_string; Pour les guillemets, effectivement, on peut s'y perdre. Avec un éditeur respectant la coloration syntaxique, ça passe mieux. Sinon, pour info : entre guillemets simples ' ', PHP ne fait aucun traitement. Entre guillemets doubles " ", PHP remplace les variables par leurs valeurs respectives. A l'affichage, le résultat de : echo 'votre nom est '.$nom; et celui de : echo "votre nom est $nom"; est identique, mais le temps de traitement n'est pas le même. Et, pour finir, mysql_real_escape_string (ou son équivalent déprécié, mysql_escape_string), n'échappe pas les underscores. Les codes échappés, sont les suivants : NULL, \x00, \n, \r, \, ', " et \x1a.

Ensuite, il faut voir si son champ est harmonieux (on n'utilise que des virgules pour la séparation, pas d'espace, etc). Mais merci d'argumenter dans mon sens

Tu peux utiliser la fonction explode, pour transformer ta chaîne en tableau. Edit : pas assez rapide.

Quand le moteur arrivera sur le .net, il suivra la redirection, en mettant s'il y a lieu ses informations à jour (d'où le 301). Dans les deux cas, on arrivera au final sur le .be

Le type image fonctionne comme un type submit, un petit test t'aurait aidé à le découvrir par toi-même

<input type="image" src="chemin_de_ton_image" />

Non, avec la redirection 301 (moved permanently), tu ne perdras rien. C'est juste que quelle que soit l'extension générale que tu choisiras, les deux aboutiront au même endroit, en précisant à celle qui ne sera pas choisie, que les pages sont déplacées.

J'utilise Notepad++, gratuit et très sympa à mon goût.