jpv

Tu te rends comptes de ce que tu dis là ? Tu proposes un système de spamindexing, donc malhonnête, qui tiens sur l'honnêteté de ses utilisateurs... Et peut importe que la malhonnêteté soit "limite"," acceptable", "usuelle" ou je ne sais quoi d'autre. En fait tu viens d'inventer un nouveau concept : "tricher honnêtement". De toi à moi : Ya pas comme un soucis dans la démarche ??? Ha si, je comprends parfaitement le projet : créer artificiellement de faux backlinks destinés à tromper les moteurs en vue d'apparaitre en première position (dixit toi même pour l'objectif final). Ecoutes, honêtement, je crains que ceux qui vivent du spamindexing ne soient pas très effrayés. Content que tu ai trouvé ce débat "passionnant", pour moi il est un peut décevant en ce que je n'ai visiblement pas réussi à te convaincre que ton outil ne fait que faire perdre du temps à tous ceux qui essaient de rendre le web un peut moins pire. Ceci dit, fait quand-même attention, que des gens mal intentionnés, ou des apprentis dark-vador (c'est eux les pires) ne tombent pas trop vite sur ton système parce qu'en l'état il est ouvert à tous vents et tu pourrais t'en mordre les doigts. jp PS : juste une dernière chose que je ne parviens pas à raisonner : imaginons que ton système ai du succès, tu vas te retrouver avec un nombre considérable de pages indéxées par le smoteurs. Comme tu le sais, au delà d'un certain volume d'indexation, une petite visite de la cavalerie est garantie, surtout si les milliers de liens pointent vers l'extérieur. A ton avis, comment vont-ils réagir les gars des moteurs en tombant sur ton système ? Toute la difficulté des faux backlinks est justement de les disperser sur des domaines et serveur différents, là tu concentre tout sur le tiens de serveur, ce qui en passant apparente plus ton système à une bête farmlink qu'à autre chose. Ca ne t'inquiètes pas ?

C'est indéfendable ta position là, tu créé un outil destiné à pourrir les moteurs, une moulinette à spamindexing tu à au minimum la responsabilité morale de l'avoir fait. Je ne vois rien dans mes propos qui permette de croire que je pratique ce genre de faisanderie, t'as pas bien compris le sens de mon intervention. il faut me lire au premier degré : Ca me révolte. c'est tout. Pour être encore plus clair, sur la centaine de site que j'ai développé (je suis développeur pas référenceur dieu merci) je ne l'ai jamais fait, jusqu'à démissionner de boites qui voulais le faire (incroyable non ?), si tu ne me crois pas c'est que tu es déjà du coté obscur de la force :) Mais enfin, faut arrêter avec cet argument, le monde entier est remplis d'imbéciles, ça ne te donnes pas l'autorisation d'être comme eux, avoue que ce serait dommage Imaginons une petite fable ensemble : Imaginons que ton système soit mal fait, avec une absense totale de la moindre sécurisation du formulaire et qu'en conséquence il soit possible de créer n'importe quoi. Par exemple, imaginons deux failles basiques (à ce niveau là ce ne sont plus des failles d'ailleurs) par exemple que l'adresse email ne soit pas vérifiée, qu'il n'y ait aucun moyen de vérifier que l'url est bien celle de l'utilisateur et qu'en outre d'autres vérification basique ne soit pas implémentés (celle là je les donnes pas hein). D'ailleurs à tu seulement pensé à ça ?, je suis sérieux là, ton système à un défaut de conception, comment vérifier qu'un utilisateur ne rentres pas l'url d'un site concurrent aux fins de google bombing ? Comment vas tu gérer les mots clés saisis ? puisqu'on peut rentrer n'importe quoi, tu sais tous ces mots difficilements acceptables qui commence par P, A, S, D ??? Comment vas tu gérer ces cas là ?, je crains qu'il ne te failles prévoir de longues, longues soirées de modération, ou d'investir dans la mise au point de filtres bayesiens en priant le ciel pour qu'ils soient à la hauteur. Continuons ma petite fable : Imaginons en outre que je n'ai pas grand chose à faire cette nuit, et qu'il ne me failles que quelques minutes pour monter une petite moulinette qui inscrive et créé de facto environ cent nouvelles entrées dans ton système, disons toutes les deux minutes pour ne pas affoler ton serveur. J'aurais reproduis, à ton niveau, exactement ce que tu fais vis à vis des moteurs. La question : demain matin, avec environ 30 000 nouvelles entrées bidons (pour commencer) remplis de mots clés inutiles et pointant vers ton url, peux tu me dire quel serait exactement ton sentiment ? Je te rassures, je n'ai ouvert que deux sites bidons à la main, trucbidule et trucbidule2 qui pointe vers ton url, et je m'arrêterais là. Je vais aussi quitter ce post, parce que tu viens de me convaincre d'une chose : je perds mon temps. JP Ps: bon courage pour la suite.

Les pages satellites un truc d'initié ? tu rigoles ?, même le plus nul des newbies connait la technique répétés mille fois partout. Ben là t'à tout bon, voila la moulinette à pages pages satellites du pauvre... Et alors ?, ça te donne quel droit de faire pareil ?, j'aimerais voir ta réaction si je viens te braquer chez toi au prétexte que "d'autres le font", c'est du n'importe quoi, ou alors t'affiches la couleur et tu dis " je vous propose un outil de spamindexing ", là ce sera courageux, puéril, mais courageux. Concerné n'est pas vraiment le mot, consterné est plus proche du fond de ma pensée, particulièrement par ce genre de choses : Où il faudrait m'expliquer quel est le rapport entre orditruc, dommachin et forumbidule entre eux et ton site. Remarque, je n'ai peu-être pas bien saisi non plus la notion d'échanges de liens Ben non, le pire c'est c'est de diffuser ce genre d'outils, faut pas chercher plus loin. Sans vouloir être trop aggressif, c'est comme la remballe dans les supermarchés, ça existe, yen à qui le font parceque "d'autres le font" ça empêche pas que c'est dégueulasse. Bon, allez j'arrête de spammer ton post, tiens c'est vrai ça, je pourrais spammer ton post, le pourrir de commentaires inutiles, tu tiendrais combien de temps avant de demander l'intervention d'un modo.. ? JP

Bon, allez y'en faut au moins un, je me dévoue. Vous en avez pas marre de pourrir les bases des moteurs ? Tu dis que ton nouveau-système est apprécié des moteurs, on croit rêver, il est pour le moment simplement ignoré, le jour où ce ne sera plus le cas il vous arrivera ce qui est arrivé récemment à cette socitété de référencement qui utilisait ta "technique révolutionnaire" : Leur site à été désindéxé, c'est bien fait pour eux, et tous leurs clients aussi, là c'est beaucoup, beaucoup plus grave, car ça les classe direct dans la catégorie "escrocs" et "abus de confiance". A chaque nouvelle invention, basée sur la duperie et le détournement vous alimentez le champs de ruines du référencement, que vous transformez en une sorte de compétition infernale à celui qui aura l'honneur et la gloire du titre de "plus grand arnaqueur du web". Il arrivera à ton nouveau-système-vieux-comme-le-web, ce qui est arrivé avec les farmlinks et les annuaires bidons (en passant, gros nettoyage lors de la dernière dance) : direction poubelle, d'où il n'aurait jamais du sortir. Et comme cela reviens à dire, grosso modo, "aller vous faire ...", à tous ceux qui essaient de faire un job honnête, tu me permettras, en leur nom à tous de te retourner le compliment. JP Ps: Et je t'encourage vivement à diffuser largement ton "produit", plus il va être vite utilisé, moins ça va durer, ça en fera un de moins, ce sera toujours ça de gagné.

Bonjour, Il existes de bonnes librairies pour gérer la compression zip avec PhP. En voici une parmis d'autres qui s'avère robuste et simple : PhP Concpet - Pclzip JP

Autrement dit, le javascript assure 2 fois plus de travail Oui et non Dans le cas d'un controle de fomulaire c'est quand même plus "pratique" de controler les champs avec javascript que d'imposer un aller retour serveur. Sur ce genre de cas le surcroit de travail n'est pas énorme, ce sont souvent des procédés qui peuvent être généralisés. Il est par exemple très simple de développer une pseudo classe JS de contrôle d'élements de formulaire qui ne nécessite aucune adaptation et peut prendre en charge des cas multiples (valeur requise, controle de type, de longueur, de caractère interdis...). Il ne s'agit en aucun cas d'une "validation" qui est réservé au traitement applicatif lui-même mais simplement d'un "filtre" qui permet d'éviter l'aller-retour serveur dans la plupart des cas "simples". Autre cas : La sélection multiple d'items de listes de résultats, où les solutions classiques sont généralement assez lourdes : fondé sur GET on impose un rechargement de page à chaque sélection et en utilisant POST on impose la gestion d'une multitude de champs de formulaires. Dans les deux cas l'utilisabilité est médiocre et l'implémentation d'un procédé scripté, bien fait et testé "en situation" apporte une plus-value non négligeable. En revanche il est vrai que pour des procédés plus complexes cela nécessite souvent de doubler le travail, mais bon, dans la perspective d'une meilleure ergonomie, d'une meilleur utilisabilité et d'une meilleure accessibilité, cela ce justifie pleinement. JP

Bonjour, Maintenant, s'il faut faire du "javascriptless" parce que les lecteurs vocaux ne savent pas les suivrent Ce n'est pas tout à fait juste. Les lecteurs d'écrans comme jaws, window eyes... et les navigateurs vocaux comme Home page reader, fonctionnent comme une surcouche comme l'à précisé Ganf. Si l'API du navigateur sait intérpréter javascript et si il est activé tous les scripts et fonctionnalités scriptées seront utilisables. En revanche des problèmes d'ergonomie et d'utilisabilité peuvent se présenter et il est toujours necessaire de tester la situation que créé une fonctionnalité scriptée particulièrement pour des traitements atypiques. Dans certains cas, un traitement bien fait peut être facteur d'une meilleure accessibilité. Pour reprendre l'exemple du controle de formulaire, c'est toujours profitable de doubler le traitement serveur par un pré-controle javascripté qui en évitant un rechargement de page augmentera sensiblement l'utilisabilité et l'accessibilité du formulaire. Même remarque avec l'utilisation de XMLHttpRequest (AJAX) qui peut rendre de grands services. De même il n'y à pas à autocensurer des effets scriptés à destination du design si tant est qu'on prenne soin de vérifier qu'ils ne gênent pas. Les bonnes questions à se poser avant de décider de l'implémentation d'une fonctionnalité scriptés ne concernent pas le support client ou l'utilité, elles concernent l'ergonomie, la méthode et les alternatives. L'ergonomie et l'alternative sont les deux points essentiels d'un dispositif javascript car cela te forcera à une analyse réelle du processus. En terme d'ergonomie tu dois t'assurer que le dispositif scripté demeure fonctionnel et produit le résultat attendu dans toutes les situations problématiques, notamment pour les handicaps visuels, moteurs et cognitifs. Un exemple très simple : un menu déroulant qui n'est implémenté que sur les seuls events souris deviens rédhibitoire pour ceux qui navigue au clavier, il faut donc doubler tous les events souris de leur équivalents claviers (onfocus et/ou onkey...) par exemple. En terme d'alternative, tu dois t'assurer que la fonctionnalité prise en charge par javascript possède une alternative crédible, efficace et de même nature en terme de logique applicative, ou ce qui reviens au même, que l'absence d'alternative ne constitue pas un problème. Un exemple très simple : Un diaporama javascripté (images défilantes) où il n'y à pas d'alternative crédible est parfaitement utilisable si tu assures d'y adjoindre des vignettes fixes permettant d'accéder manuellement aux images. Si tu respectes ces principes, ainsi que des méthodes sures : écriture normalisée, externalisation des scripts, utilisation du DOM ou encore la limitation, autant que faire se peut, des attributs d'evenements (onclick=fonction()) introduite dans le corps HTML au profit d'une affectation au chargement de la page, tu auras résolu l'immense majorité des problèmes. Du coup le support ou non de javacsript n'est pas un problème car tu te dois d'assurer une alternative, et si le problème demeure c'est que ton procédé est mal conçus et qu'il faut le refaire. JP

Bonjour, Le warning de bobby viens du fait que tes liens sont entourés d'espace insécables, il l'interprète comme une tentative de séparation de lien adjacent et t'indique que l'espace insécable est innoportun pour cet usage Tu peux l'ignorer, en revanche tu gagnerais à center tes liens au lieu de les formater avec l'espace insécable. JP

Tout à fais d'accord, c'est justement parce que le contexte et la logique applicative s'y pretent que j'en ai profité pour faire cette expérience. En revanche je n'avais pas pensé à la répercussion de l'utilisation de session dans le cadre de processus parallèles (hors sujet dans ce projet mais merci pour la piste, je vais y réfléchir.) Merci en tout cas de la richesse de tes réponses. JP

Merci des liens, Le web est plein d'utopies qui ne tiennent que sur la bonne foi des uns et des autres. Celle là était intéressante mais tu à raison, à peine née déjà détournée, comme tant d'autres (qui à pensé au référencement ?) Pour en revenir au fil, le hasard fait que je suis plongé dans cette problématique sur mon dev actuel, (c'est la raison pour laquelle j'ai envahis ce fil ) Toute la gestion utilisateur est monté sur une session, il n'y à rien de critique, ce sont des process simples de navigation, tri, recherche, consultation. Cela faisais longtemps que je voulais tester une conception de ce genre sur des front-end et cette appli s'y prete à merveille, justement parce qu'il n'y à rien de critique. Le confort de développement, de maintenance, la simplification extrème du code sont tellement profitables que la méthode classique par GET-Url-a-rallonge ou la surcharge de POST dans des séquencages de formulaires me semble du coup cauchemardesque. Le soucis, évidemment, c'est que pas de cookie de session, pas de site Du coup j'ai implémenté le passage manuel de SID par l'url pour résoudre ce conflit hors crawler et bestioles en tout genres. Si j'ai bien compris le sens de ta réflexion, ce n'est pas vraiment une bonne idée et je devrais remplacer la béquille par un joli disclaimer au sujet de l'utilisation des cookies sur ce site, ou pour aller au bout du raisonnement laisser le power_user maitre de sa décision ? C'est évidemment assez théorique car, comme tu le fais remarquer, la désactivation des cookies est relativement rare et que dans le cas de ce dev le vol de session n'à strictement aucune importance.. Dernières questions, purement techniques celles-là: - use_only_cookies ON rendrait l'implémentation manuelle de SID innopérante ? - c'est accessible par ini_set ? (Je suppose que non mais j'ai pas eu le temps de tester, je suis en recettage ). JP

Non, évidemment Mais les sessions sont un moyen pratique de gestion des actions utilisateurs. Pour des applications critiques, boutiques, login, panier... il est évident qu'interdire de passer la session dans l'url est une bonne idée. En revanche, pour des gestions utilisateurs simples, comme par exemple d'utiliser une session pour stocker des valeurs de recherche ou simplifier une navigation de liste de résultat, le passage par l'url ne pose aucun problème. Dans ce cas là, l'interdiction semble contre productive. J'ai lu avec beaucoup d'intérêt tes deux articles, aurais tu un lien plus "pédagogique" vers la déclaration P3P qui sur celui que tu donnes, à la mode "MS-maitre du monde" est particulièrement difficile à comprendre ? Jp Ps: en passant félicitations pour PhP 5 avancé, dans le genre c un must

Bonjour, Juste une petite question Dans ce cas là, comment traiter le cas des visiteurs qui ont désactivés le support des cookies ? JP

Bonjour, Même avec le pop-up il suffira de faire ALT+fleche pour parcourir l'historique. En revanche, si il n'est pas possible de controler l'historique de navigation (et encore heureux), il est tout à fait possible de conditionner l'affichage d'élément de pages avec un cookie ou une session. Dans le cas d'un QCM par exemple il est tout à fait possible, et très souhaitable pour le sérieux de la chose, de bloquer des champs de formulaires en saisie après réponse. jp

Bonjour, Désolé de t'avoir offensé Klouchi, ce n'était pas mon intention. C'était juste une réaction épidermique face au "pas vu pas pris" et la fraude permanente voire organisé en concours (cf le concours du meilleur spam-indexing en cours) qui prévaut dans ce domaine. Mille excuses JP

Ou utiliser, de manière détournée, la balise noscript et la remplir de mots clés... Klouchi, moi à ta place j'aurais pas osé quand même. Quelle est vraiment l'utilité de tout ça ??? Cloaking, dissimulation de mots clés, détournement de balisage, farmlink... Ha... que voilà une grande iddée du référencement... JP Ps: quand vous allez faire vos courses vous changez les étiquettes de prix ou vous mettez directement le cd sous votre tee-shirt ?