captain_torche

Ne t'inquiètes pas pour tes ressources : si tu indexes les bons champs, tu ne devrais pas avoir de souci.

Je pense que c'est possible, en se basant sur l'article sur les .htaccess dispo dans les publications du hub, en l'adaptant un peu, pour qu'il bloque les mp3, et non les images. RewriteEngine On RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://www.votredomaine.net/.*$ [NC] ReWriteRule .*\.mp3$ - [F] Tiens-nous au courant, si ça marche (ou pas).

Et en les remplaçant par une valeur en 'em' ?

On va tenter de résumer : S'il s'agit de freewares, sharewares, ou gratuiciels, tu mets par défaut un lien vers la homepage de l'éditeur du logiciel. Tu peux envoyer un e-mail à l'éditeur, lui demandant la possibilité de faire un hotlink directement sur le fichier. S'il te répond par la positive, et seulement à ce moment, tu pourras lier directement le fichier depuis ton site. Mais cette méthode ne te met pas à l'abri d'une modification du site de l'auteur, rendant ton lien inutilisable. De même, si la version du logiciel ciblé change, soit il garde l'ancienne version (ton lien marche toujours, mais le logiciel n'est plus le bon), soit il supprime le vieux logiciel, et dans ce cas ton lien ne fontionnera plus.

Le meilleur moyen de le savoir, c'est de contacter l'auteur. Mais, sache que le lien direct, va lui pomper de la bande passante, sans que l'internaute sache chez qui il prend la ressource (il clique sur un lien venant de chez toi, et télécharge chez quelqu'un d'autre sans le savoir). Légallement et éthiquement, c'est une pratique douteuse, vu que tu spolies l'auteur d'une publicité somme toute justifiée, via son site. Donc, à moins d'avoir reçu l'autorisation expresse de l'auteur, fais juste un lien vers la home page du site.

Il n'y a pas de problème, si c'est un freeware, shareware, ou gratuiciel, à condition de citer l'auteur d'origine, etc. De plus, nombre d'éditeurs de logiciels refusent le lien direct vers le logiciel, il est raisonnable (et sensé), de faire un lien vers la page d'accueil de leur site.

Plutôt que de mettre le fichier sur ton serveur, tu peux faire un lien vers le site de l'éditeur : - tu ne risques rien (si tant est que le logiciel est un freeware, shareware ou gratuiciel) - tu économises de la bande passante - et ça ne change rien pour tes visiteurs

Que t'affiche t'il lorsque tu fais un echo de $_GET['id'] ? C'est bien $_GET['id'] que tu récupères dans ton second include ?

Et, comme l'ont déjà dit plusieurs membres ici : pour la plupart des gens créant et entretenant un site web, il s'agit d'une passion, ou d'un hobby, et comme n'importe quel hobby (ou passion), il faut admettre que ça engendre des frais. La simplicité apparente de 'rembourser les frais avec la pub', fait un peu oublier tout ça.

Si tu pouvais nous envoyer une capture d'écran, ça pourrait également aider.

Je t'ai donné le code du lien, dans le cas où tu le mettais directement en HTML. Comme tu le fais, tu as laissé les balises PHP, dans le code PHP, d'où l'erreur. Pour un lien dans un echo, comme tu le fais, il te suffit de faire : echo '<a href="index.php?page=page2&id='.$data['id'].'">'.stripslashes(htmlentities(trim($data['titre']))).'</a>'; PS : en analysant le code généré, ça aurait sûrement pu te mettre sur la piste.

Sinon, pour ton fomat de base ($typexx), tu peux utiliser cette forme dans ta boucle : if(${'type'.$i} != null)

Il te suffit de le mettre en second paramètre : <a href="index.php?page=page2&id=<?=$data['id']?>">page 2</a>

Plutôt qu'un array, imposant de retourner chacune des lignes de ta table correspondant à ta recherche, et d'effectuer par-dessus des calculs en PHP, pourquoi ne pas effectuer ce même calcul directement dans ta requête ? SELECT SUM(totalttc) AS Somme FROM comm_active WHERE user='$session'

Il faut considérer que personne ne surfe en plein écran C'est pour ça que je parle de 'compatible 800x600', etc.

Pour moi, 16% d'utilisateurs potentiels, c'est loin d'être négligeable. De plus, à partir de quelles statistiques se base le site en question ? Les siennes ? Dans ce cas, on ne peut pas certifier que 'mondialement, 16% des internautes surfent avec une résolution de 800x600', même s'il est vrai que ça démontre une certaine tendance.

Sinon, par rapport à la taille de l'écran, il faut encore savoir que nombre de personnes surfent encore en 800x600 (vieil écran, ou difficultés à lire sur une résolution plus élevée). Il faut donc prendre en considération le public visé par le site : Pour un site 'tous publics', il faut donc avoir une résolution compatible 800x600 (élastique ou statique), ce qui fait environ 770 pixels de large au maximum (et 430 de haut max si on veut éviter une scrollbar verticale). Si jamais le public visé possède une résolution au moins égale à 1024x768, une largeur maximale de 960px semble très raisonnable. Pour info, je développe tous mes sites en 'compatibilité 800x600', à une exception près (il s'agit d'un site de graphiste, donc destiné à un public possédant une résolution au moins égale à 1024x768).

Tu peux considérer que les crawlers utilisent un 'navigateur non graphique'. Donc, pour eux, il n'y a pas de différence non plus.

C'est sûr que si c'est pour limiter l'accès à une page en fonction de la page précédente, c'est pas fiable. Si c'est juste pour un script de stats, c'est moins grave.

Si tu ne veux pas redimensionner l'image, tu peux au moins vérifier la largeur de l'image avant de l'enregistrer. Si elle dépasse une taille maximum, tu n'effectues pas l'enregistrement, et tu renseignes un message d'erreur explicite

Ca rend bien sympa, tout ça Juste quelques petits conseils : Lorsque tu listes les départements, ainsi que les photographes, il serait agréable d'avoir à côté, le nombre de photos associées, pour ne pas à avoir à cliquer sur 15 liens avant d trouver du contenu Sinon, je vois que tu as intégré le multi-pages, et il fonctionne plutôt bien, c'est cool. Et, pour finir, tu devrais limiter la taille des clichés affichés; les plus gros dépassent de ton design : http://www.lafrancevueduciel.fr/image_phot...to=001145724855

En fait, après un p'tit tour sur le site en question, il s'avère que lexor n'utilise pas les frames, mais que ce soit juste le site de redirection qui les impose. (Pour info, http://jdhosts.net/ifsi ne possède pas de frame). Donc, en optant pour un .com (et si possible l'hébergement qui va avec; on peut avoir les deux pour une 30aine d'euros à l'année), tu ne devrais plus avoir ce souci.

Le site dont tu parles, a sûrement également un plan marketing assez conséquent (et coûteux), ainsi qu'un nombre conséquent de backlinks. Pour ce qui est des frames, elles sont à éviter absolument, et ce pour plusieurs raisons : - on garde le même titre de page tout au long de la navigation - on ne peut pas mettre une page précise du site en favoris - si jamais les pages de contenu sont indexées, elles le seront sans les pages alentour. En gros, si ton frameset est du genre : header - menu - contenu, en cliquant sur une page de contenu référencée dans un moteur, tu te retrouves privé du menu et du header ce qui, tu en conviendras, est assez frustrant pour le visiteur, qui risque de quitter précipitamment le site.

L'encodage des caractères (é etc), ne sert que quand le jeu de caractères utilisé n'est pas spécifié. Pour un navigateur, il n'y a pas de différence.

De toutes façons, je doute qu'une iframe soit valide en mode strict. Ensuite, plutôt que d'essayer tous les hacks du monde pour rendre ton truc, tu peux essayer d'utiliser du CSS, pour obtenir le même résultat qu'avec un iframe (si le but de tin iframe est bien d'avoir une zone scrollable).