Anonymus

Le but du xml est simple : Offrir un meta langage simple pour communiquer entre 2 serveurs. Avant le xml, on envoyait des données (entre serveurs) en format csv, texte simple, sql, etc.. Bref, c'etait l'anarchie. Maintenant, avec le xml, c'est simple, on sait au moins quel est le format. Le problème du xml, c'est que.. chacun développe son xml Le second problème du xml est le protocole de transfert. Chacun y va de sa nouvelle invention pour envoyer un xml. Et tout y passe : POST, GET, SOAP, etc.. Bref, ca simplifie, sans pour autant être la solution qui regle le problème général.

Quelle est l'url de ta page ?

Bonjour, Es tu sûr que ca soit cette ligne qui ne marche pas ?

Bonjour, Pour le problème des blogs à plusieurs utilisateurs, tu en as un certain nombre, parmi lesquels wordpress-mu (pour mutualisé). Pour ton problème de créer un blog : Ne réinventes pas la roue. Les blogs fleurissent sur le net (enfin.. je parle des programmes de blogs). Pourquoi vouloir en refaire un ? Le temps que tu perdra à en faire un perso, tu pourrais t'en servir pour : - améliorer ton système flambant neuf, - aider le support de ce système de blogs, -... le passer avec ta famille etc.. Bref, je te conseille plutot de t'orienter vers un système tout fait, et de le développer, plutot que d'en créer un autre Si vraiment tu veux développer ton propre blog et y mettre toutes les fonctionnalités sympas, alors.. jettes un oeil aux différents sites de blogs, tu y trouveras suffisamment d'idées pour le développer

Sur le principe, Dan n'est pas une banque. Le service qu'il 'offre' est un service d'entreprise, et comme toute entreprise, il a des compte à gérer. S'il ne fait pas de paiement mensuel, c'est pour ne pas avoir tous les mois à sortir une facture pour '3 francs 6 sous', sans compter les problèmes récurents à courir derrière le client pour qu'il paie. Ceci dit, un site coute de l'argent, et parfois coute cher. Cependant, autant il coute cher, autant tu devrais, toi, penser à le rentabiliser. Sans cette équation, tu ne t'en sortira pas : - Ton serveur plante ? Autant de temps de perdu. - Ton backup plante ? Autant tout refaire de zéro. .. Dans tous les cas, l'infogérance fait partie de la prise de risque. Et la prise de risque est toujours en rapport avec l'argent perdu lorsqu'on l'a mal évalué. (Et le temps, c'est de l'argent, on a fait le tour..) 500, c'est cher pour un site qui ne rapporte rien, c'est beaucoup si on y a investi peu de temps, c'est peu si on y a investi beaucoup de temps, c'est peu s'il gagne beaucoup. A toi de voir.

Bonjour, Tu testes une variable que tu passes préalablement en minuscule. C'est ce qui t'oblige ensuite à envoyer des variables en minuscule. Enlève toute référence aux minuscules (dont le strtolower ici), et tu pourras chercher des majuscules Nico.

Bonjour, Tu as inversé les paramètres :

Bonjour, Remplaces le nom de tes variables, c'est plus que nécessaire En attendant, tu as toujours une solution de secours : Nico.

Fais la page avec les données que tu as déjà, et avec ce que l'on t'as dit, et reviens nous voir lorsque tu bloqueras sur un problème concret

Bonjour, Il n'y a pas de taille recommandée pour une base de données. Tout dépend de ce que tu as à y mettre. Par contre, il existe un certain nombre de recommandations, de choses à faire ou ne pas faire, pour éviter qu'elle devienne incohérente. Au hasard, par exemple, une donnée ne doit pas (ne devrait pas) se trouver 2 fois dans la base, sous peine de ne pas s'y retrouver. Tu as des articles, dans la partie 'publications' du hub, pour justement commencer du bon pied, avec les bases de données. (publications > lien dans le menu en haut.)

Ce sont les fichiers créés par le programme !? Créées un script php qui ira supprimer ces fichiers

Bonjour, Merci de nous fournir au moins les liens vers la doc Anonymus.

Il te faut un 'joker'. Tu peux élargir le champ de ta recherche, en sql, avec le sigle %%. Tu procèdes ainsi : SELECT champ FROM table WHERE champ LIKE '%test%' Là, tu auras comme réponse : 'un test', 'testAutreTest', 'CeciEstUnTestBien' Bref, ca te sert de joker, pour trouver un enregistrement, quand tu ne connais qu'une valeur approximative.

Tant qu'il y aura des sites qui laisseront des listes entière d'email, tu auras des robots pour les capter. De la même manière, tant que tu auras des formulaires avec soumission anonyme, tu auras des robots pour les remplir. Par rapport à ca, je trouve que, comme Dash, il faut savoir raison garder. Il y a un moment où l'on oublie le principal : permettre de poster. A vouloir mettre trop de captcha, on finit par ne plus permettre aux utilisateurs de se servir des formulaires. Or comme la plupart des formulaires hyper sécurisés n'offrent pas d'autres possibilité qu'un autre formulaire pour soumettre le problème, on tourne en rond. Combien de sites n'offrent pas la possibilité à un quidam de contacter l'administrateur dudit site ? Combien de forums obligent à s'inscrire pour pouvoir.... dire qu'on ne peut pas s'inscrire bien qu'on ne soit pas un robot !? Les captcha, c'est comme les anti virus : le meilleur anti virus, c'est la prise électrique. Pas de spam ? pas de formulaire

Il ne faut pas regarder l'extension, pour connaitre l'usage d'un fichier. L'extension n'est donnée qu'à titre indicatif. Tu peux faire des fichiers langue avec n'importe quelle extension. De quel programme s'agit-il ? (parce que néammoins, ce '.mo' me dit quelque chose..)

Ensuite, si tu mets ton adresse mail dans le formulaire, comme ca a l'air d'être le cas, ton adresse mail va se faire récupérer par des moteurs de recherche, et tu vas te faire spammer très rapidement. :/

Bonjour, Tout dépend de quelles facons ces données te sont mises à disposition. il existe pour cela quantité de protocoles différents. Si tu as accès à ces données directement depuis ton navigateur, par exemple, il te suffit de lire cela, ce qui donnerait : $data =""; $fp = fopen("le_site_en_question.com","r"); while (! feof($fp)){ $data .= fgets($fp,4096); } fclose($fp); echo $data;

Un groupe de casinos français demandait à être autorisé à mettre en ligne un (des?) site, arguant que ses conccurents étrangers sont présents (via internet) en France. Il (ce groupe) trouvait dommage d'être obligé de s'installer à l'étranger pour avoir les mêmes droits que ses conccurents.

Sugarcrm pourrait te convenir. Il se développe à grands pas, et possède déjà de nombreux atouts. Tu as le site en francais ici : http://www.crm-france.com/ et la version américaine ici : http://www.sugarcrm.com/

Mets le chemin complet, depuis la racine, tu t'y retrouveras plus facilement

Oui. Ce genre de fonctions sont extremement proches du système. Tu peux lancer, avec ca, toutes (enfin.. presque) les commandes shell basiques. Tu devrais protéger au maximum ton programme, notamment si possible en pré-déclarant tous les paramètres que ton programme pourra utiliser, et utiliser uniquement cette pré-déclaration. Ne fait surtout vraiment pas confiance aux données introduites par l'internaute, elles sont forcément corrompues

le htaccess de modx dit (en gros) qu'il faut tout rediriger vers le fichier index.php, qui se débrouillera. Seulement, en précisant /modx/, j'aurais tendance à penser que ca renvoie ) la racine du serveur. A ta place, j'essayerais comme ceci : RewriteRule ^(.*)$ index.php?q=$1 [L,QSA] En tout cas, ca marche sur mon localhost

Pour comprendre pourquoi ca ne marche pas, il nous faudrait le code html de cette newsletter

Quand tu enlèves les .htm et .html, il te reste 11 pages. Passer de 11 à 28000, c'est un sacré trou.. C'est vrai que ca justifie pas autant de pages indexées, ca procure uniquement du contenu..

Je suis un magicien !! Regarde ici : http://www.google.fr/search?hl=fr&q=si...oogle&meta= Tu prends le 2e résultat sur ton navigateur, après avoir désactivé javascript : Tu as une jolie page, bien présentée, etc, etc. En fait, tout le site est fait avec du cgi-bin. Or google a enregistré des pages en .htm.. Louche