TheRec

Il y a peu de risque que ta fonction telle qu'elle est écrite ici fonctionne : Source: MySQL 5.0 Reference Manual - 9.2.3 Function Name Parsing and Resolution Bref, il ne faut pas mettre d'espace entre le nom de ta fonction (COUNT) et la parenthèse (à moins d'avoir activé l'option IGNORE_SPACE sur ton serveur MySQL, mais je t'avoue que j'ai découvert cette fonction en cherchant une solution à ton problème, donc je ne connais pas toutes les implications qu'a cette option).

D'accord... et la deuxième partie dont je te parle dans mon précédent message ? mysql_error te donnera l'erreur générée par MySQL, car en fait l'erreur que tu viens de nous donner est là parce que la requête SQL est erronée.

L'idéal serait de nous donner l'erreur en question Ainsi que ce qu'affiche la ligne, si tu l'exécutes juste après avoir exécuté ta requête grâce à la fonction mysql_query : echo mysql_errno().": ".mysql_error();

Oui, effectivement il manquait un parenthèse, je t'avoue avoir écrit ceci à la volée sans l'avoir testé, pardon. Et oui tu noteras que je n'ai pas utilisé la variable $_HTTP_COOKIE_VARS, à la place j'ai utilisé $_COOKIE, idem pour $HTTP_SERVER_VARS qui est remplacé par $_SERVER. Ces variables $_HTTP_*_VARS ne sont pas dépréciées pour le moment, elle sont juste déconseillée parce que dans le futur elles disparaîtront certainement au profit des autres, donc autant ne plus les utiliser, ainsi la durée de vie de ton code est plus longue.

Relis le message de Jan, il te dit de tester (avec if) la variable $lang au lieu de $_GET['lang'] (toi en l'occurrence dans ton dernier message tu test $_HTTP_COOKIE_VARS['lang'], alors que je viens de te dire qu'il n'était pas conseillé d'utiliser les variable $HTTP_*_VARS, enfin tu fais comme tu veux ). Cela ne peut être plus clair. Sinon si tu veux prendre en compte le paramètre GET intitulé "lang" pour qu'il prime par rapport au cookie ou à la langue du navigateur tu peux faire ainsi : <?php if(isset($_GET['lang'])) { $lang = $_GET['lang']; } elseif(isset($_COOKIE['lang'])) { $lang = $_COOKIE['lang']; } else { $lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'],0,2); } if($lang=='fr') { include('fr/headerfr.php'); } elseif($lang=='en') { include('en/headeren.php'); } else { include('fr/headerfr.php'); } $expire = 365*24*3600; setcookie("lang", $lang, time() + $expire); ?>

Bonjour, mysql_query te renvoie un ressource (lorsqu'il s'agit d'une requête SELECT) que tu peux exploiter afin d'en extraire les résultats de ta requête avec des fonctions comme mysql_result, mysql_fetch_array, mysql_ fetch_ field, etc. Dans ton cas tu n'a pas besoin d'initialiser un tableau ou de rechercher un champ bien précis vu qu'il n'y a qu'un champ. Donc tu peux le faire avec mysql_result : echo mysql_result($compteur,0); Le "0" correspond à la position de la colonne, la première étant 0 (et non 1).

Bonjour, Jan a vraisemblablement raison, j'ajoute qu'il serait bon de ne plus utiliser les tableaux prédéfinis $HTTP_*_VARS (qui dates de versions de PHP antérieures à 4.1.0), mais d'utiliser les tableaux super-globaux $_SERVER, $_COOKIE, $_GET, $_POST, etc. Pour l'instant les tableaux prédéfinis $HTTP_*_VARS sont encore disponible pour des raisons de compatibilité, mais je jour où ton application sera utilisée sur un version où ces tableaux ne le sont plus tu devras récrire tout ou partie de ton code

Oui, effectivement ce que je te proposait ne fonctionne pas, je me suis trompé. La solution que tu propose me semble être la seule solution viable.

Bonsoir, Lorsque tu fais une redirection permanente, d'une source précise (sans devoir recourir à une expression régulière) à une destination connue, tu peux simplement utiliser RedirectPermanent : RedirectPermanent /visuel_approche_globale_commerciale_et_marketing.htm http://destination.com/approche-globale-marketing-commerciale.php C'est plus "court" et surtout cela ne fait pas appel au moteur d'expression régulières. Ensuite concernant ton problème de RedirectMatch, le moteur de redirection ajoute automatiquement la QueryString (paramètres GET : ?var1=valeur1&var2=valeur2 etc.) de l'URL source à l'URL de destination. À ma connaissance il n'est pas possible de corriger cela. Pour la réécriture d'URL par contre, tant que le flag QSA (QueryString Append) n'est pas activé la QueryString n'est pas ajoutée à la fin de l'URL de destination. Donc tu pourrais faire ceci ainsi : RewriteEngine On RewriteRule ^/fiche_reference\.htm$ /references.php [R=301] Avec ceci tu tires partie du comportement par défaut de RewriteRule, sans le flag QSA la QueryString ne sera pas transmise de l'URL source vers l'URL de destination. R=301 transforme la réécriture en redirection permanente. (À toi de voir si tu as besoin des "/" au début de la source et de la destination, cela dépend de la configuration du serveur). Bonne continuation.

De rien, je suis content que tu aies trouvé ton bonheur, mais si ce site que tu as trouvé est accessible (gratuitement) peux-tu nous en communiquer l'adresse, cela permettra à d'autres de trouver réponses à leurs questions lors de recherches sur le forum Merci d'avance.

Bonjour, Sans répondre directement à ta question, je tiens juste a t'informer qu'il est possible de faire ceci en CSS sans JavaScript (ou avec une "pointe" de JavaScript pour achever les effets créées en CSS) et surtout cela permettera aux moteur de pouvoir utiliser tous les niveaux de ton menu. Voici une démonstration : Simple drop line menu Ensuite pour remplacer le texte de chaque élément par des images il y a beaucoup de solution à ta disposition également en CSS.

Bonjour, Prototype permet de faire ceci simplement grâce à la fonction "update". Pour vider un élément il suffit de l'appeler sans paramètre, dans ton cas : function vide(element) { $(element).update(); } Si tu souhaite directement remplacer le contenu je te laisse lire la page "update" de l'API de Prototype. Bonne continuation

Une simple redirection à la soumission de ton formulaire fera l'affaire je pense. Lorsque ton formulaire est soumis, l'envoie se fait vers la page "www.mondom.com/cherche.php?q=tutu" dans cette page correspondant au traitement tu peux simplement effectuer une redirection : <?php header("HTTP/1.1 301 Moved Permanently"); header("Location: http://www.mondom.com/".$_GET['q']."/"); exit(); ?> Il faut exécuter ceci avant tout autre envoi de caractères vers le navigateur (au tout début de ton fichier). Ensuite tu gères ta réécriture comme tu l'aurais fait si l'utilisateur avait directement tapé l'URL -http://www.mondom.com/tutu/ . Bien entendu si tu veux utiliser uniquement un fichier PHP (cherche.php) pour effectuer cette redirection et la recherche tu peux simplement rajouter un paramètre supplémentaire lorsque fais la réécriture sur lequel tu feras un test conditionnel (if) pour déterminer s'il faut faire la redirection avec header (pour effectuer ensuite la réécriture) ou faut effectuer la recherche et envoyer les résultats (parce que l'utilisateur vient d'être redirigé vers l'URL réécrite). Ou alors tu fais deux fichiers distincts, un pour la redirection avec header vers l'URL réécrite et un pour effectuer la recherche (qui sera la cible de ta réécriture). J'ai essayé de te décrire le fonctionnement complet, j'espère que je ne t'ai pas trop embrouillé

Effectivement, pour couper ce service il doit s'en être réservé le droit avant de conclure la vente, cela découlait de source pour moi mais il est bon de le préciser.

Ah, donc si tu ne paies plus ton assurance par exemple, quand il t'arrive un accident il doivent te couvrir sous prétexte qu'ils ne doivent pas se faire justice eux-mêmes ? J'ai comme un doute, en tous cas en Suisse cela ne se passe pas ainsi. Lorsqu'un client ne paie pas un service, il ne peut pas en profiter. La loi et la tradition française en matière de commerce étant différente en certains points je ne vais pas m'avancer et garantir que ce que je viens de dire s'applique en France. Enfin, lorsque la situation est inversée, par exemple un locataire arrêtant de payer son loyer la règle dont tu parles s'applique, le dernier n'a pas le droit d'arrêter de payer tant qu'il profite du bien loué selon les termes du contrat.

Bonjour, Dadou> Tout dépend de la nature de site, s'il utilise une technologie serveur pour générer des pages avec un contenu dynamique il ne pourra absolument pas récupérer leur code source. Tout ce qu'il récupérera ça sera la sortie ((x)HTML, CSS, etc.) des scripts utilisés. Mais effectivement il pourra récupérer la charte graphique par exemple et tant qu'il n'a pas besoin de modifier le site en apparence il aura un site fonctionnel (à condition que les systèmes ne dépendent pas absolument de la technologie serveur : envoi de courriels, etc.). Par contre, si le site est composé de pages "statiques" uniquement, effectivement un simple aspirateur de site suffira à priver Jerome38 de son levier de négociation et peut-être même de tout espoir d'obtenir un paiement. Je ne peux que rejoindre les autres, si, après les sommations d'usage (lettre recommandée) notifiant les conséquence d'un non-paiement, ton client ne montre pas de bonne foi, tu pourras couper le service jusqu'à régularisation de la situation. Je n'apporte pas plus d'informations que les autres (même moins à lire certaines réponses), mais il faut de la fermeté également lorsqu'il s'agit de défendre ta source de revenus. Un client est par définition une personne recevant des biens commerciaux ou des services contre paiement ! Bonne chance et bon courage pour la suite.

Bonjour, Essaie de placer cette ligne : header("Cache-control: private"); Juste après ton session_start();, cela permet d'instaurer un cache "privé" par rapport à la session, et les données des formulaires seront gardées en cache également, pour peu que le navigateur propose cette fonctionnalité évidemment. Bonne continuation.

Bonjour, Fondamentalement tu ne peux pas envoyer des données à quelqu'un et l'empêcher de les stocker. Donc même si tu empêches les gens de mettre en cache une vidéo (en modifiant les paramètres de cache sur le serveur je suppose), tu ne peux pas les empêcher de capturer le flux de données et de l'enregistrer dans un fichier. C'est le même principe de les gens voulant empêcher de télécharger des images sur un site, toutes les tentatives de protection peuvent être contournées. La seule fonctionnant est de ne pas mettre en ligne le contenu et l'envoyer seulement aux personne autorisées, dans ton cas ce n'est pas l'application que tu comptes en faire apparemment. En partant de ce postulat, non JavaScript ne te sera d'aucune aide.

Sans problème Effectivement, à ma connaissance tu ne trouvera pas d'autre solution "fiable" pour faire exactement ce que tu souhaite, l'en-tête que tu envoies pour indiquer qu'il y a redirection est locale au serveur l'émettant (le serveur source), une fois la redirection effectuée, l'en-tête renvoyée par le serveur cible sera à priori un statut "200" (OK), si tout c'est bien déroulé. Désolé de ne pas pouvoir te fournir une solution, selon mon expérience tu touches au limites de HTTP et en fait ce n'est pas un mal, car si ce que tu souhaites faire était possible cela représenterait un moyen de tracking supplémentaire pouvant sérieusement nuire à la vie privée. Si c'était faisable on pourrait théoriquement reconstituer le parcours d'un utilisateur de site en site sans être son fournisseur internet.

C'est ce que je m'évertue à te dire, la page &quot;http://www.urlcible.com?r=1" redirigera vers ta page de destination sans le ?r=1. Par exemple en PHP te ferais ainsi au tout début de la page de destination : <?php if($_GET['r']) { header('HTTP/1.1 301 Moved Permanently'); header('Location: http://www.urlcible.com'); exit(); } // Le reste de ta page cible sera en dessous dans le cas, ainsi si ?r=1 n'a pas été défini dans l'URL la page se charge normalement Les moteurs de recherche suivent cette redirection et n'indexent que la page en fin de redirection... sinon comme tu le dis les gens pourraient pourrir l'index (enfin, à priori les moteur de recherchent préviennent cela et c'est aussi du devoir du programmeur d'y penser en renvoyant une erreur HTTP 404 lorsqu'une page n'existe pas par exemple parce que les paramètres GET ne correspondent à rien par rapport à l'architecture du site). Maintenant, le fait est que rediriger simplement l'URL ?r=1 vers l'URL cible ne t'avance pas beaucoup, par contre si juste avant d'envoyer ce statut "301" tu crées une variable de session (cela implique soit d'utiliser le cookies, soit le Session ID... je sais cela pose d'autres problèmes) indiquant qu'il y a eu une redirection tu pourras la récupérer et l'exploiter comme tu le souhaite. Je ne vois pas d'autre solution plus fiable... dans tous les cas tu as raison si tu laisse pointer l'URL ?r=1 et sans ?r=1 sur le même contenu les moteurs détecteront ceci comme du duplicate content. Mais si tu fais une redirection après la première redirection, tu n'as pas ce problème, comme je viens de l'expliqurer.

Si cela te pose un problème d'avoir un paramètre GET dans la Query String (après "?"), tu peux éventuellement passer par la réécriture pour inclure ce paramètre. Mais fondamentalement tu va devoir différencier ces pages (sans pouvoir utiliser le HTTP_REFERER vu le peu de fiabilité de ce dernier), donc du point de vue du référencement ce sera deux pages différentes, sauf que celle ou atterriront les personne ayant utilisé une redirection les redirigera à nouveau vers la page de destination... mais au passage tu aura pu collecter les informations nécessaire au sujet de la personne. Pour les moteurs de recherche ils sont généralement conçu pour suivre les redirection et n'indexer que les pages de destination lorsque tu utilises une redirection permanente (301). Pour la page d'erreur, je ne vois pas ce que tu veux dire :S

Bonsoir, Pourquoi ne pas simplement ajouter un paramètre GET dans l'URL du site cible ? Sur ce site il suffit d'analyser (avec un langage comme PHP par exemple) cette variable pour déterminer si l'utilisateur est arrivé grâce à la redirection ou directement. Pour cela il faut pouvoir influencer le site source afin d'inclure ce paramètre dans cette redirection. L'URL de destination serait :-http://www.urlcible.com?r=1 Ensuite si ce paramètre te gêne tu peux générer une redirection sur le site cible qui sera effectuée uniquement si ce paramètre est à la bonne valeur (ce qui t'évitera de voir cette URL indexée), mais au passage tu auras pu déterminer si le visiteur est arrivé sur la page par une redirection. Si tu ne peux pas modifier le site source je ne vois pas vraiment d'autre solution fiable, le Referer n'est défini que lorsqu'un utilisateur effectue un clic. En même temps si c'était possible, il ont pourrait espionner tous le dernier site visité par un utilisateur, donc encore heureux que ce ne soit pas possible

Bonsoir, Je n'ai jamais été confronté à ce genre de problème, généralement les e-Shop dont on me confie la réalisation sont liés à une boutique préexistante et donc les stocks sont généralement les mêmes ou du moins entreposé aux mêmes endroits. Mais dans ton cas tu peux éventuellement aussi passer par une entreprise spécialisée dans le Self-Stockage (je te trouver le prestataire qui te convient) si tu peux en supporter les frais. Généralement le stockage de marchandises pour les entreprises à un tarif spécifique... et certains types de marchandises ne sont pas permises (entre autres les denrées périssables, explosives, etc.). Ensuite il faut aussi qu'il y ait une telle entreprise dans à proximité de ton logement (apparemment tu compte gérer ton affaire depuis ce lieu), afin de ne pas décupler les frais d'envois liés à chaque commande Bonne continuation.

Bonsoir, Sinon il y a aussi une classe PHP nommée "wiki2xhtml" qui est inclue dans le moteur de blog "DotClear", étant donnée que ce logiciel est sous licence GNU/GPL donc tu peux le réutiliser sous les même conditions de licence. Elle est peut-être un peu difficile à prendre en main, mais elle est assez bien documentée. Bonne chance

Effectivement si ce sont les prix pratiqués dans le domaine tu es avantageux Espérons que tu pourras conserver ces tarifs, lorsque ton site aura plus d'audience. À mon avis c'est le sous-entendu que Leonick faisait Bonne continuation et plein de succès pour ton site.