Aller au contenu

Dan

Direction
  • Compteur de contenus

    30 688
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Dan

  1. Salut Nicolas, La première chose à faire si tu veux pouvoir valider tes pages est de mettre un <!DOCTYPE...> en toute première ligne (avant la balise <html>) Tu peux mettre celui-ci comme tes pages ne sont pas en 4.01 strict. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> Ensuite, partout où tu utilises "width=..." met des doubles quotes de part et d'autre de la valeur. Une fois cela fait, tu verras que la majorité des erreurs disparaissent, et celles qui restent peuvent être contournées par l'utilisation de CSS, par exemple en remplaçant: <td background="illustration/index_bh.gif" width=5%> par: <td style="background-image:url('illustration/index_bh.gif'); width:5%;" > Dan
  2. Salut Stéphane, Probablement parce que les règles de réécriture d'URL n'utilisent que ce numéro pour retrouver la page concernée. Il existe nombre de sites sous Spip (ou autres CMS) qui génèrent des URLs sur base du titre des articles. Et dans ce cas, tu vois le plus souvent un N° à la fin car la règle convertit: les_infos_de_la_semaine-12.html en article.php3?id_article=12 Dan
  3. Salut Raoulmapoule, Je n'ai pas trouvé de solution valable en CSS, mais avec un peu de javascript, on arrive à faire ce que tu cherches. <table border="1"> <tr onclick="location.href='index.php', target='_blank'; " onMouseOver="this.style.cursor='hand'; this.bgColor = 'orange'; " onMouseOut ="this.bgColor = 'FFFFFF'"> <td>cellule 1</td><td>cellule 2</td> </tr> <tr onclick="location.href='page2.html', target='_blank'; " onMouseOver="this.style.cursor='hand'; this.bgColor = 'orange'; " onMouseOut ="this.bgColor = 'FFFFFF'"> <td>cellule 3</TD><td>cellule 4</td> </tr> </table> Dan
  4. Ernestine, Olivier a été plus subtil que moi sur ce coup là Dan
  5. Ernestine, La fonction preg_replace est ce qu'il te faut: <?php $search = array ("'<script[^>]*?>.*?</script>'si", // javascript "é", "&egrave", "&ecirc", ../.. ); $replace = array ("", "é", "è", "ê", ../.. ); $text = preg_replace ($search, $replace, $document); ?> Tout ce qu'il te faut, c'est un tableau $search, un tableau $replace, et un appel de fonction. Dans l'exemple, cela supprime aussi tout le javascript. Je te laisse le soin de compléter . Il faut une ligne dans chaque array.... et ces deux lignes doivent correspondre. Dan
  6. Monique, Ca ne change pas le curseur de la souris, mais le texte est cliquable. Je n'ai essayé que sur IE, comme j'étais sur mon portable. Mais je reconnais volontiers que c'est de la "bidouille"... comme je mentionne plus haut (utilisation à contre-courant). Le mieux serait de faire un rollover déporté pur CSS comme expliqué sur le site d'Eric Meyer, à moins que tu ne nous sortes quelque chose de ton chapeau de magicienne A mon avis, garder la compatibilité Netscape 4 est aussi une navigation à contre courant. Si on continue à "bricoler" pour moins d'1% d'irréductibles, on en sera toujours là quand CSS3 sera sorti et supporté par -presque- tout le monde. J'explique en général à mes clients qu'un développement de site compatible NN4 me demande 50% de temps en plus et impose pas mal de limitations sur le plan du rendu visuel, et qu'au final ce temps sera porté sur la facture. Aucun n'a à ce jour jugé ce surcoût utile vu la faible part de marché de NN4. A ce stade là, pourquoi on ne fait pas des sites pour Mosaïc ? Les irréductibles de Netscape ont quelques autres versions plus récentes à se mettre sous la dent... Dan
  7. Salut Raoulmapoule, En mettant la balise <a> de manière à ce qu'elle englobe la balise <tr>, ça fonctionne sur IE. <table> <a href="fichier.htlm"><tr><td>un</td><td>deux</td></tr></a> </table> Par contre, cela ne valide pas, et il faudra essayer avec d'autres navigateurs. C'est une utilisation un peu "à contre-courant W3C". Dan
  8. C'est quand tu veux, on peut s'occuper de toi Plus prosaïquement, tu as parfaitement raison car les besoins en matière de visibilité ne sont pas du tout les mêmes pour des sites pros que pour des sites perso. De plus, les sites pros sont souvent dans des niches concurrentielles dans lesquelles il est difficile de se faire une place au soleil. Regarde les trésors d'ingniosité que les sites adultes doivent déployer pour atteindre la première page de résultats. Il est beaucoup plus simple d'arriver à placer "pique-nique avec tante Angèle" que "bar américain" en première position Dan
  9. Si tu fais une identification, tu dois avoir un cookie sur ton PC qui fait que tu peux accéder à ce menu...
  10. Bonjour gpascal, et bienvenue sur le Hub ! Il est difficile de te donner un avis comme la page qui permet un aperçu - ce que tout le monde voudra avant de s'inscrire - est en erreur 404. Toutes les autres pages de ton site demandent une identification. Dan
  11. Dan

    Weborama

    Olivier, Je te confirme que la toolbar 2.0 est sortie en VF. http://toolbar.google.com/intl/fr/ Dan
  12. Dan

    Paypal

    Bonjour, Juste une précision concernant Paypal. Pour s'inscrire, il faut prouver une identité. Et le numéro de carte sert à ça. Il sert aussi à montrer qu'on n'est pas dans de trop mauvais papiers, car Paypal débite US$ 1.95 de la carte, qu'ils recréditent sur le compte une fois donné le code qui apparaît sur le relevé de carte en regard du débit. Cela prouve à Paypal qu'il a bien le titulaire de la carte en ligne et pas n'importe qui, vu qu'il faut avoir accès au numéro de carte ET au relevé de l'organisme financier. Je trouve ce procédé suffisamment sûr que pour éliminer d'entrée de jeu la plupart des escrocs à la carte de crédit. Les arguments disant qu'on peut payer sans que la marchandise soit expédiée sont à mon avis propres à tout système de paiement en ligne, Paypal ou autre. Les clients qui n'ont pas été livrés par une société de vente en ligne française dont le nom s'apparente au personnage apportant les cadeaux aux enfants en ont fait les frais... et ce n'était pas Paypal. Dan
  13. Anonymus, Il y a une énorme différence en temps d'exécution entre des regex analysées par un script php (interprété) ou les mêmes regex analysées par le module rewrite.c natif d'Apache (écrit en c et compilé). Ton approche est valable pour des sites à trafic faible ou moyen. Mais un site faisant plusieurs millions de pages vues par mois ne peut pas vraiment se permettre ce type de "gaspillage de cpu". Dan
  14. Je lui demandais d'être sympa avec le Hub et de bien nous classer... http://www.google.com/custom?hl=fr&ie=ISO-...rche+Google&lr= MDR - tu m'a donné le bâton pour te battre
  15. C'est balayer un peu vite tous les autres moteur qui, même s'ils sont distancés aujourd'hui, n'en sont pas moribonds pour autant. C'est aussi oublier que quand Microsoft se sera "offert" la technologie et les têtes bien pensantes pour la mettre en place à coups de milliards de US$, les règles du jeu peuvent à nouveau basculer. Ce jour est peut-être plus proche que l'on imagine. C'est quoi 2 ou 3 ans ? Le temps de monter un site "à succès" ? Mais peut-être aussi le temps qu'il faudra à Microsoft pour lancer un pavé dans la mare de Google ? Tous les nouveaux arrivants sur le Web ont oublié qu'à une époque pas si lointaine, l'outil Altavista de Digital Equipment était le leader incontesté du marché de la recherche... attention, le web bouge vite, très vite ! Trop vite peut-être... Dan
  16. Naej/Jean Même à une variable, ça vaut le coup ! Il n'y a aucun doute là dessus. Maintenant, cela vaudra d'autant plus le coup que tu arrives à introduire des mots clés dans l'URL. Pour le site de Jean Pierre (JPS), il est clair qu'une URL du type: http://cartouche.biz/imprimante_CANON_BJC_4400.html est plus intéressante au niveau indexation qu'une URL /imprimante.php?type=1234 (numéro fictif) L'URL n'est pas démesurée et on gagne les mots clés "canon", "bjc" et "4400" qui sont vraisemblablement ceux que les internautes vont entrer dans la recherche. Un internaute entrera par exemple "cartouche imprimante canon bjc 4400" et tous ces mots sont dans l'URL en comptant le domaine. Et de mémoire, le fichier .htaccess avec les règles ne fait même pas 10 lignes. Si en plus tes titres de pages sont bien fichus... tu dois cartonner ! Y a pas photo ! (même avec Canon ) Pour ta page en Flash, difficile à dire sans la voir, mais il est certain que ce n'est pas le plus facile à référencer... si tu as l'occasion d'y mettre un lien, même petit et de préférence .html, au moins les moteurs pourront passer. Cordialement, Dan
  17. Je ne vais pas la mettre en téléchargement ici pour ne pas avoir d'ennuis avec Google, mais j'envoie l'installer en français par email à ceux qui me le demandent par MP. (442Kb) Dan PS (Perle d'Argent et Bzhcool, c'est parti pour vous)
  18. Naej, J'ai pris la liberté de modifier l'intitulé des 2 premières réponses possibles: à la question "pour ou contre" la réponse logique était "pour" ou "contre" et non pas "oui", "non"... j'ai laissé le reste des options en l'état pour ne pas fausser les résultats. Dan
  19. Bonjour JPS (Jean Pierre) Content de voir que le client auquel je faisais allusion s'attribue le label de "webmaster heureux". Je pense qu'on en ferait tous autant après avoir doublé le trafic ciblé d'un site... Je savais que tu étais convaincu de l'utilité de l'URL rewriting mais apprécie que tu aies pris le temps de venir en témoigner ici. Cordialement, Dan
  20. Nissone, Tu trouveras de quoi te documenter là : Mod_rewrite, ou la réécriture des URL "à la volée" La réécriture d'URLs récursive
  21. Bonjour Raoulmapoule et bienvenue sur le Hub ! Ton pseudo me fait toujours sourire, et pourtant on s'est déjà suffisament croisés sur la toile et j'aurais dû m'y habituer. Sur un des forums où il m'arrivait de sévir avant le Hub, j'ai à de maintes reprises mentionné le risque bien réel d'avoir des paramètres nommés "id". Les sources étaient irréfutables (GoogleGuy sur WebmasterWorld) et les correctifs appliqués par ceux à qui j'avais mentionné ce "problème" on fait que les pages se sont retrouvées indexées très vite après le changement du nom de la variable. Il serait très simple de la changer sur ton site et de voir si la page sera indexée suite à ce changement, ce dont personnellement je ne doute pas Cordialement, Dan
  22. Naej, Comme pour toutes les techniques, il y a toujours le risque d'un détournement... Ce n'est pas l'arme qui fait l'assassin, non ? Tous les fondateurs du Hub respectent une éthique et sont profondément anti-spam. J'ai personnellement refusé des clients (à plusieurs reprises) parce qu'ils me demandaient de mettre en place une réécriture d'URLs dont l'idée sous-jacente était le Spam... c'est contre l'idée que je me fais de mon métier. Par contre, pour faire indexer l'intégralité du catalogue d'un site dynamique, l'URL rewriting est "magique" et mérite bien le surnom de "couteau suisse de la manipulation" qui lui est donné sur le site d'Apache. Pour ceux que la réécriture d'URLs intéresse, voici les articles: Mod_rewrite, ou la réécriture des URL "à la volée" La réécriture d'URLs récursive Dan
  23. En tant qu'auteur des articles que beaucoup consultent sur WRI , Spip-contrib, Phpdev, PhpFrance et... le Hub, il me fallait bien répondre "OUI" Dan
  24. Naej, Malheureusement Proxad ne supporte pas l'URL rewriting mais de nombreus hébergeurs offrent des possibilités pour quelques dizaines d'Euros/an... Si les règles sont bien écrites, avec par exemple un "passthrough" pour tout ce qui ne doit pas être réécrit, le ralentissement se chiffre en millisecondes... et reste donc indétectable. D'où l'importance d'une étude préalable correctement menée pour éviter les mauvaises surprises. Dan
  25. Bonjour Naej, et bienvenue sur Le Hub ! Je ne pense sincèrement pas qu'il y ait le moindre risque de blacklistage lors de l'utilisation de l'URL rewriting. En fait, si l'URL rewriting est fait correctement, un visiteur n'a aucun moyen de le détecter (et un moteur non plus). Il n'y a que lors de l'envoi d'entêtes spécifiques telles qu'une redirection permanente 301 qu'il y a évidence de redirection. Et même dans ce cas, la redirection 301 est celle qui est recommandée par Google en cas de changement d'adresse d'une page... donc aucun risque non plus. Le seul risque à mon sens pourrait venir d'une mauvaise implémentation des règles, qui peuvent dans ce cas mettre un serveur "à genoux". Nous avons quelques articles dans la partie publications du Hub qui peuvent t'aider à mettre cela en place... Pour te donner une idée du niveau de résultat qu'on peut obtenir avec une réécriture effectuée correctement, un de mes clients récents avait avant réécriture d'URL une dizaine de pages dans l'index Google, et environ 1000 pages après... Chacune de ses nouvelles pages a un contenu unique et il n'y a donc aucun risque de blacklistage... au contraire. Ce client se reconnaîtra très certainement comme il est membre du Hub. Peut-être témoignera-t-il ici pour te rassurer? Cordialement, Dan
×
×
  • Créer...