jcaron

Tu peux nous dire ce que contient $filestore exactement? De préférence après avoir vérifié qu'il a bien cette valeur-là à ce moment-là avec un petit echo ou error_log bien placé... Jacques.

Tu devrais trouver dans bonheur là-dedans: />http://php.net/manual/en/book.imap.php voir en particulier imap_fetchstructure, imap_fetchbody, imap_bodystruct... Jacques.

Tu m'enlèves les mots de la bouche :-) C'est sûr, pas sur un mutualisé, mais de toutes façons je suppose (j'espère!) que le projet final n'est pas prévu pour tourner sur un mutualisé. ab c'est très bien, mais il faut bien voir une chose: si tu ne le lances que depuis une seule autre machine, tu es limité par les performances de cette machine-là, ce qui ne permet pas forcément de monter jusqu'au niveau de requêtes voulu, donc il faudra probablement "attaquer" à partir de plusieurs machines. Et ça ne prend pas forcément en compte des paramètres tels que la latence de certains utilisateurs. C'est moins vrai de nos jours maintenant que le dialup a beaucoup régressé, mais il doit encore y en avoir. Après suivant les cibles il y a les gens à l'autre bout de la planète ou ceux sur des connexions 3G etc, qui ont une latence plus élevée que celle observée depuis un autre serveur. Ca a l'air con comme ça, mais si tu as 100 ms de latence A/R sur une connexion, ça peut très nettement augmenter le temps que la connexion TCP va rester en place, et donc éventuellement qu'un processus php va rester "occupé" et squatter de la RAM pour rien (ça dépend de la façon dont php est utilisé, en module, en cgi, en fastcgi...). Il doit y avoir des services commerciaux qui permettent de faire ça à grande échelle aussi. Tiens, au passage, quelques paramètres système qu'il est utile de vérifier/modifier/augmenter carrément beaucoup quand on veut monter sérieusement en charge sur une machine FreeBSD: kern.maxfiles kern.maxfilesperproc kern.threads.max_threads_per_proc kern.ipc.somaxconn kern.ipc.maxsockets net.inet.ip.portrange.first net.inet.tcp.maxtcptw net.inet.tcp.nolocaltimewait net.inet.icmp.icmplim vm.pmap.pv_entry_max Je ne sais pas s'ils ont tous des équivalents sous Linux. Il y a certainement des paramètres qui n'ont pas besoin d'être modifiés de la sorte sous Linux, et il doit y en avoir d'autres à modifier en plus à mon avis, et ça doit évidemment varier d'une version/distribution à une autre. Certains paramètres sont aussi liés à ton architecture exacte (par exemple net.inet.ip.portrange.first et net.inet.tcp.nolocaltimewait sont utiles dans le cas où tu utilises un reverse proxy ou load balancer genre pound sur la même machine). Evidemment, il faut penser à instrumenter ta (tes) machine(s) avant de faire tes tests, histoire de pouvoir suivre au minimum la consommation de CPU et de RAM, et suivant les cas les accès disques et quelques autres paramètres genre nombre de processus, de threads, de fichiers ouverts, de connexions établies, etc. Jacques.

Je ne sais pas s'il y a un problème spécifique avec ce type d'hébergement (je ne vois pas très bien pourquoi, tant que chaque domaine est bien géré comme un virtual host séparé, et qu'il n'y a pas de redirection ou de framing), mais ce serait plus facile avec les noms des domaines... Jacques.

C'est pour ça que je suis allé sur ton site, j'ai préparé une commande, j'ai vu le bouton Paypal, j'ai fait "afficher le source", et j'ai vu le "CHARSET"? Donc tu vires la suppression des accents, tu fais pareil, et tu regarde quelle gueule ces accents ont dans le source. Et tu penses à corriger le "CHARSET", évidemment. Jacques.

+1 avec Kioob, on n'est plus au temps du Minitel, les connexions "simultanées" en http c'est un élément à géométrie variable (rappel: un navigateur est connecté au serveur le temps de charger la page et ses éléments, éventuellement quelques secondes après au cas où, puis il se déconnecte, il ne reste pas connecté tout le temps que la page est affichée). En général, on compte plutôt en nombre de requêtes par seconde, mais couplé avec le temps d'exécution d'une requête (CPU + latence accès bdd ou ressources externes) et les mécanismes de Keep-Alive, ça a une influence sur le nombre de connexions TCP (et de processus ou threads) simultanés. Une "session php" ça ne consomme rien. Pour moi il y a trois parties: - les connexions avant 20h - le "dévoilement du questionnaire" - les connexions après pour soumettre les réponses Le dévoilement du questionnaire peut être fait de plusieurs façons: - quand le gars se connecte avant 20h on lui envoie le questionnaire quand même, mais il est "caché", et ne sera dévoilé qu'à l'heure dite sans nouvelle connexion au serveur. Evidemment il faut prendre un minimum de mesures pour que le gars ne puisse pas juste regarder le source une heure avant pour le récupérer, et il faut assurer un minimum de synchro (i.e. ne pas tenir compte bêtement de l'heure du PC) mais quoi qu'il arrive, si on veut éviter une connexion à 20h, il faut fournir tous les éléments à l'avance, et c'est donc forcément déchiffrable - on force un reload à l'heure dite. Ca veut dire 15 000 requêtes en quelques secondes. - on utiliser un système de "push" (en fait du long polling). Ca veut dire 15 000 connexions simultanées (là c'est effectivement le cas, on garde volontairement la connexion établie), et 15 000 réponses envoyées d'un coup à tout le monde - on combine la première option et l'une des deux autres pour envoyer toutes les données à l'avance, sauf une clef de déchiffrement, et on envoie juste la clef à l'heure dite. Pour le push/long polling, voir des solutions comme APE, ou faire un développement maison (avec libevent il doit être possible de développer ça en quelques centaines de lignes de C, peut-être même moins de 100). Note que quoi qu'il arrive "exactement au même instant" reste approximatif, il y aura forcément un écart de quelques millisecondes à plusieurs secondes. Pour les parties avant/après, c'est une question de prévoir à quel rythme ces connexions vont se faire. Au pire c'est 15000/seconde, au mieux ça s'étale sur des minutes donc on peut descendre à quelques dizaines de requêtes/seconde. Ne pas oublier malgré tout de compter les reloads que plein de gens vont forcément faire (ce qui entraîne des requêtes pour tous les autres fichiers inclus), et dans le cas de la soumission, les problèmes genre soumission incomplète etc qui vont forcément entraîner plusieurs soumissions. Choses à faire ou à vérifier: - essayer de rendre un maximum de contenu totalement statique - alléger autant que possible toutes les pages "sur le chemin" - séparer le contenu statique du contenu dynamique (mettre le contenu statique sur un serveur dédié super light, genre Apache sans aucun module ou presque, ou lighttpd) - supprimer les keep-alives sur le contenu dynamique - la config d'Apache en termes de nombre de clients, processus, threads, etc. - attention à faire en sorte que la machine ne swappe pas: les processus php sont très gourmands en RAM, donc si tu laisses Apache en forker trop, ta machine va te faire une mort subite - la config mysql en termes de nombres de clients etc. - la config système en termes de nombre de processus, fichiers ouverts, connexions, etc. - la config de firewalls (externes ou internes) qui limiteraient le nombre de nouvelles connexions par seconde (pensant que c'est une attaque DDOS par exemple) Si tout ça ne tient pas sur une seule machine (ce qui est possible), tu peux avoir intérêt à utiliser des solutions de serveurs virtuels "à la demande" (voir chez Gandi ou chez Amazon par exemple), que tu peux louer pour juste quelques heures et qui utilisent des "images" du serveur pré-construites. Et évidemment, tester tout ça bien à l'avance, surtout la montée en charge. On a toujours des surprises sur des paramètres auxquels on n'aurait jamais pensé... Jacques.

Il y a deux problématiques: savoir si ton association loi 1901 est imposable ou pas (voir http://fr.wikipedia.org/wiki/Association_loi_de_1901#R.C3.A9gime_fiscal pour les détails), et ensuite, si elle est imposable, savoir si la TVA s'applique (suivant les mêmes critères que pour une activité commerciale, une question de seuils de CA). Une fois que tu as déterminé si tu es assujetti à la TVA ou pas, on a donc deux possibilités: - tu n'es pas assujetti: tu n'as pas de numéro de TVA, tu paies la TVA comme tout le monde, tu ne te la fais pas rembourser, tu n'en factures pas - tu es assujetti: tu as un numéro de TVA, pour la TVA française tu la paies et tu te la fais rembourser par le fisc, pour les transactions intra-communautaires normalement du donnes ton numéro de TVA et le fournisseur ne te la facture donc pas, et tu dois facturer de la TVA à tes clients (sauf assujettis en UE hors France) que tu reverses au fisc Jacques.

Je me réponds à moi-même... C'est bien ça, il faut mettre charset en minuscules et ça marche très bien pour la description. Mais comme tu supprimes les accents dans le reste, difficile de dire ce qu'il en est pour le moment... Jacques.

Au fait, c'est "charset", pas "CHARSET", il me semble bien que Paypal est sensible aux majuscules/minuscules. Jacques.

Bon, reprenons depuis le début. Tu vas sur ton site, genre www.exemple.truc. Il y a une script PHP (genre index.php) qui est appelé. Ce script génère du HTML, qui est envoyé à ton navigateur, qui affiche la page correspondante. Pareil dans le cas présent: tu vas sur la page de paiement, il y a un script PHP qui est appelé (je ne sais pas comment il s'appelle chez OScommerce, supposons que ce soit payment.php, qui appelle tout un tas d'autres fichiers, modules, librairies, etc.), il génère du HTML, qui est envoyé à ton navigateur, qui affiche alors une page avec un joli bouton "Paypal". Le bouton en question est le résultat de tout un tas de HTML, un formulaire (<form...>) avec tout plein de <input type="hidden" name="xxx" value="yyy">, et un bouton. Quand tu cliques sur ce bouton, le formulaire est "soumis" à Paypal, avec tous les paramètres qui sont indiqués dans les <input type="hidden"...>. Le bout de code que tu as donné est du PHP qui génère ce code HTML. Or, il se trouve que visiblement, ce code PHP se trompe quelque part, et génère du code HTML qui est incorrect sur certaines des valeurs qui n'ont pas le bon encodage et/ou ont été incorrectement converties (trop ou pas assez). Donc si tu vas sur la page où se trouve ce bouton "Paypal", que tu fais "Afficher le source", tu vas avoir le code HTML correspondant à ce formulaire, y compris toutes les valeurs que tu passes à Paypal. Bref, tu vas voir le résultat de l'exécution de ton code PHP. C'est la première chose à faire quand on débuggue du php ou tout autre script sur un site web: on commence par vérifier que le résultat de l'exécution (le code HTML généré) correspond bien à ce qu'on voudrait/attend, et que le code HTML généré est bien correct. Si tu ne sais pas exactement ce que tu envoies à Paypal, tu ne peux pas reprocher à Paypal de mal le traiter. Ce serait comme remplir ta déclaration d'impôts les yeux fermés et l'envoyer sans la regarder, et ne pas être content parce qu'ils te font payer plus d'impôts que prévu: tu penses que tu as mis les bonnes valeurs dans les bonnes cases, mais en fait tu n'en sais rien, donc tu ne peux pas te plaindre. La première chose à faire est de vérifier ce qui est envoyé, et ça, tu va au moins en avoir une indication en regardant le code HTML. Comprendo? Jacques.

Au delà de la problématique "technique" (qui devrait effectivement être assez facile à résoudre, il suffit une fois la traduction faite côté client que le script JS fasse un autre appel Ajax d'une .php chez toi auquel il envoie la version traduite, et hop -- ceci dit, quel est l'intérêt de stocker tout ça en base?), tu es bien conscient que les traductions automatiques Google ça reste quand même très approximatif? Jacques.

Et à ton avis ton PHP il génère quoi? Du HTML, qui est interprété par ton navigateur. Donc tu prends ton navigateur favori, tu vas sur la page qui contient le formulaire en question et tu fais "Afficher la source", et tu regardes ce que contiennent les <input type="hidden" value="xxx">, en tenant compte du charset indiqué dans le formulaire, du charset de la page et éventuellement du charset du <form>. Visiblement certains champs doivent être encodés de travers, probablement parce qu'entre la base et le HTML il y a des conversions inutiles (ou manquantes). Et à ma connaissance ce n'est pas spécialement nouveau, il me semble bien que ça fait plusieurs années que ça existe tout ça. En tous cas je viens de tester, ça marche parfaitement bien. Jacques.

Essaie en rajoutant <param name="wmode" value="opaque"></param> avant le <embed...> et wmode="opaque" dans le <embed...> Jacques.

La partie récupération du titre ou de la description est relativement facile. Il suffit de: - récupérer la page. Plein de méthodes pour ça en php, la plus simple étant probablement file_get_contents, mais si tu veux récupérer les headers (ce qui est indispensable, voir ci-dessous) ça va être un peu plus compliqué (fopen + stream_get_meta_data). - interpréter le contenu de la page, l'idéal étant d'utiliser un vrai parser HTML, mais une paire de regex bien senties font l'affaire dans la plupart des cas. Ne pas oublier de vérifier le charset dans le Content-Type (dans les headers et/ou le meta http-equiv) et de convertir l'encodage comme il faut, et de gérer les entités HTML (&machin;) évidemment. Pour le screenshot, c'est nettement plus compliqué, puisqu'il faut un moteur complet de rendu HTML (+CSS +JS +Flash +plein d'autres choses). Effectivement la plupart des sites utilisent des solutions externes telles que citées par KaRaK (il me semble qu'il y en a encore une ou deux autres). Pendant longtemps c'était assez tordu à faire, il me semble que récemment il y a eu des progrès de ce côté et qu'il y a un moyen de linker le moteur de rendu de FF (ou est-ce Konqueror?) à travers une librairie, mais ça reste quand même non trivial, et si la partie "je récupère le titre de la page" te paraît compliqué, tu peux probablement oublier tout de suite... Jacques.

Moi je n'utilise pas OSCommerce, mais je passe sans problème tous les accents que je veux à Paypal et retour... Comme je disais précédemment, ce que tu obtiens est le signe qu'il y a déjà (au moins une) conversion incorrecte avant. Remplis un panier, et sur la page où se trouve le bouton de paiement Paypal, regarde le code HTML pour voir déjà quelle gueule ont tes accents dans les <input type="hidden"...> générés, et si ça correspond à l'encodage que tu indiques à Paypal et à l'encodage de la page (évidemment il faut que tu soies en mesure de contrôler l'encodage utilisé pour l'affichage de ton HTML). A mon avis tu vas te rendre compte que ce n'est pas vraiment ça. Je suppose évidemment que par ailleurs sur le site les accents fonctionnent bien, et qu'on peut donc au minimum supposer que php, mysql, oscommerce, les templates, etc. sont tous d'accord sur l'encodage. Jacques.

Utilise plutôt <em> ou <b> qui sont faits pour ça (surtout le premier), ou fais-en des liens. Jacques.

Tiens, je viens d'aller voir sur le site de l'INPI, et j'ai peut-être tout faux, tu peux déposer un "dessin ou modèle", mais il y a pas mal d'exceptions (en particulier on ne peut pas protéger "Un dessin ou un modèle qui porte sur un programme d’ordinateur"). Je te conseille de consulter le site de l'INPI pour plus de détails... Jacques.

Pas un spécialiste, mais je dirais que non. Tu peux déposer une marque pour ton logo, éventuellement pour une couleur (mais là c'est quand même super chaud). Pour le design, pas de dépôt de marque a priori, mais ça reste protégé par la législation sur le droit d'auteur. En cas de besoin, il te reste à prouver que tu es l'auteur du design en question, ce qui va de la conservation des ébauches, fichiers sources, photos non traitées, etc. au dépôt chez un huissier ou un notaire en passant par l'enveloppe Soleau et la classique lettre AR adressée à soi-même qu'on n'ouvre pas et qui contient le design en question. Jacques.

Paramètre, variable, c'est la même chose ici. Tu rajoutes tep_draw_hidden_field('charset', 'UTF-8') . là où il faut... Jacques.

Sinon il doit être possible de partir du code phpmyadmin pour faire ce que tu veux. Avec un peu de chance le code est structuré de telle façon qu'il y a juste une fonction ou deux de leur code à appeler sans aucune modif... Jacques.

http://www.cygwin.com/ Jacques.

Commence déjà par rajouter le paramètre charset=UTF-8 (ou autre charset utilisé) dans les paramètres passés à Paypal... Ce que tu obtiens (¿œ, mais plus vraisemblablement ï¿œ qui est l'encodage UTF-8 du "replacement character" affiché comme de l'ISO-8859-1) semble indiquer qu'il y a plus de problèmes que ça, i.e. tu dois déjà avoir quelque part une conversion incorrecte. Jacques.

Ah je n'avais pas saisi que ce n'était pas pour ton usage propre. Tu peux peut-être y arriver en créant un compte avec des droits plus limités, mais c'est vrai que ça doit compliquer l'interface pour pas grand chose. Tu peux semble-t-il faire un lien directement vers l'édition de la bonne table dans la bonne base, ce qui pourrait convenir? Jacques.

Je n'utilise ni php ni mysql dont je ne le jurerais pas, mais phpmyadmin ne permet pas de faire ça? Jacques.

http://fr.wikipedia.org/wiki/Liste_de_systèmes_de_gestion_de_contenu#SGC_ne_n.C3.A9cessitant_pas_de_base_de_donn.C3.A9es Sinon, dans ton cas, ça doit probablement pouvoir se faire en quelques dizaines de lignes de php... Jacques.