jcaron

Pourquoi tu ne pourrais pas en tant qu'auto-entrepreneur? Il faut par contre que tu choisisses le bon statut, tu fais évidemment du commerce. Pour le reste, tu commences par dire que tu vas faire la livraison toi-même, ensuite que c'est la Poste qui va la faire, difficile de t'aider... Jacques.

Un POST c'est normalement prévu pour une requête qui va faire des modifications, pas pour récupérer des données. On en abuse souvent parce que ça permet d'envoyer plus de données qu'un GET (où toutes les données envoyées doivent tenir dans l'URL), mais dans ton cas il me semblerait logique d'utiliser un GET plutôt qu'un POST, non? De façon générale, les moteurs ne vont pas trop suivre les POST. Il fut un temps il ne le faisaient jamais (parce qu'un POST peut avoir un "effet", alors qu'un GET ne devrait pas en avoir), mais Google (et peut-être d'autres) commence à le faire quand ils pensent que ça ne pose pas de problème, et qu'ils ont une idée de ce qu'on peut bien mettre dans les différents champs (i.e. des selects, pas des champs de texte...). Dans ton cas, je ne compterais pas dessus pour du référencement, si tu veux que la page de destination soit référencée, il va falloir prévoir des liens "normaux" vers ces pages. Au final, ta RewriteRule ne serait donc pas top utile... Jacques.

Chez moi, sur base de MIME::Lite, ça se finit comme ça: my $string = $msg->as_string; $string =~ s/(\r\n|\r|\n)/\r\n/g; (... ajout de la signature DomainKeys ...) open my $sendmail,"|/usr/sbin/sendmail -t -oi -oem -f $sender" or die "can't start sendmail: $!"; print $sendmail $string; close $sendmail; Il faut dans ce cas de figure que l'utilisateur qui envoie les mails figure dans la classe "t" (trusted) de sendmail, je ne sais pas de tête où l'équivalent se configurerait dans postfix (et quelles options il faut passer). Pour une raison ou une autre je ne fais pas l'envoi en SMTP directement. Mais de façon générale MIME::Lite c'est la prise de tête dès que tu as du texte qui n'est pas strictement 7 bits, ça oblige à faire toutes sortes de contorsions :-( Jacques.

La première solution est très très très très très certainement beaucoup plus efficace que la deuxième (si bien sûr tu as l'index qui va bien sur la table). Le unserialize(file_get_contents()) à lui tout seul doit coûter plus cher que la requête SQL, et je ne te parle même pas de la boucle sur le tableau pour chercher l'id. Jacques.

Si je comprends bien, c'est une vérification que tu veux faire lors de certaines requêtes sur ton site (par opposition à vérifier tout ça d'un coup une seule fois)? Je ne sais pas à quel "cache" tu fais allusion, mais s'il s'agit de générer un source php qui correspond au contenu de la table, alors le temps de charger, parser et interpréter ce source risque d'être nettement plus long et plus couteux en ressources que de faire une requête SQL. L'option idéale si tu as vraiment beaucoup de requêtes ce serait d'utiliser un cache comme memcached (avec une entrée par ligne). Une autre option consiste à utiliser un fichier type GDBM ou équivalent (histoire de bénéficier de l'index qui va avec). Mais sinon la requête SQL ne devrait pas être trop problématique. Jacques.

C'est tout petit comme base ça, tant que tu as un index qui intègre correctement l'année ça ne devrait vraiment poser aucun problème. Je ne sais pas si des produits/catégories restent d'une année à l'autre, mais si c'est le cas, une table catégories, une table produits, et une table de jointure (colonnes: année, id catégorie, id produit) pourrait être une bonne solution... Jacques.

Tu vas probablement vite te rendre compte qu'il manque pas mal de choses dans ta structure. En particulier, les catégories ont souvent besoin d'une hiérarchie plutôt que juste une liste, un produit peut souvent être dans plusieurs catégories (et/ou une catégorie peut être dans plusieurs catégories "mères"). Ce n'est pas beaucoup plus compliqué, mais ça ajoute une paire de tables. Concernant ta question, tu ne nous donnes aucune indication du nombre d'articles/catégories. Avec des index correctement établis (et utilisés), la taille de la base de devrait cependant pas changer grand chose. Jacques.

Le premier point c'est avant tout de s'assurer que ton jeu ne tombe pas sous le coût de l'interdiction des jeux de hasard. C'est le cas s'il réunit les 4 éléments suivants: - le jeu est ouvert au public (oui) - il y a une participation financière (oui) - il y a quelque chose à gagner (oui) - il y a intervention du hasard, même à titre accessoire Un "concours" avec une question simple et ensuite un tirage au sort pour départager les ex-aequo rentre dans cette catégorie. Deux solutions pour ne pas tomber dans cette catégorie: - que la participation puisse se faire gratuitement (par le biais d'un remboursement des frais de participation, y compris des frais de demande de remboursement) - ou qu'il n'y ait absolument aucune intervention du hasard, mais uniquement appel aux compétences des participants (connaissance, rapidité, etc.). Au delà de ça, tu fais ce que tu veux. Cependant, le fait de payer pour participer au concours en fait vraisemblablement un service, ce qui t'oblige à avoir un statut adapté. Jacques.

Je pense que tu risques d'avoir du mal à trouver un seul fournisseur en dropshipping pour une si large gamme de produits, donc ça risque de ne pas être très facile à gérer. De plus, vu la faible adéquation entre les produits et les visiteurs (puisque tu as des visiteurs étalés sur une très large gamme, mais une très petite gamme de produits à vendre), tu ne vas pas avoir des volumes très importants à mon avis. Ca risque d'être difficile à gérer, et en plus, ça va être difficile d'avoir des prix réellement intéressants, ce qui diminue d'autant ton taux de transfo (d'où un cercle vicieux). Mon expérience perso sur des produits multimedia c'est qu'Amazon vend souvent moins cher que les distributeurs ne vendent aux revendeurs (sur les consoles par exemple), que les quelques dropshippeurs facilement accessibles (Pixmania pro) vendent comparativement très cher, et que les produits vraiment intéressants sont difficiles à se procurer. Ca peut être très différent dans d'autres secteurs, mais il va falloir que tu gères chacun séparément, ça fait beaucoup de travail... Jacques.

Si tu le fais au moment où tu reçois la requête, oui, ça peut être un peu lourd si le serveur d'origine ne répond pas très vite. C'est probablement une meilleure idée de stocker le referer en BDD, puis d'avoir un processus en tâche de fond qui va aller faire le boulot. Il y a plein de cas où ça ne va pas marcher: si le referer est bloqué par le navigateur, firewall, proxy, anti-virus, etc; si le referer n'est pas transmis (de mémoire si tu fais un window.open il n'y a pas de referer contrairement à un lien habituel); si la page où se trouve le lien est protégée par une authentification quelconque; si la page où se trouve le lien est fortement dynamique et basée sur autre chose que juste l'URL, en particulier s'il y a du contenu chargé en Ajax, si le contenu dépend des cookies, de la langue, de la localisation, etc; si le lien est construit dynamiquement (en JS) ou qu'il utilise un handler en JS plutôt qu'un simple <a href>, et j'en oublie probablement. Si tu ajoutes à ça le fait que ce n'est probablement pas une fonctionnalité très demandée (à part pour du SEO assez hard l'intérêt semble limité, non?), ça fait beaucoup de raisons pour ne pas le faire, mais rien ne t'empêche de le tenter. Suivant ta motivation, ton site, et les sites qui font des liens vers toi, ça peut être faisable quand même. Jacques.

Il faut commencer par récupérer le referer, ensuite récupérer la page correspondante (avec file_get_contents par exemple), puis idéalement un parser HTML, au pire une regex, pour trouver le lien et son contenu. Evidemment, un petit cache ou une table en BDD pour ne pas aller vérifier plusieurs fois la même page peut être utile. Note aussi que s'il y a plusieurs liens différents vers la même page de ton site, il ne sera pas possible de faire la différence entre ces liens (i.e. savoir lequel a été utilisé pour arriver chez toi). Jacques.

Je pense que ça aiderait beaucoup si tu précisais quel(s) type(s) de produits tu veux vendre... Les fournisseurs de smartphones et ceux de sous-vêtements ne sont pas forcément les mêmes... Jacques.

Tu peux tenter de contacter bookmyname.com (c'est le registrar de Proxad aka free) et leur exposer la situation... Jacques.

Ton hébergeur n'est probablement pas le registrar officiel du domaine, mais juste un revendeur d'un autre registrar (vérifie le whois de ton domaine qui te l'indiquera). Dans ce cas, il est (peut-être) possible de gérer le problème avec le "vrai" registrar (à condition bien sûr qu'ils aient correctement rempli les infos de propriétaire et de contact). Jacques.

...ET des pays de tous les utilisateurs ciblés... Jacques.

Je ne serais pas aussi catégorique... En tant qu'éditeur de site, le droit de ton pays de résidence (pour simplifier puisque personne physique) est applicable, ainsi que le droit du pays où tu es hébergé, ainsi que (au minimum) le droit du pays des utilisateurs que tu cibles activement (par de la pub, par une version adaptée à ce pays, par le choix de l'extension du nom de domaine par exemple), et dans le pire des cas, le droit du pays de n'importe quel visiteur de ton site. Quant à savoir si tu cours un risque "réel" dans l'un des différents cas (i.e. risque effectif de poursuites et/ou de conséquences réelles pour toi ou pour le site), c'est un autre souci. Mais tu devrais couvrir les bases applicables dans au moins les trois premières juridictions sus-citées, qui peuvent éventuellement être la même. Ceci étant dit, en termes de mentions légales, la France est probablement le pays qui en demande le plus... Jacques.

Si ça permet à n'importe qui de mettre du php dans un article qui sera ensuite exécuté sans aucune vérification, alors ça ne qualifie même plus de dangereux, c'est suicidaire. Je suppose et j'espère qu'il y a en fait des limitations... Jacques.

Tu peux utiliser eval(), mais lis-bien les avertissements dans la documentation, et assure-toi bien que les accès à ta base de données sont bien contrôlés, parce que sinon ça peut ouvrir des failles de sécurité énormes. Jacques.

En effet, j'avais lu un peu rapidement. C'est probablement une bonne idée que de demander confirmation aux impôts. Jacques.

Encore une fois, la page dont tu as donné le lien indique bien que l'exonération ne s'applique désormais plus qu'aux sociétés créées depuis le 1/1/2012 qui ont au moins un salarié qui bénéficie de l'exonération des charges patronales... Jacques.

Tu devrais relire la page dont tu as donné le lien, tout ou presque qui est indiqué. Note que cette page indique que seules les nouvelles entreprises avec au moins un salarié qui bénéficie de l'exonération des charges patronales peuvent bénéficier de l'exonération d'IS. Elle indique aussi que si tu n'es pas toujours sur place, tu dois soit avoir un salarié sur place, soit générer 25% de ton CA auprès de clients dans la ZFU. A propos des deux sociétés, ça me paraît compliquer beaucoup les choses, à moins que vous soyez complètement indépendants l'un de l'autre. Sinon il y aura forcément des refacturations entre les deux sociétés, ce qui va augmenter leurs CAs respectifs, ce qui peut affecter certains seuils ou taux à droite ou à gauche. En plus, c'est nettement moins clair pour les clients, et le jour où vous voudrez embaucher, ça ne va pas simplifier les choses... Jacques.

A priori, tu n'as pas compris les différents types de sociétés. Certaines sociétés (EI, SNC...) n'ont pas de personnalité morale, i.e. le (EI) ou les (SNC) dirigeants sont directement et personnellement impliqués (sans limite de responsabilité. Ils sont personnellement les employeurs des éventuels employés (donc, non, "par définition", on n'est pas forcément seul dans une EI... On est le seul dirigeant, mais on peut très bien avoir des employés). A l'opposé, les sociétés de capitaux (EURL, SARL, SASU, SAS, SA...) ont une personnalité morale (i.e. la société est une entité indépendante, les gérants/administrateurs peuvent être différents des actionnaires/associés). Un EURL n'est pas une EI. En gros: - sociétés de personnes: AE, EI aka SNP, SNC... - sociétés de capitaux: EURL, SARL, SASU, SAS, SA... Je ne comprends pas très bien l'intérêt de deux EURL si vous travaillez réellement ensemble, mais tout dépend des circonstances précises. Pour revenir au coeur de la question, la problématique est d'être bel et bien établi dans la ZFU. Il te font donc au minimum des bureaux sur place, et y travailler effectivement. C'est un peu comme une société offshore, sauf qu'au lieu d'être sous les cocotiers, elle est dans la zone. Ca inverse le travail du fisc, en gros, ce qui n'est pas forcément à ton avantage si tu n'es pas vraiment dans la ZFU. Jacques.

Il n'y a aucune différence entre cette requête et la précédente. Ce que te conseillait Dadou, c'est de faire le sub-select (le SELECT dans les parenthèses du NOT IN), récupérer les résultats, puis construire une deuxième requête en mettant la liste des references à exclure directement dans la requête. Bref, il y a deux requêtes, dont l'une est composée avec les résultats de la première. Sinon tu peux essayer ça: SELECT count(reference) AS nb_messages FROM (SELECT reference FROM table_1 WHERE createur != '$createur' EXCEPT SELECT reference FROM table_2 WHERE trouveur = '$createur') s Dans tous les cas, la présence d'un index sur table_2.trouveur pourrait beaucoup aider. Evidemment, on suppose que ton utilisateur de $createur directement dans la requête est un raccourci pour simplifier ton post, ou alors que tu vérifies de façon très stricte la valeur de $createur, sinon tu cours le risque d'une injection SQL. Tu devrais TOUJOURS utiliser mysql_real_escape_string, ou PDO pour éviter ce genre de problèmes. Jacques.

Tu as au moins Keyyo (français), mais aussi Tollfreeforwarding, et probablement des tonnes d'autres, suivant le type exact de numéro que tu veux. Jacques.

Donc ça veut dire que tu as un module genre mod_h264_streaming installé qui gère ça, et comme je le disais, il faut alors soit reproduire ce qu'il fait (ce qui est assez complexe, il faut aller lire plein de trucs dans le mp4), soit renvoyer vers lui, mais c'est a priori non trivial en php. Si tu utilises mod_php, tu devrais pouvoir utiliser virtual($fichier); à la place du readfile original. Sinon, c'est plus tordu, il faut probablement faire appel à un RewriteMap et modifier le script pour qu'il agisse comme un filtre qui lit les URLs avec token et répond les URLs des fichiers. Normalement un RewriteMap avec une règle dbd: doit pouvoir faire l'affaire aussi, mais je ne suis pas très sûr que ce soit parfaitement "safe" vis-à-vis des injections SQL. Jacques.