Aller au contenu

TheRec

Hubmaster
  • Compteur de contenus

    1 777
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par TheRec

  1. Bonjour, ta recherche initiale est effectuée via un formulaire utilisant la méthode "GET", ainsi les valeurs définie dans ce formulaire sont passée par l'URL, par la querystring c'est-à-dire tout ce qui vient après le premier point d'interrogation dans l'URL. Ainsi tu peux "simuler" la soumission du formulaire en composant ton URL de la même manière que ton navigateur le fait lorsqu'il est soumis par un utilisateur. Le format pour passer une variable GET est le suivant : echo '<p style="font-weight: bold;">Essayez avec cette orthographe :<a href="script_de_recherche.php?query='.urlencode($results->synonyme[0]).'">'.$results->synonyme[0].'</p>'; La fonction urlencode sert à gérer les caractères "spéciaux", si tu souhaite utiliser cette variable par la suite tu peux la passer dans urldecode. Bien sûr l'adresse du lien est à modifier, ainsi que le nom de la variable (query) si nécessaire.
  2. Bonsoir, preg_match_all peut sans autre réaliser ce que tu demandes : $text = "blablablabla {part:debut} blibliblibliblilib {part:milieu}blolbolbolbob {part:fin}"; preg_match_all('/{([^}]+)}/',$text,$matches); print_r($matches); Dans la première cellule (0) du tableau retourné tu auras ce qui as correspondu au masque complet, et dans la deuxième (1), ce qui as correspondu au sous-masque. Bonne continuation.
  3. Bonjour, En fait ton problème de page non trouvée que tu as interprété comme une règle qui n'a pas fonctionné vient du fait que, par défaut, Apache n'autorise pas les "slash" ou "backslash" encodés dans les URL et renvoie une page 404 lorsqu'une telle URL est utilisée. Il existe une directive pour modifier ce comportement : AllowEncodedSlashes On À placer dans ton httpd.conf ou dans la configuration de ton VirtualHost (si tu en as un), cette directive ne fonctionne pas dans un .htaccess et donc suivant ton type d'hébergement ne sera pas modifiable. Concernant urlencode ou rawurlencode, il faut savoir que ces fonctions sont destinése non à des URL complète mais à des données qui sont passées dans l'URL par la querystring. Et effectivement, une autre RFC (malheureusement je ne me souviens plus du numéro) indique que dans la partie "chemin" d'une URI l'encodage est différent et correspond effectivement à un double encodage. J'ai récemment fait l'expérience d'un double encodage de paramètre dans le même cas de figure (slash) et selon mon interprétation, Google semble conserver l'URL décodée (une seule fois) comme référence et donc lors du second passage (non en suivant le lien mais directement avec l'URL mémorisée) détermine que la page n'existe pas car Apache renvoie une erreur 404 (la directive AllowEncodedSlashes étant à Off), donc selon mon expérience le double encodage fonctionne bien pour les utilisateurs, mais lorsqu'il s'agit d'indexer une telle URL on s'expose à ce genre de problème :S Mais si tu peux modifier cette directement cela semble régler le problème sans avoir recours à un double encodage (du moins pour les slash). Elle aura toutefois un effet de bord si tu t'appuye sur le comportement par défaut (page 404 lorsque %2f est utilisé) dans d'autre cas.
  4. Bonjour, Tu as une solution permettant également la cohabitation en utilisant un type MIME Apache particulier. Pour qu'un fichier ne soit pas interprété mais soit affiché avec la coloration syntaxique (si elle est configurée), il faut lui attribuer l'extension .phps et avoir cette ligne dans ton httpd.conf ou un fichier .htaccess : AddType application/x-httpd-php-source .phps
  5. Bon, en retard... mais pour une fois c'est pas à cause du boulot... mais des vacances Joyeux anniversaire le Hub C'est toujours un plaisir renouvelé de venir ici. Même si les tâches de modérations ne sont pas toujours les plus gratifiantes, la communauté est d'une telle qualité que cela ne pose aucun problème et même cela ajoute un peu de motivation dans ces tâches. Donc merci à tous, aux fondateurs, à l'équipe de modération comme au membres assidus et même occasionnels ! Je pense que continuer sur la même lancée pour les 5 prochaines années est loin d'être une mauvaise idée
  6. RedirectPermanent, RedirectMatch comme RewriteRule ne s'occupent pas de la querystring, sauf pour l'ajouter à la fin d'une requête pour RewriteRule, avec le flag QSA ou automatiquement pour toutes les redirections "externes" (toute redirection utilisant une destination commençant par http://. Une solution : RedirectPermanent /region_us http://www.lhotelleriefamiliale.com/? Seule différence, le ? à la fin de l'URL de destination... cela prévient la concaténation de l'URL d'origine. Par contre je ne saurais t'affirmer que le "?" résiduel dans ton URL de destination ne sera pas pris en compte par certains moteurs de recherche.
  7. Une interview très intéressante, merci à tous les participants Il semble que cette pratique ne soit pas très courante en Suisse, les contraintes administratives pour démarrer un activité étant vraiment limitées il devient presque illogique de vouloir donner une partie de son chiffre d'affaire à une société de portage. Mais quand les démarches administratives sont telles qu'elles peuvent facilement mobiliser un employé de bureau chaque jour, j'imagine que cela justifie pleinement un tel service Comme quoi cela a du "bon" de compliquer les choses des fois, cela crée des emplois et des opportunités
  8. Bonsoir, Voilà un exemple... toutes les URL's commençant pas n'importe quel caractère (au moins 1) suivi de ".tonextension" seront réécrites vers le texte qui aura correspondu auquel l'extension .php sera appondue : RewriteEngine On RewriteRule ^(.+)\.tonextension?$ $1.php [L] Bonne continuation.
  9. Bonsoir, Tu peux activer MultiViews qui fait ce que décrit Leonick dans son message (ce n'est pas un comportement spécifique à Apache, c'est le fait d'un module de négociation de contenu de Apache, qui est souvent activé chez les hébergeurs mutualisés) et avec ce comportement tu n'auras plus besoin de mettre d'extension pour les fichiers dans tes URL et ce tant que les types (MIME) de fichiers sont reconnus par Apache. Cela a des inconvénients, surtout lorsque tu commences à multiplier les fichiers ou que par malheur tu as un répertoire qui porte le même nom qu'un fichier (ou plusieurs fichiers avec des extensions différentes), Apache choisira la première occurrence qui correspondra à la recherche et ce ne sera pas forcément celle que tu penses. Pour activer cette fonctionnalité, place la ligne suivante en haut de ton fichier .htaccess : Options +MultiViews Bonne continuation.
  10. Difficile de garantir la fiabilité de l'information de provenance des visiteurs (referer), vu que c'est une en-tête HTTP qui est indiquée par les clients uniquement s'il sont configurés pour le faire. La solution d'un cookie est à privilégier à priori, mais elle n'est pas parfaite non plus (elle présente des inconvénients similaires car rien n'oblige les clients à les accepter)... la solution la plus fiable est selon moi de faire deux pages différentes. Du point de vue de l'ergonomie, toutes les études et les livres récents déconseillent fortement les "pages d'intro" (splash pages, au même titre les "splash" en Javascript) sauf si elle sont totalement indispensables, ce qui est rarement le cas.
  11. Comme tu peux le voir sur le site de Stu Nicholls ça fonctionne, donc il faut suivre à la lettre les explications et te référer à l'exemple. Tu n'as pas parlé de modifier ta feuille de style alors que dans les explications il y a : De plus il y a un peu de Javascript qui est nécessaire pour que cela fonctionne sous Internet Explorer 6 et 7.
  12. Bonjour, Tu peux essayer cette technique : A revised and simplified CSS left flyout menu that works in IE par Stu Nicholls Bonne continuation
  13. TheRec

    REGEX, j'en ch.... !

    Pardon, je ne me référais pas à la trivialité de l'expression rationnelle, mais à la méthode utilisée... je voulais dire qu'il y a sans doute des cas que je n'ai pas prévus, tiens en voilà un, il n'est pas permis de mettre type="css/text' ou type='css/text" et mon expression régulière le permet (enfin c'est pas si grave que cela... à moins qu'il manque un " ou une ' ... dans ce cas la valeur retournée sera erronée
  14. TheRec

    REGEX, j'en ch.... !

    Tester la présence de l'extension .css peut paraître suffisante, mais ce n'est pas le cas. Tu peux utiliser n'importe quelle extension pour ton fichier CSS, du moment que tu spécifie l'attribut "type" de ta balise <link>, donc ton test ne fonctionnerait pas dans tous les cas... et l'expression rationnelle que tu utilises (au passage la constante "REGEX_LINK" n'est définie nulle part dans le code que tu as montré, donc je suppose que tu utilises la constante REGEX_CSS en fait) va récupérer toutes les valeurs qui commencent après href=", qui ne contiennent pas le caractère > et qui finissent avant la séquence />, alors que ce que tu souhaites faire, si j'ai bien compris, c'est récupérer tout ce qui se trouve entres les guillemets doubles ou simples de l'attribut href lorsqu'il est spécifié pour la balise <link> (et pas pour les autres balises, du type <a> ou <base> par exemple). Donc comme l'a dit Kioob, si tu veux limiter ta recherche aux balises <link>, il faut le spécifier à un moment donné dans ton expression rationnelle. Un exemple d'expression rationnelle qui fonctionnerait (si on ne se préoccupe pas de l'attribut type... mais je te conseille de le prendre en compte car l'utilisation de <link> ne se limite pas au feuilles de style) : preg_match_all("/<link.*\shref=[\"'](.+)[\"'].*\/>/iU",$contents,$matches); À noter que pour le support des single (') et double quote ("), j'ai créer deux sous-masques (qui permettent plusieurs alternatives qui seront retournés dans le tableau $matches mais qui ne te servirons pas forcément par la suite... c'est juste la méthode la plus simple qui m'est venue à l'esprit en écrivant ceci, à toi de le faire évoluer L'utilisation de l'option "U" pour le masque, c'est en fait la désactivation du mode gourmand (greedy -> ungreedy), si tu veux plus d'informations à ce sujet : REGEXP multi-lignes en PHP
  15. TheRec

    REGEX, j'en ch.... !

    Bonjour, Et si ton script est destiné à des sources de données variées, sur lesquelles tu n'as pas de contrôle cela va devenir plus compliqué également, parce qu'(x)HTML est assez souple au niveau de l'ordre des attributs, des séparateurs (single quote et double quote). Pour l'ordre des attributs cela revêt une importance car si tu veux récupérer toutes les URL (relatives et absolues) de toutes les balises <link> qui concernes les feuilles de style tu vas devoir vérifier que l'attribut type à bien la valeur "text/css". Il se peut que chercher une seule expression rationnelle pour régler ces problèmes soit plus compliqué que se résoudre à le faire en deux fois par exemple: Extraction des <link> ayant type="text/css" ou type='text/css'. Extraction des URL de chacun de ces éléments (de nouveau en prenant en considération les différents séparateurs. Bonne continuation.
  16. Bonjour, Je pense que karanabal fait référence à thickbox concernant le "popup inline" pouvant accueillir plus que de simples images
  17. Très bonne interview (comme à ton habitude Arlette ), très instructive. Merci à tous les participants
  18. Tout à fait d'accord, un redirection permanente du domaines de moindre importance vers le domaine principal serait plus judicieuse. Mais vu la volonté de Gregory de séparer également les statistiques de ces deux domaines je me suis dit qu'il désirait réellement avoir deux site séparés mais identiques, malgré les risques qui en découlent au niveau du référencement.
  19. Non, tu peux le faire directement en PHP (je ne connais pas le CMS que tu utilise mais s'il y a un système de templates, peut-être peux-tu insérer un code dans le genre : if ($_SERVER['HTTP_HOST'] == 'www.nom-de-domaine.com') { echo "<script type\"text/javascript\">_uact = \"UA-xxxxxxx-xxx\";\n urchinTracker();</script>"; } elseif ($_SERVER['HTTP_HOST'] == 'www.nom-de-domaine.org') { echo "<script type\"text/javascript\">_uact = \"UA-xxxxxxx-yyy\";\n urchinTracker();</script>"; } Cela se placerai comme actuellement, à la fin de ton <body> après l'inclusion du fichier de Google Analytics. Pour l'inclusion de la Google Maps tu aurais une condition similaire, mais dans ton en-tête xHTML (<head>). Hé non... au moment de mon post c'était bien la 1.2.4... les versions pleuvent ces derniers jours
  20. Il y a également une pratique que j'éviterai à ta place, cela concerne ta fonction "include", qui sert à ajouter le script de Google Maps (en fonction du domaine), tu utilises un document.write à cet endroit, certes c'est plus "facile" mais cela a un impact sur le changement de la page et si d'aventure tu viens à servir ta page XHTML en tant que application/xhtml+xml c'est fortement déconseillé pour XHTML 1.0 et totaltement proscrit en XHTML 1.1, donc autant s'y mettre tout de suite et utiliser le DOM comme tu le fais pour Google Analytics. Ou encore mieux, comme tu sembles utiliser un langage interprété côté serveur (PHP), tu peux faire l'inclusion du bon code (pour Google Maps et Google Analytics) en fonction de la variable $_SERVER['HTTP_HOST'].
  21. Le problème se situe sans doute dans le fait que tu appelles ta fonction load (pour la carte Google Maps) directement dans le corps de ta page xHTML (<body>) et non dans l'en-tête (<head>)... essaie de l'appeler à l'événement docready (comme ta fonction pour inclure le code Google Analytics) ... ou au pire à l'événement load, mais à priori il n'y a pas de contre indication à le faire dès que le DOM est prêt. Du moins le problème n'existe que sur la page où tu effectue ce chargement de la Google Maps, pas d'erreur sur les autres sous IE. P.S. : Pardon pour la "fausse" piste de docready, mais en même temps pourquoi attendre le load si tu n'agit pas sur des images
  22. Bonjour, À priori, c'est un problème assez classique de Internet Explorer, lorsque les éléments n'ont pas encore tous été parcourus par le parseur DOM, ils ne sont pas disponibles. Je te conseille de changer la ligne : window.addEvent('load',function() { en window.addEvent('domready',function() { dans ton fichier /js/mqs.js Ainsi l'événement sera appelé dès que le parseur DOM aura redonné la main au moteur de rendu des navigateurs. Pour information, sous jQuery (dont la version 1.2.4 vient de sortir), l'équivalent est la méthode "ready" qu'on applique à l'objet document (ce qui sémantiquement est plus juste) Bonne continuation.
  23. Bonjour, Tu ne suis pas captain_torche, il ne veut pas donner la/les URL, c'est bien ce qui fait penser à certains qu'il s'agit d'un cas fictif Que ce soit le cas ou non cela ne change rien. Tout à été dit, si ton activité se déroule en France (même partiellement) et que tu perçois ces revenus en France, ils sont soumis à l'impôt (à moins d'une exonération exceptionnelle dont tu n'aurais pas parlé). Tout autre solution pour ne pas payer ou payer moins d'impôts, dans la situation actuelle (micro), s'appelle de la fraude fiscale et c'est punissable selon la loi, que ce soit la non-déclaration, l'évasion (et il y a des conditions particulière à remplir, un simple compte suffit rarement) ou autres pratiques. Maintenant tu es conscient de ces faits, libre à toi de tirer les conclusions qui s'imposent, personne ne peut déclarer tes revenus à ta place (à part tes parents pour la période ou ils étaient tes représentants légaux), mais tôt ou tard, statistiquement, l'administration constatera ton train de vie. Elle ne se gênera pas tirer ces conclusions à ta place, tu auras le droit à un contrôle fiscal et vraisemblablement un redressement (y compris une amende je suppose)... et tes parents pourraient facilement être englobés dans ce contrôle. Que cette situation t'arrange ou non n'a pas vraiment d'importance, que tu la trouves juste ou non, pas plus (d'où l'inutilité de chercher à le convaincre du bien fondé des impôts, pour ceux dans le fond qui chercheraient encore à le faire ), la loi est la même pour tous. Je ne sais pas comment cela se passe en France, mais en Suisse, sur décision des autorités exécutives, il y peut y avoir une amnistie fiscale (la dernière date de 1969) et à cette occasion il est possible de déclarer des revenus qu'on a "oublié" lors des précédentes déclaration sans risque de représailles mais bien entendu on se retrouve taxé, normalement, sur ces revenus... mais attendre sur un tel événement est risqué car à tout moment on peut se faire contrôler. Si j'ai bonne mémoire, de mes lectures (car je n'étais pas né), la dernière amnistie à permis à l'État de faire "ressortir" quelques 11 milliards de francs suisses
  24. Bonsoir, Je pense que cela vaut la peine, voyant que Google met en évidence dans ses résultats les mots recherchés lorsqu'ils sont présents dans l'URL. Et généralemment cette fonctionnalité existe pour tous les CMS (par exemple) et est généralement justifié pour l'optimisation du référencement J'ajouterai que rien ne t'empêche de vérifier la partie "mots-clés" de ton URL en fonction de l'ID utilisé. Si les mots clés ne sont pas corrects (par rapport aux informations de la page en question, à toi de voir comment tu as généré cette liste de mots-clés, soit un champs dédié, soit à partir du titre) tu retournes une erreur 404, même si l'ID existe bien c'est la preuve que l'URL utilisée n'est pas celle prévue pour accéder à ce contenu. Il est clair que si tu n'effectue pas une telle vérification, tu as le risque de voir des URL non désirées être utilisées soit par erreur voire éventuellement pour te nuire et effectivement un moteur de recherche estimera que ces pages sont des doublons de la page d'origine.
×
×
  • Créer...