captain_torche

Marvin : si pour toi il est cohérent de séparer contenu et présentation en XHTML, un débutant qui te lirait, ne ferait pas forcément le rapprochement. (Oui, je suis un p*%£* de chipoteur). D'autant plus que faire un site full-css (donc avec une séparation contenu/présentation), n'est pas limité qu'à l'emploi du XHTML.

Sémantiquement, une liste <dl> devrait être utilisée pour un glossaire, non ?

C'est utile quand ton visiteur n'utilise pas le même jeu de caractères que toi. Ca lui évitera d'avoir des petits carrés (ou pire, des lettres erronées), à la place de tes caractères spéciaux.

Je corrige MarvinLeRouge : on peut faire du design tabulaire en XHTML valide (passé au validateur), comme on peut faire un site full-css en HTML. Sinon, effectivement, il a été d'usage pendant longtemps d'utiliser les tableaux pour faire la mise en page. Mais tout le monde, ici, te déconseillera cette méthode, trop rigide, peu accessible et trop lourde. Tu peux arriver au même résultat en utilisant du code CSS (qui, tu le verras, a beaucoup d'avantages). Comme tu commences à apprendre, je pense que tu ne verras pas d'inconvénient à faire machine arrière. Pour apprendre quelques bases en (X)HTML/CSS, je te conseille de jeter un oeil sur le site du zéro. (Petite digression : J'ai lu, au détour de quelques pages du forum, que certains déconseillaient le site à cause de certains mauvais choix. Qu'en est-il exactement ?). Sinon, pour ton souci d'image, il faut d'une part que ton image se situe dans le même répertoire que la page qui l'appelle (en tout cas, de la manière dont tu l'appelles). Et, comme le dit Marvin, le fait d'avoir des espaces (ou des caractères accentués, ou spéciaux) dans le nom d'un fichier (image, archive, page ...), peut être source de problèmes. Si tu ne veux pas coller tes noms de fichier, tu peux utiliser _ ou - comme séparateurs.

Ben, le souci, c'est que si tu veux sous-traiter la modération, il faudra payer une (ou plusieurs) personnes, ça va revenir assez cher (salaire du/des modérateur(s), plus bénéfices de l'entreprise traitante). Dans le cas du forum d'un site énorme, ça peut se justifier, mais on peut limiter les coûts en embauchant soi-même les modérateurs.

Si par ta demande, tu dis "Est-ce qu'un internaute, venant de la page A, peut faire indiquer à son navigateur qu'il vient de la page X", je réponds oui. Dans le cas contraire, tu n'es pas très clair

Et comment envoies-tu le mail ?

Pas besoin de session pour ça, il suffit juste que tu exploites la valeur du referer de la page : <?php if($_SERVER['HTTP_REFERER'] == 'http://www.tonsite.com/page-a.php') include('page-b.php'); else include('page-c.php'); ?> Mais cette solution n'est pas valide si la page A est une page accessible théoriquement uniquement par les membres inscrits : le HTTP_REFERER est une valeur envoyée par le navigateur, donc aisément modifiable. Si tu veux vérifier qu'un membre s'est bien logué avant d'accéder à lapage B, il est nécessaire d'utiliser les sessions.

Personnellement, j'utilise la pagination (quand elle est présente), sinon le calendrier (et/ou la pagination du calendrier). Je ne consulte que très rarement les archives.

Je résume les recherches effectuées en mp avec yokito, pour ceux qui s'y connaissent plus que moi : abc systems : SARL fondée le 14/10/05 (enseigne abc systems) Nom de domaine www.abc.com déposé en Mars (si je ne m'abuse), non actif à ce jour. Mr XXX - abc : affaire personnelle fondée en décembre 2005 (enseigne abc) Nom de domaine www.abc.fr déposé en février, actif à ce jour. Les activités des deux entreprises sont les mêmes (installation de matériel domotique) Je n'y connais pas grand chose, mais j'imagine que la création d'affaire personnelle en relation avec le site abc.fr, autorise la personne en question à exploiter le ndd abc.fr.

Si ton formulaire utilise la méthode POST, l'ensemble de tes variables définies par un champ 'name' dans tes INPUT, est envoyé à la page de résultats, sous la forme d'un tableau (array), nommé $_POST. Dans cette page de traitements, tu peux exploiter ce tableau de valeurs, de la manière que tu veux. Un peu de doc : La gestion des tableaux en PHP.

Es-tu sûr que le transfert de ces images se soit bien passé ? Il y a des chances que non.

Si la structure de tes champs ENUM est inamovible (ça peut arriver), tu peux les mettre 'en dur' dans ta page HTML. Sinon, s'ils sont susceptibles d'être modifiés, une première interrgoation de la base sera nécessaire, pour renvoyer les différents ENUM.

Déjà, le dossier upload/gallery existe t'il ? Si oui, je ne vois pas d'où peut provenir le souci. Si non, il peut s'agir d'une redirection par .htaccess

Hé, faut que je me réveille le matin, moi ! Deux jours de suite que je laisse passer des erreurs comme ça

Je vois déjà plsusieurs erreurs de conception. D'une part, lorsque tu recherches si le pseudo existe déjà, ta requête est celle-ci SELECT COUNT(*) AS nbre_entrees FROM membres WHERE pseudo='$pseudo1' AND mot_de_passe='$mot_de_passe1' Cette requête ne te retournera une réponse, que s'il existe un enregistrement avec le même login ET le même mot de passe. Pour faire ce que tu recherches, vérifie juste l'existence du login. Sinon, il n'est pas nécessaire d'enregistrer le mot de passe de vérification (vu qu'il est censé être le même que le mot de passe normal). Le principe est juste de tester l'égalité avant d'enregistrer en base : if($_POST['mot_de_passe'] === $_POST['mot_de_passe_verif']) { // suite du code } Et, pour finir, je te conseillerai plutôt de passer le HTMLentities sur les champs à l'affichage, et non à l'enregistrement. Tout simplement parce que si tu veux permettre la modification des champs, le HTMLentities compliquerait grandement la chose. Pour donner la structure de la table, tu as une option 'exporter', dans PHPMyAdmin.

Ben, si j'ai bien compris, il n'est pas nécessaire de passer le contenu en tableau, puis de le reserializer, puisqu'ils sont déjà séparés par des virgules dans le cookie. On aurait donc : if($_COOKIE['nom']) $req = mysql_query("SELECT * FROM tatable WHERE tonchamp IN (".$_COOKIE['nom'].")");

En fait, techniquement, Opera t'affiche bien les menus, mais il affiche invariablement l'iframe par-dessus. Et il n'y a, à ma connaissance, aucun moyen de contourner ce 'bug' d'Opera. Ce que tu peux faire, par contre, c'est utiliser un code CSS qui fera exactement la même chose que ce que tu recherches (contenu scrollable dans une partie du document). Dans ton HTML : <div class="iframe"> Ton contenu </div> et, dans ton CSS : .iframe { width: 626px; height: 420px; overflow: auto; }

Je ne suis pas juriste (ni n'ai aucune compétence dans le domaine), mais je pense que si le terme 'abc' n'est pas trop usité (si ce n'est pas un nom commun, par exemple), et que tu peux prouver qu'il peut y avoir spoliation de clientèle (noms ressemblants, même activité, etc), ça ne posera pas de soucis. As-tu regardé dans les registres de sociétés, pour savoir depuis quand cette entreprise existe ? Et, pour finir : pourrais-tu me donner les noms des sites en mp ?

Effectivement, je dois pas être bien réveillé Merci de m'avoir corrigé.

Déjà, pour lire le fichier, il faut utiliser un langage spécifique (par exemple le PHP). Tu dois avec ce langage, ouvrir le fichier, lire son contenu, et séparer les chiffres des virgules (J'espère pour toi que tu utilises le point pour les décimaux, s'il y en a). En php, ça pourrait donner ça : <?php // Le code de connexion à ta bdd // Ouverture du fichier, récupération de son contenu $filename = "chemin_vers_ton_fichier.txt"; $handle = fopen ($filename, "r"); $contents = fread ($handle, filesize ($filename)); fclose ($handle); // Séparation des chiffres, et organisation dans un tableau $tab = explode(',', $contents); // boucle effectuant la requête pour chaque élément du tableau foreach($tab as $chiffre) { $req = mysql_query("SELECT * FROM tatable WHERE tonchamp = $chiffre"); // Suite du traitement } ?>

Ce n'est pas ta requêtre d'INSERT qui ne fonctionne pas, apparemment. On pourrait avoir plus d'infos sur la construction de ta table ? Et sur la requête servant à l'identification ?

Si j'ai bien compris, le souci ne vient pas du formulaire d'inscription (vu que les données sont déjà présentes en base), mais plutôt de celui de modification. Tu dis que tu appliques un HTML entities sur tes données. Tu le fais AVANT l'entrée en base ? Si c'est le cas, je te le déconseille fortement : - tu enregistres des valeurs supplémentaires dans ta base (donc tu l'alourdis) - tu empêches une modification simplifiée (tu dois auparavant faire un html_entity_decode sur toutes les valeurs pour les afficher dans les champs nécessaires) - Tu t'empêches également d'appliquer des fonctions d'affichage par la suite (BBCode, etc). L'idéal étant d'enregistrer les valeurs textuelles dans ta BDD, après les avoir transformées avec mysql_real_escape_string (pour éviter les injections SQL). Sinon, comment se passe la recherche d'informations quand on veut modifier sa fiche ? Sur quels champs te bases-tu ?

A mon avis, il vaut mieux éviter de conseiller à un internaute de changer de navigateur, pour consulter un site : D'une part, parce que s'il l'utilise, c'est qu'il y est attaché (il ne connait que lui, ne veut pas changer ses habitudes, tout ça) D'autre part, parce que si le visiteur n'a pas un intérêt VITAL à consulter ce site en particulier, il va très vite quitter ce site. Et surtout parce que, pour un webmaster, le but est de faire un site accessible aux navigateurs les plus courants, dont (et surtout) IE6.

Heu, non, c'est juste une liste <ul>, dans un <div> tout bête.