jcaron

Ca dépend déjà de la question, mais le problème est très certainement le fait que c'est "le premier qui répond" qui gagne. Vu les aléas introduits par les connexions Internet etc, ça relève du hasard, et donc de la législation sur les loteries. Jacques.

Il y a deux parties pour le paiment en ligne: - le compte commerçant - la passerelle de paiement Suivant les cas, tu peux avoir les deux ensemble ou séparément. Le compte commerçant est fourni par une banque au commerçant lui-même, la passerelle peut l'être aussi (c'est le cas des solutions de paiement Internet de la plupart des banques françaises qui sont du ATOS repackagé), ou tu peux passer par une passerelle tierce comme Paybox. En "intégré" tu as aussi Paypal, Moneybookers et quelques autres. Dans tous les cas, il va falloir faire une intégration entre ton site et la passerelle de paiement, pour passer les bonnes informations (compte, montant au minimum), et récupérer le fait que la paiement a été effectué ensuite. Ca peut aller des choses très simples (par exemple un bouton créé une fois pour toutes avec le créateur de bouton de paiement de Paypal, et dont il ne reste plus qu'à coller le code HTML dans ta page, et une notification par e-mail du paiement), à des choses nettement plus compliquées, avec passage de nombreux paramètres, autorisation et paiements séparés, contrôles anti-fraude, notification des paiements directement dans la BDD, etc. Dans de nombreux cas tu ne verras jamais les numéros de carte etc. qui seront traités uniquement par la passerelle, dans d'autres cas c'est toi qui les stockes (mais ça a des conséquences importantes en termes de sécurité, de certification PCI DSS, etc.). Certaines banques sont assez frileuses quand il s'agit de fournir des comptes commerçants (à cause du risque de "chargeback" sur les opérations, qui peut couler une société qui ne fait pas attention et laisser la banque avec une jolie ardoise), d'autres moins, ou vont tenir compte du secteur d'activité (considéré comme à risque ou pas). De la même façon certains vont se gaver en comms (la comm Paypal par défaut c'est 3.4%, et j'ai déjà vu encore plus). Bref, il y a beaucoup de paramètres, et beaucoup de choses vont dépendre exactement de ce que tu vends, comment, à qui, etc. Et oui, si tu dis "cryptation SSL", tu vas passer pour un glandu. En bon français c'est chiffrement, en mauvais c'est cryptage. Jacques.

Non, pas forcément. Il y a de nombreux cas où la config est bancale, et suivant le "chemin" pris pour résoudre le nom (le NS sélectionné à tel ou tel niveau, par exemple), le résultat pourra être bon ou pas. Quoi qu'il arrive, les résultats seraient alors imprévisibles et surtout irréguliers: ça pourrait marcher à un moment, ne plus marcher un peu plus tard, etc. Jacques.

Tu as vérifié que ta config est correcte et cohérente? Utilise un outil comme http://www.squish.net/dnscheck/ qui explore de façon exhaustive toutes les possibilités pour être sûr que les NS indiqués renvoient bien tous la même chose (ou en tous cas ce que tu veux qu'ils renvoient). Ensuite tout dépend de la modif exacte (changement d'un A, changement de NS...) et de comment elle a été préparée (réduction du TTL avant ou pas). Si tu nous indiquais le domaine ça pourrait aider, bien entendu. Jacques.

Pour enlever les accents, en perl, moi je fais ça: my $t = NFD($string); $t =~ s/\pM//g; Ca veut dire: recode tout ça de telle façon que les caractères accentués soient codés comme un (ou plusieurs) accent(s) + la lettre "de base", puis vire tous les caractères qui sont des accents. Je vous laisse transformer ça en php (hint: http://php.net/manual/en/class.normalizer.php ). Jacques.

C'est quoi le but ultime? Faire l'authentification au niveau php en utilisant une BDD, ou juste récupérer l'utilisateur déjà authentifié par les directives dans le .htaccess? - dans le deuxième cas, il te suffit de consulter $_SERVER['REMOTE_USER'] et l'histoire s'arrête là - sinon, demande-toi bien si tu ne peux pas le faire dans le .htaccess. Avec un bon mod_auth_mysql ça devrait être réglé en quelques lignes - si tu veux vraiment faire l'auth en php et utilisé le code fourni, note qu'il manque un \, je te laisse trouver où :-) Jacques.

J'ai failli dire la même chose, mais j'ai été vérifier dans la doc d'Apache, et dans ce cas précis en fait on n'a pas besoin de mettre l'URL complète: le flag [R] ajoute automatiquement le début. />http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule C'est effectivement différent des directives Redirect* ou de ce qu'on met dans un header Location: directement. Jacques.

Les RewriteRules en question ne sont pas des redirections, mais plutôt des alias: de l'extérieur (navigateurs, moteurs...), seule l'URL au format dans la première partie est effectivement visible. Il te faut donc rajouter une "vraie" redirection qui va renvoyer les anciennes URLs vers les nouvelles. Pas un grand spécialiste de la RewriteRule, mais quelque chose comme: RewriteRule ^products/(.*\.htm)$ http://nomdusite/nouveauterme/$1 [R=301] devrait faire l'affaire (si c'est pas ça c'est pas très loin). Jacques.

Sans une bonne connaissance du marché local ça risque d'être chaud... Pour le mobile il y a toutes sortes de standards, et d'un pays à l'autre l'importance relative de chacun sont très variables. Par exemple au Japon i-mode a été très largement dominant à un moment donné, je ne sais pas si c'est toujours le cas ou pas. Ensuite il y a peut-être du WAP, puis du XHTML mobile, et de nos jours on doit commencer à évoluer vers des téléphones qui supportent du web "classique" ou presque. En France aussi il y a des centaines de types de téléphones différents, chacun avec ses spécificités en termes de formats supportés, de taille d'écran, etc. Note qu'il doit aussi y avoir (en particulier sur i-mode) des modes de paiement "intégrés" pour des petits montants (i.e. paiement directement sur la facture mobile), comme sur les kiosques WAP en France. Une bonne approche peut consister à séparer la partie "logique" (bdd, algos...) de la partie présentation, avec une jolie API (un webservice) au milieu, et dire à l'agence de faire juste la partie présentation en utilisant l'API que tu mets à leur disposition. Jacques.

Parce que tu aurais un action dans le form, éventuellement un onsubmit si tu as réellement besoin de JS. Idéalement il faudrait transformer ton input type=button en input type=submit, sinon tu dois ajouter un onjesaispasquoi sur le input. De toutes façons, quoi qu'il arrive, <form> <input> </form> c'est normal, alors que <a href> <input> </a> je ne suis même pas sûr que ce soit autorisé. Jacques.

Je pense que c'est surtout parce que tes INPUT ne sont pas dans un FORM (qui rendrait d'ailleurs le A HREF inutile), non? Au passage, tu devrais vraiment passer ta page au validateur, il y a des choses assez horribles dedans... Jacques.

Tu as bien gardé tous les bouts que j'ai donnés, en particulier le position: fixed sur le div externe? A part les background et color évidemment :-) Tu as bien ce code juste après le <body>? Ce n'est normalement pas indispensable, mais ça peut éviter des surprises. Tu as passé l'ensemble de ta page au validateur W3C pour vérifier qu'il n'y avait pas de problèmes de syntaxe qui pourraient affecter la mise en page? Avec le code que je t'ai donné, le div externe est forcément calé sur la fenêtre (c'est le but du position: fixed, par opposition à un position: absolute qui le calerait par rapport à la page), et le div interne est calé par rapport à ce div externe. J'ai testé ce code avec IE, FF et Opera et ça fait bien ce qui est prévu: le div interne ne bouge pas d'un poil quand tu scrolles. Jacques.

C'est ce que fait le code que je t'ai donné, non? Jacques.

+1 Tu enlèves le contenu litigieux s'il te le demande (et que ça te paraît justifié, bien entendu). S'il veut les adresses IP, il faut qu'il porte plainte, et la justice te les demandera. Tu n'as pas le droit de les lui fournir directement. Jacques.

Non, la base de données ne devrait poser aucun problème, mais si lors de l'install il a pris en compte "en dur" des chemins absolus qui disent que c'est dans "web" ça peut poser des problèmes. D'après la doc, dans l'interface d'admin ("Gandi AI"), en mode avancé, tu peux choisir le répertoire utilisé pour chaque serveur (http://wiki.gandi.net/fr/hosting/gandi-ai/module/apache2) Sinon, option à tenter: - tu renommes le dossier doc en ce que tu veux (ou tu le vires complètement s'il n'y a rien d'utile dedans) - tu renommes web en doc - tu essaies pour voir si tout marche. Si c'est le cas, tout va bien. Sinon, tu renommmes doc en web pour revenir en arrière Au delà il faudra effectivement probablement faire des manips en ssh, ce qui n'est pas très compliqué en soit, mais sans connaître l'organisation des choses chez eux c'est un peu difficile de te téléguider. J'ai plein de domaines chez Gandi mais aucun hébergement, donc je ne sais pas du tout à quoi ça ressemble. Jacques.

C'est un serveur virtuel plutôt qu'un dédié, mais de ton point de vue c'est pareil: c'est pas fait pour ceux qui ne connaissent pas :-) Tu fais ensuite des mélanges entres URLs, chemins locaux, etc. qui font qu'il est difficile de te suivre. La grande question est: si www.monsite.fr arrive dans le répertoire docs, pourquoi vouloir créer un nouveau répertoire et faire des choses compliquées (pour toi) pour le renvoyer ailleurs? Pourquoi ne pas mettre le contenu de ton site dans le répertoire docs qui existe déjà et qui doit a priori être fait pour ça? Sinon le but du jeu ne devrait pas être de faire des redirections, rewrites ou quoi que ce soit du genre, mais juste changer le chemin racine (DocumentRoot) pour le serveur considéré. Ca se passe dans la config Apache directement, pas dans un .htaccess... Jacques.

Je suppose que tu veux dire que tu veux le centrer dans la fenêtre :-) Pour ça, la solution "pur CSS" c'est de faire un div en position: fixed avec top, left, bottom et right à 0, et mettre dedans un deuxième div en position: absolute, aux dimensions voulues, avec des margin: auto et top, left, bottom et right à 0. <div style="position: fixed; top: 0; bottom: 0; left: 0; right: 0; background: red; border: solid 1px black"> <div style="position: absolute; width: 400px; height: 300px; top:0; bottom:0; left:0; right: 0; margin: auto; background: blue; border: solid 1px black"> Blah </div> </div> Il y a peut-être plus simple, mais ça en tous cas ça marche. Attention: il faut que les dimensions de la boîte à centrer soient fixes, sinon ça ne marche pas. Jacques.

Rien compris... Ils sont où exactement les liens problématiques, et c'est quoi le problème exact? Avec un exemple précis ça aiderait probablement. Sur le site que tu indiques je ne vois aucun souci avec les liens partenaires? Jacques.

F: ne serait pas sur un serveur distant? Il n'y aurait pas un problème de droits pour le processus php? Jacques.

Tu as regardé du côté de open_basedir? http://www.php.net/manual/en/ini.core.php#ini.open-basedir Jacques.

Tu as quoi comme extension pour ton site? .co.jp ou .com? Si .com, tu as bien mis un Content-language ja-JP dans tes pages? Bing serait, d'après ce que j'ai pu en lire, plus "difficile" que Google à convaincre du public cible. Maintenant, quand tu dis que Bing est très utilisé au Japon, quelles sont tes sources? Moi les derniers chiffres que j'ai c'est 75% Google, 20% Yahoo et 2% Bing... Mais visiblement les pdm de Google et Yahoo ne correspondent déjà pas à ce que tu observes. Jacques.

Je ne sais pas comment elle s'appelle et j'ai la flemme d'aller vérifier, mais oui, la page où il y a le bouton qui envoie chez Paypal, qui est le formulaire généré par le code que tu as donné au début, qui doit contenir le charset, et les paramètres que tu passes pour pré-remplir tout ça. Si le charset n'est pas bon même la description des produits pose problème (UTF-8 non reconnu et affiché comme de l'ISO). C'est donc cette page-là dont tu dois afficher le source pour vérifier que les coordonnées de l'utilisateur sont correctement encodées (ou pas). Jacques.

C'est mon instinct, mais j'avoue que je n'ai pas grand chose pour l'appuyer. Pour faire ça, un peu de rewriting bien classique suffit, avec plusieurs façons de le faire possibles... Jacques.

Bizarre, mais déjà que php c'est pas ma tasse de thé, alors php sous Windows... Il n'y a pas un réglage dans php.ini qui l'empêcherait d'écrire "ailleurs"? Jacques.

Il y a 3 problématiques: - il faut que les domaines <pays>.domaine.tld pointent sur le serveur. Pour ça, il faut soit les mettre tous un par un dans la zone, soit créer un "wildcard" (*.domaine.tld) qui va pointer sur le serveur. Chez certains registrars la deuxième solution n'est pas forcément possible. - il faut que le serveur reconnaisse le domaine et l'amène au bon endroit. Si tu es sur un serveur dédié, c'est facile. Si tu es sur un mutualisé, ça va dépendre beaucoup de ton hébergeur et de la formule choisie - ensuite il faut qu'en fonction de ce contenu tu affiches tes choses différentes. Pour ça tu peux utiliser du rewriting, ou des virtual hosts différents, mais le plus simple à mon avis est juste de déclarer un seul index (index.php) qui va identifier le site demandé ($_SERVER['HTTP_HOST']) et à partir de là trouver les bonnes infos à afficher (avec une petite table qui va bien en base par exemple). Tout ceci étant dit, je ne suis pas convaincu qu'avoir une site par pays soit forcément la meilleure option en matière de référencement, puisque ça veut dire que chaque site/domaine est considéré séparément, donc ça va être plus difficile a priori de construire du trustrank et tout le tintouin. Une solution de type www.domaine.tld/pays me semblerait plus appropriée, non? Tu peux toujours tester les deux options sur deux domaines différents pour voir :-) En faisant attention au duplicate content, évidemment... Jacques.