jcaron

Il me semble qu'il y a des solutions comme ça, mais l'utilisation d'une solution comme Prestashop a de nombreux avantages: - c'est un vrai CMS avec back-office, qui permet donc la mise à jour facile de la boutique par le propriétaire du site - tu as les fonctionnalités de suivi de commande, de support - tu as la gestion des catégories, des recherches, etc. - tu as la gestion des stocks, des frais de port - tu as des modules qui permettent l'intégration facile avec les systèmes d'expédition (pour avoir par exemple l'impression automatique des étiquettes Colissimo) - tu as des modules qui font l'export automatique du catalogue vers les comparateurs de prix ou les plateformes d'affiliation - tu as des modules pour le suivi Analytics automatique et détaillé - tu peux facilement traduire le site en plusieurs langues etc. Jacques.

Non, tu mets tes données dans Prestashop (catégories, produits, descriptions, photos...), et tu "habilles" Prestashop à ta sauce. C'est assez souple donc tu peux faire pratiquement ce que tu veux, mais la structure de base est forcément fournie par Prestashop... Jacques.

Tu as plusieurs niveaux de vérification possible: - la conformité de la syntaxe (avec une regexp) - l'existence du domaine de destination (un petit lookup DNS) - l'existence de l'adresse e-mail Pour le dernier cas, il n'y a (à ma connaissance) pas de solution simple qui marche à coup sûr. En SMTP il existe des commandes VRFY et EXPN qui permettent normalement de vérifier l'existence d'une adresse, mais il me semble qu'elles sont très souvent désactivées. Il est aussi possible de faire un début de connexion SMTP (en envoyant un EHLO, un MAIL FROM et un RCPT TO, puis en se déconnectant avant d'envoyer le corps du mail), mais le RCPT TO peut répondre positivement même si l'adresse n'existe pas (par exemple dans le cas de serveurs mails à plusieurs niveaux), ou au contraire toujours répondre négativement le premier coup (greylisting). Donc "en temps réel" (i.e. lors de la saisie), tu ne peux malheureusement faire que les deux premiers. Ensuite tu fais les trucs classiques, tu envoies un mail avec une URL de validation et tu demandes à l'utilisateur de cliquer dessus (ou alternativement tu ne le laisses pas choisir son mot de passe et tu lui envoies par mail). Evidemment ça a l'inconvénient qu'il peut y avoir un petit délai (surtout si son serveur de mail fait du greylisting), donc ça "casse" son processus d'inscription, suivant ce que tu cherches à faire ça peut être un handicap ou pas. Tu peux ensuite en plus ajouter la gestion des bounces etc. Jacques.

Oui, Prestashop est une bonne solution. Pour l'intégration avec CyberPlus il faut ajouter et paramétrer le module correspondant (d'après ce que je lis le module est fourni gratuitement par la BP). Par contre Prestashop n'est pas "un panier que tu ajoutes à un site", c'est une solution complète avec back-office et front-office, catalogue, catégories, etc, il faudra que tu intègres les produits dedans, et que tu adaptes ta charte graphique pour en faire un "thème". Un peu de boulot au départ, mais à terme c'est nettement mieux... Jacques.

Quand tu demandes à ton navigateur de visiter une URL donnée (ou quand un robot visite cette URL), il découpe l'URL en deux (un peu plus en fait, mais pour la discussion ici ça nous suffit): le nom du site, et le chemin sur le site (http://www.site.tld/chemin -> www.site.tld et /chemin). Ensuite il utilise le DNS pour "résoudre" www.site.tld (sans pouvoir fournir d'autre information, donc en particulier pas le /chemin), qui lui répond une ou plusieurs adresses IP. Donc cette IP sera forcément la même, que tu demandes www.site.tld/toto ou www.site.tld/tata. Pour les moteurs autres que Google: - bing serait sensible à la spécification exacte (et non standard) de la langue (dans le Content-Language), par exemple en-GB (ou est-ce en_GB? je ne sais plus) lui permet de décider que tu vises UK plutôt que les US - pour Yahoo j'en sais rien Evidemment pour des pages qui visent des pays différents mais utilisent la même langue, ben oui, c'est la même langue (Google ne lit pas le Content-Language mais fait une analyse linguistique du texte, donc la subtilité entre américain/britannique/australien lui échappe clairement). A mon avis la meilleure solution consiste à avoir un domaine par pays, dans le bon ccTLD (ce qui en plus donne plus confiance aux visiteurs du pays cible), avec ensuite un sous-domaine ou un sous-répertoire par langue pour les pays multilingues (Belgique, Suisse, Canada, Hong Kong, Singapour, éventuellement US, etc.). Jacques.

Au niveau de l'adresse IP, non, puisqu'il s'agit d'un seul et même site, et donc forcément d'une seule et même IP (même si un site peut avoir plusieurs IPs, y compris différentes en fonction de la localisation du visiteur, ce n'est pas important dans le cas des robots, qui ne verront forcément qu'une seule IP au hasard). La résolution site -> IP ne tient en aucun cas compte du reste de l'URL. Par contre Google devrait bien détecter la langue de chaque page de façon indépendante. Et il est aussi possible de choisir le ciblage de chaque répertoire séparément dans GWT en ajoutant chaque répertoire comme un site séparé. Jacques.

Non, pour tout plein de raisons. Il serait temps d'aller lire la doc. - Files "matche" sur le nom de fichier uniquement (basename), pas sur le chemin - Allow "matche" sur l'adresse IP de celui qui se connecte A priori ton "lecteur mp3" est chargé sur l'ordinateur du client, et c'est celui-ci qui va aller chercher le fichier. Donc il faut que tu acceptes toutes les adresses IP, et que tu trouves un autre moyen de ne pas donner accès aux fichiers en question. Indice: il n'y a pas de méthode sûre à 100% qui puisse faire ce que tu veux. Jacques.

UTF-8 est un sur-ensemble de l'ASCII, compatible avec de l'ASCII si tu n'utilises que des caractères ASCII, ce qui est ton cas ici. mb_detect_encoding ne fait que vérifier si une chaîne est compatible avec tel ou tel encodage, et par défaut (si tu ne donnes pas de liste), commence par l'ASCII. Dans ton cas, le texte est du 100% pur ASCII, donc il te répond que c'en est. Et convertir l'ASCII en UTF-8 ou de l'UTF-8 qui ne contient que des caractères ASCII en ASCII ça revient à ne rien faire. Jacques.

Précisons que le symbole pour l'euro n'existe pas en ISO 8859-1, mais uniquement en 8859-15 (ainsi qu'en windows-1252). Pour ma part je conseillerais fortement de tout passer en UTF-8, ça élimine toutes les ambiguïtés... Jacques.

preg_replace('/\b(mot)\b/','<a href machinchose>$1</a>',$chaine); Non? \b "matche" à la limite d'un mot. Jacques.

Si tu as accès à la config du serveur (plutôt que juste les .htaccess), il y a probablement plus simple avec un Alias ou ScriptAlias de / vers ton script, et ensuite tu récupères "le reste" via $_SERVER[PATH_INFO]. Je n'ai jamais fait ça avec un php, mais en perl ça marche très bien, donc je suppose que ça doit être jouable avec du php... Alternativement, une RewriteRule qui renvoie tout (.*) sur ton script, et ensuite tu dois bien pouvoir trouver l'URL originale quelque part dans $_SERVER (probablement REQUEST_URI ou quelque part par là...). Jacques.

Ben s'il n'a pas déposé de marque, et à moins (ce qui m'étonnerait) qu'il puisse bénéficier de la protection de la marque "notoire", je pense qu'il ne va pas pouvoir faire grand chose, à part éventuellement une procédure en concurrence déloyale (parasitisme), mais ils ont nettement plus de boulot. Et évidemment, si l'ensemble des deux mots est générique par rapport à la thématique, ils peuvent difficilement faire grand chose (genre si c'est credit-immobilier et immobilier-credit). Au fait, à part "nous domaine X-Y vous domaine Y-X, salaud", ils disent quoi précisément? Ils donnent une base légale quelconque à leur message? NB: moi pas avocat, si tu veux un vrai avis un peu plus étayé, consultes-en un. Jacques.

Je n'avais même pas pensé à eux, mais au delà, même si tu ne peux pas déposer un mot ou une expression commune liée à ce que tu vends (tu ne peux pas déposer "Boulanger" si tu vends du pain, alors que tu peux le déposer si tu vends de l'électroménager), une combinaison de mots communs peut parfaitement être déposée et protégée. Par exemple "pain" et "quotidien" sont deux mots génériques, et pourtant "le pain quotidien" est déposé. D'ailleurs fais une recherche sur "pain" sur le site de l'INPI, tu vas voir, il y en a des tonnes... Jacques.

La toute première question c'est quand est-ce-que l'autre a déposé son domaine et quand il a commencé à l'utiliser. La deuxième c'est de savoir s'il a fait un dépôt de marque (et où en est ce dépôt, et de quand il date). Et pour finir quand est-ce-que tu as commencé à utiliser ton domaine. Déjà si tu as antériorité, il peut oublier direct. Ensuite s'il n'a pas de marque déposée ça va être assez difficile pour lui d'obtenir grand chose à mon avis, en tous cas en contrefaçon (et donc UDRP etc.). Il peut éventuellement essayer de d'attaquer sur du parasitisme, mais je pense que ça risque d'être assez laborieux aussi, mais évidemment ça dépend beaucoup des circonstances exactes. Jacques.

Euh... Propriété intellectuelle = propriété littéraire et artistique (droits d'auteur, droits voisins...) + propriété industrielle (marques et brevets), pas l'inverse. Si on ne parle que de droits d'auteurs, les produits dérivés sont clairement des oeuvres dérivées, et il faut donc l'autorisation des ayant-droits originaux (aussi bien en termes de droit moral que de droit d'exploitation). C'est quoi la question? Jacques.

La deuxième page est sur le même site (même domaine)? Dans le même répertoire (tu n'as pas précisé de chemin, donc par défaut c'est restreint au même répertoire)? Jacques.

Pas tout suivi... Si tu supprimes le cookie, il n'existe plus (comme on le voit bien dans ton test) et isset($_COOKIE[$cookieAuthName]) est faux. Jacques.

Euh... isset($_COOKIE[$cookieAuthName]), plutôt, non? Et quel est l'intérêt de stocker une variable de session dans un cookie? Jacques.

Je ne vois pas bien l'intérêt de cette méthode par rapport à la méthode libkhtml qui est pratiquement faite pour ça. Si tu peux faire tourner Firefox tu peux faire tourner libkhtml, puisque c'est ce que Firefox utilise, et tu devrais avoir un contrôle nettement plus précis de ce qui se passe... Jacques.

dummy=bidon L'explication dit que tu mets le nom de domaine et le dossier dans lequel se trouve ton forum (genre forum.site.com ou www.site.com/forum), mais qu'il faut laisser le /dummy/ à la fin. Il est probablement remplacé par quelque chose d'autre par la suite ou un truc du genre. Jacques.

Si je ne m'abuse tu peux préciser l'URL de l'IPN à utiliser dans le paramètre notify_url dans le formulaire transmis à Paypal. Evidemment ça rend l'URL en question publique et ça peut attirer des indésirables. L'autre option est que tu utilises un script IPN unique qui va utiliser un paramètre (genre le format de custom) pour déterminer de quel site il s'agit et agir en conséquence (éventuellement en faisant du proxying vers le script de chaque site). Sinon il faut vérifier avec Paypal, mais je ne suis pas sûr que ça passe très bien plusieurs comptes au même nom (tu vas avoir des problèmes pour valider le compte, genre tu ne peux pas avoir la même carte sur plusieurs comptes). Jacques.

Ca fait longtemps que je n'ai pas touché un serveur avec X installé, mais je ne vois pas en quoi KDE serait si difficile que ça à sécuriser... Ce n'est pas parce qu'il est installé que tu as besoin de lancer un serveur X ouvert de l'extérieur. Tu lances juste un framebuffer accessible uniquement en local, et c'est fini. Et je pense que tu ne trouveras aucun moteur de rendu HTML un tant soit peu complet et à jour sans un serveur X. Libkhtml est justement fait pour ça, c'est un moteur de rendu, tu peux le lancer sur n'importe quel serveur X, y compris le frame buffer qui est purement virtuel. A ma connaissance tous les services existants de génération de vignettes utilisent forcément la même méthode: un serveur X frame buffer, et soit libkhtml, soit le browser complet et un peu de découpe, ou alors l'équivalent Windows avec un browser complet un minimum contrôlable et de la capture d'écran. Pas de miracle, à moins que tu ne veuilles faire le rendu toi-même, et tu vas voir que faire un moteur de rendu HTML+CSS complet et à jour c'est un sacré boulot (et je ne parle même pas des plugins genre flash). Jacques.

http://khtml2png.sourceforge.net/ peut-être? Le composant important dans l'histoire c'est libkhtml qui contient le moteur de rendu, le reste c'est de l'habillage suivant ce que tu cherches à faire exactement. Jacques.

Pas entièrement d'accord avec la dernière affirmation: les jeux d'argent tels qu'ils sont définis dans les textes actuels et ceux en gestation (la dernière fois que j'ai regardé) requièrent l'intervention du hasard (en plus de l'espérance de gain et du sacrifice financier du participant), ou alors sont définis par leur lien avec des performances sportives (pari sportif). Ce qui est habituellement appelé un "concours", et qui fait appel à la sagacité, la dextérité, l'expérience, les connaissances, etc, ne rentre pas dans le cadre de ces dispositions, même si on doit payer pour participer et si on gagne quelque chose au bout. Mais il faut que le hasard ne rentre pas en ligne de compte, même à titre accessoire (i.e. pas question de faire un concours avec une question unique bateau, et ensuite un tirage au sort pour départager les gagnants). Ceci dit, avec une seule et unique question c'est quand même dur de faire un concours, à moins que ce soit le genre de truc avec un jury (i.e. soumettez un texte / une oeuvre), mais là ça pose d'autres problèmes (il faut un jury, il faut qu'il soit indépendant et reconnu, etc.). Avec beaucoup de questions ça devient plus facile, mais il faut toujours un moyen de départager les ex-aequos à un moment donné (à moins que le lot puisse être partagé), et là ça devient difficile (de mémoire la jurisprudence dit que les questions genre "donnez un nombre entre 1 et 1000" et le gagnant est celui qui est le plus proche de la moyenne sont considérées comme du hasard). La rapidité peut intervenir, à condition que les moyens de mesure aient une précision supérieure à l'écart entre les participants, ce qui est le problème ici... Jacques.

Ben comme je disais, ça va dépendre de la question. Si c'est une question assez compliquée pour que ça prenne plusieurs minutes pour y répondre, et qu'il y a un écart d'au moins quelques secondes entre les réponses des différentes participants, ça ne devrait pas trop poser de problème. Si par contre c'est super simple et que tout le monde peut répondre en une fraction de seconde, ça va être chaud, la latence induite par Internet variant probablement plus que l'écart entre les réponses. Jacques.