Anonymus

.... Calmes toi, ca n'est pas la télévision, ici. Prends les éléments les uns après les autres et pas tout en même temps, prends le temps de lire ce qui t'es répondu, prends le temps d'étudier les ressources qui te sont envoyées, Le web ne s'est pas fait en un jour, il te sera difficile d'apprendre tous les langages d'ici la fin de la semaine. A la question ' Par quoi commencer', la réponse est simple : le Html. Ensuite, lorsque tu lis une documentation html, tu y verras des références à d'autres langages. poursuis tes lectures sur ces autres langages, apprends y au moins l'origine, le principe, et approfondis au besoin. Le prinicipal soucis lorsque l'on s'attache à " tout sur tout ", c'est que l'on en oublie bien souvent l'essentiel..

C'est probablement la pire des solutions, sachant que le fisc et les services sociaux ont l'oeil sur ce genre d'associations qui se repère assez facilement en général ( mais c'est bien tenté )

Tu penses vendre des librairies javascript. Tu sais qu'il est extremement difficile de protéger ses sources, et qu'il y a de fortes chances que le programme que tu vendra une fois se retrouve sur 50 sites en peu de temps. Penches toi sur ce problème, surtout si ton modèle économique tiend là dessus. Sinon, pour ton problème de structure juridique : tu peux très bien faire du commerce en faisant du B2B. L'un n'empèche pas l'autre. A priori, il n'y a pas de notion de droits d'auteur pour les programmes. Tu créées, tu vends, c'est du commerce.

L'un n'empèche pas l'autre. Tu achètes un magazine sur Linux. La plupart regorge de CD avec installation du trio php/mysql/apache (LAMP), et la doc est (presque) toujours avec. D'un coté tu auras la doc en livre, et de l'autre la doc en ligne. J'ai potassé un livre pendant pas mal de temps, et le jour où j'en ai eu marre de rassembler les pages (qui ne manquaient pas de se détacher), je suis passé à la doc en ligne complètement Pour cela, d'ailleurs, tu as l'embarras du choix, il y a quantité de docs, pour tous les sujets, tous les langages, accessibles à tous les niveaux. C'est l'un de ses grands avantages. Sinon, si tu veux faire un exercice 'facile', pour débuter, tu peux commencer par un cas d'école : faire un forum simple, en php et mysql. Si en plus tu y arrives en css et tableless, c'est mieux Pour commencer, comme le dit si bien Dan, tu prends une feuille blanche, et... c'est parti

Bonjour, installer aspseek pose pas mal de problèmes lorsque l'on ne maitrise pas "l'administration serveur". Tu peux essayer avec mysql, mais encore faudrait il que ton système d'exploitation le permette. Quel est il ? Qu'as tu d'installé dessus ?

Première ébauche du php: <?php $jour =$_GET['jour']; $mois =$_GET['mois']; $années =$_GET['annee']; $id =$_GET['id']; (je ne ne connais pas fonction php donc je met en html) <a href=http://vigi.netboxdata.com/vigigraph.php?id=kmfa2etovfxbx5ouzz2k&vigid=5&jour="$jour"&mois="$mois"&annee="$années"> pas vraiment. En fait, il te faut d'un coté récupérer les valeurs, et de l'autre les réécrire pour l'url en question. <?php // on récupère $jour =$_GET['jour'].; $mois =$_GET['mois'].; $année =$_GET['annee'].; $id = $_GET['id']; ?> éventuellement là, on transforme les données (si $annee est l'année prochaine, ca donnera ceci : <? $annee = $annee+1; ?> Enfin, on affiche l'url : echo "<a href='http://vigi.netboxdata.com/vigigraph.php?id=".$id."&jour=".$jour."&mois=".$mois."&annee=".$annee.">l'annee prochaine</a> "; Un morceau de code pourrait donc être : $jour =$_GET['jour']; $mois =$_GET['moins']; $annee =$_GET['annee']; $id =$_GET['id']; echo "<a href='http://vigi.netboxdata.com/vigigraph.php?id=".$id."&jour=".$jour."&mois=".$mois."&annee=".$annee."'>cette année</a> "; $annee = $annee+1; echo "<a href='http://vigi.netboxdata.com/vigigraph.php?id=".$id."&jour=".$jour."&mois=".$mois."&annee=".$annee.">l'annee prochaine</a> "; Tu remarqueras une erreur, je te laisse la trouver (pour info, les dates se gèrent avec la fonction 'date' )

Imagines que demain, tu ais besoin de mettre une section 'membre' sur ton site ? Tu va reprendre toutes tes pages, une à une, et leur incorporer le formulaire qui permet d'identifier les membres ? Si tu as 10 pages, on peut dire que ca peut aller vite. Si tu en as 10 000 ca ira moins vite. Mais de manière générale, à moins que tes 100 pages soient toutes exactement différentes, sinon tu as tout intéret à les faire en php. A partir de là, tu n'es pas obligé de faire toute la page en php. Mais essaies au moins de découper le contenu des pages, et de les mettre dans des fichiers différents, essaies de mettre le contenu des variables récursives dans un seul et même fichier, et n'oublies pas de mettre l'extension ".php" à tous les fichiers. Ca sera fait pour la prochaine fois.

Tu devrais séparer le code du formulaire et de l'image

Ca m'arrive de temps en temps, lorsque je sauvegarde, modifie la page en cours, et resauvegarde avant qu'il ait eu le temps de finir la première sauvegarde. La seule chose à faire, qui soit assez rapide, c'est de : - copier/coller le texte dans une autre page (on n'est jamais assez prudent.. ) - fermer la fenètre en cours (oui, je sais, encore 2 fenètres d'alerte...) - rouvrir la fenètre, - coller le texte précédemment copié sur une autre page. Autrement dit, quand je veux éviter ce genre de manips, j'évites les 'accès en lecture/ecriture' sur un fichier trop rapidement. Il faut bien qu'il sauvegarde A mon avis, il n'y a pas grand chose à faire, sinon développer le plus possible en local, (oui, je sais, c'est pas toujours facile..), et taper moins vite j'ai pas d'autres solutions (mais je suis intéressé s'il y en a une !! )

.... de là à dire que les hackers vont sauver le monde, il y a une marge.... A mon avis, ce sont des passionnés qui cherchent des failles là où elles sont. Un peu comme les mots croisés. On fait des mots croisés pour le plaisir de se creuser les méninges, tout simplement. A coté de ca, je crois que tout le monde est d'accord pour dire que les pirates font ce qu'ils font pour le profit. Attention cependant à ceux qui jouent sur les 2 fronts. Un coté 'white', pour se donner bonne conscience, et un coté 'pirate', parce que l'espèce humaine est ainsi faite

Bonjour, Tu ajoutes un pointeur, que tu incrémentes à chaque passage, et quand il est à 10, tu arretes la boucle. <?php $fp = fopen("fichier.php", "r"); // lecture de la page $compteur=1; while (!feof($fp)) { //on parcoure toutes les lignes (ce que je veux c'est seulement 10) if($compteur==10)break; $compteur++; $page .= fgets($fp, 4096); // lecture du contenu de la ligne } $titre = eregi("<p>(.*)</p>", $page, $regs); //on isole le titre echo '<p>Texte choisi : '. $regs[1] . '</p>'; fclose($fp); ?>

Dans le même genre, je citerais les innombrables pages de statistiques automatiques, qui montrent non seulement les pages du site, mais également les pages de l'admin...

A mon avis, prends le problème à l'envers. Qu'existait il avant le xhtml ? Le html. Or celui-ci n'etait pas assez souple, et ne répondait pas aux besoins. Ils ont sorti le xml et les balises qui vont avec, c'est à dire le xhtml. Mais... ce ne sont que suppositions

Bonjour, Tu peux être plus précis quant à l'erreur ? Que dit il précisément, s'il te plait ? Merci.

Par définition, je dirais : Tout dépend de ce que tu veux en faire (D'où ma question : pour en faire quoi ? )

Le problème du cloaking, dans ton cas, est qu'il faut suivre de très très près les robots. Ils changent de user agent, voire même d'adresse ip, et à moins d'être un afficionados des google et consors, tu te retrouveras très rapidement avec ton annuaire indexé complètement. A mon avis, tu devrais gérer distinctement 2 types de pages. les pages des personnes qui veulent bien être dans l'annuaire, et celles des personnes qui ne veulent pas. A partir de là, tu peux blinder la partie ne devant pas être indexée, à partir de robots.txt, de noindex, etc.. Sinon, ton annuaire est à la merci du web, et ce, très rapidement. De manière générale, si tu veux tout de même poursuivre ton idée de cloaking, tu devrais à mon avis en faire un 'à l'envers', à savoir tout refuser, puis laisser ensuite l'indexation qu'aux moteurs dont tu as reconnu expressement le user agent (ou l'ip).

Tu vas y passer 2.5 secondes si tu script est codé normalement

Pour phpdig, tu devrais créer ta base en local, et ensuite donner le nom de la base créée à phpdig. De plus en plus les scripts opensource empèchent la création de la base, pour éviter les problèmes.

Ton problème n'est pas résolvable. Tu dis que l'image n'est pas sur ton serveur, mais sur un fenètre de paiement sécurisé. Tu ne peux pas lire les clics ou autres évènements sur cette fenètre. Et les seules 'magouilles' possible te seront totalement interdites par le gestionnaire du paiement sécurisé. Même si ton intention est louable, ils te refuseront catégoriquement la possibilité de lire leur image et les clics qui sont faits dessus.

A priori ca sert dans le cas où l'on place plusieurs boutons sur la page !? (quoique...) Peut être que le bouton a été créé pour servir aussi à autre chose (coordonnées envoyées par gps ? )

tu as une page d'exemple, s'il te plait ? Ca ressemble à un problème de guillemets...

Voilà, c'est ca ! En gros, quand tu as une base de données d'un coté, et un programme de l'autre, mais pas sur le même serveur. Le programme ne peut accéder à la base de données, (pour une raison ou pour une autre, disons... question sécurité, quoi..), alors le serveur où se trouve la base de données envoie les données par flux xml. Ce qui intéresse le programme, c'est le contenu : les textes, les identifiants, et tout ca. Il se fiche de recevoir des balises html, puisque c'est lui qui va les poser. En xml (si c'est bien fait ! ) il ne recoit que le strict minimum, à savoir le contenu. Ca lui permet de recevoir les données très rapidement, et de faire comme s'il était connecté à la base directement. On trouve enormément de xml chez les affiliations, par exemple. L'affilieur envoie les informations en xml, et l'affilié affiche la page avec la présentation qu'il veut. Mais on peut aussi trouver du xml pour certaines transactions hautement sécurisées, où le programme n'a pas le droit d'accéder à la base de données (par exemple les transactions en ligne se font en xml bien souvent). Tu peux de la même facon te faire un site entièrement en xml, et l'afficher en html (par exemple..) A quoi te servira donc de faire ton site en xml puis de l'afficher en html !? En fait, le xml sert pour les applications courantes du web (affiliation, transactions sécurisées,...), mais il/elle sert aussi à ne créer qu'une seule version des 'données' d'un site, et à l'afficher suivant la demande, en html, en pdf, en .txt pour l'imprimante, pour le pda, pour... etc.. Bref, de la même facon que le xml sert à transmettre des données entre 2 serveurs, il sert aussi pour un seul et même serveur, à afficher les données en fonction de la demande. Pour finir, ca peut aussi servir à séparer le contenant du contenu. Dans certains cas, une équipe travaille sur le code pendant que l'autre travaille sur le design. En réalisant l'ensemble en xml, tu partages le travail, et tu permets aux 2 équipes de travailler séparément. Le résultat s'assemblant à la fin du projet. Anonymus.

A défaut de faire un calendrier rapide, tu vas nous faire le premier benchmark à destination des pc de webmasters !! [troll] Vincent, c'est bien connu que IE est plus rapide que ff [/troll]

Tu as peut être d'autres problèmes ailleurs, tels que des requètes qui génèrent beaucoup de ressources au niveau mysql, ou trop de requètes mal optimisées, ou je ne sais quoi encore. Comme le suggère Dièse, jettes un oeil aux logs, aux graphes mrtg pour savoir de quoi il en retourne, parce que ca me parait aussi beaucoup, comme 'matériel', pour si peu de personnes... Regardes aussi si tu as beaucoup d'images, de flash, des pages trop lourdes, etc.. on sait jamais..

Je tempererais : Interdire formellement les accents, les noms trop longs et les espaces. (dans l'ordre que tu veux ) Les dossiers vides, c'est plus ou moins au cas par cas, ca peut s'avérer indispensable. Nettoies ton programme, tes dossiers, tes fichiers. ne laisses pas trainer les test.php, ou truc.bak ou autres fichiers dont tu ne sauras plus, dans 6 mois, ce qu'ils pouvaient bien dire... Prends une convention de nommage (mais.. où sont elles ??) et respecte là. De manière générale, il y a bien 36 manière différentes de coder un programme. Mais il n'y en a certainement pas plus !! On retrouve toujours les mêmes facons de coder Si c'est ton premier projet, ben.. essaies de faire au mieux, et prends notes de tes erreurs, et essaies de voir 'pourquoi' comme ceci et pas comme cela, etc.. A force, tu trouvera facilement un certain rythme, une certaine harmonie dans ce que tu fais J'ajouterais : Tant que c'est simple pour toi, c'est simple pour la machine. Si c'est compliqué pour toi, ca le sera aussi pour la machine. Elle aime l'ordre, la logique, et..... s'y retrouver. Fais de même