Dudu

Surtout que Free n'est pas un hébergeur gratuit. C'est un FAI dont le système de pages persos accepte le PHP. Si on considère Free comme un hébergeur gratuit, alors Orange, Club Internet, Neuf, Alice, etc. sont des hébergeurs gratuits eux aussi.

Non non TrocWeb, cette page existait avant, je suis bien tombé dessus moi aussi... dans un premier temps. D'ailleurs, le message de Monique un peu plus haut le confirme. En fait, le système anticopie de notre ami est très simple: - il refuse tous les navigateurs en dehors d'Internet Explorer et les redirige vers la page securite.html - si Javascript est désactivé, il redirige en meta refresh vers la même page securite.html - si Explorer et si JS activé, on affiche la page avec un script JS qui désactive le menu contextuel Personnellement, sans désactiver JS et sans utiliser Explorer, j'ai réussi à faire un clic droit. Preuve que tout est contournable PS: J'espère que je n'ai quand même pas enervé ce brave DJereMaster, au contraire j'attends une mise-à-jour de son système avec impatience. Je trépigne littéralement de pouvoir démontrer à nouveau que ces histoires d'anti-clic droit sont vouées à l'échec Encore une fois pour ceux qui n'ont toujours pas compris:

Pardon je double-poste Ci-joint une capture d'écran: on y voit la page d'accueil du site de DJereMaster... ah oui j'oubliais... on y voit aussi un beau clic droit :

Voilà ce que je disais en janvier 2007, c'est toujours valable 2 ans après Parlons un peu du système anticopie performant auquel a travaillé d'arrache-pied notre camarade DJereMaster: - En utilisant Safari sur Mac OS X (sachant qu'Internet Explorer n'existe plus sur Mac donc c'est difficile de l'utiliser), j'ai mis moins de 10 secondes à afficher le code source. - Tu ferais mieux de travailler d'arrache-pied à un système performant qui te permettrait d'écrire un HTML conforme. - Le lecteur Deezer en bas de page, ce n'est pas obligatoire. Par contre, la bonne nouvelle: puisque ton site n'a aucun contenu intéressant, tu ne risques pas de te faire copier. Et ça, comme système anticopie, c'est très performant. En plus ça ne nécessite pas d'y travailler d'arrache-pied (désolé, je n'ai pas pu m'en empêcher )

Salut Désolé, mais je vais répondre à côté de la plaque et je ne vais te donner aucune règle de réécriture J'ai déjà eu la même problématique que toi sur un site et je m'en suis sorti autrement. J'ai simplement transféré [i]http://www.domain.tld/v2/ vers [i]http://www.domain.tld/ (manuellement, via mon client FTP) après avoir transféré les anciens fichiers vers [i]http://www.domain.tld/ancien-site/. Les défauts de ma solution (et les moyens pour les corriger): certains chemins d'accès peuvent être cassés parce que relatifs au répertoire /v2/ il suffit alors de soumettre ton site au w3c Link Checker (un conseil: coche la case "Check linked documents recursively" sans mentionner de recursion depth) pour vérifier ces chemins cassés. Jette aussi un oeil de temps au temps au fichier log des erreurs sur ton dédié. l'autre écueil: il ne faut bêtement tout transférer le dossier racine vers [i]http://www.domain.tld/ancien-site/ car certains fichiers doivent rester à la racine du site. Par exemple robots.txt ou .htaccess. Sur ce point précis, seuls ta vigilance et ton bon sens pourront t'aider troisième piège à éviter: il faut que la structure du site reste la même pour éviter que d'anciennes URLs tombent en 404. Là encore, un coup d'oeil régulier au fichier log d'erreurs te permettra de les vérifier. Chez moi, cette solution a très bien marché sans nécessiter de périlleuses règles de réécriture. Ça devrait donc fonctionner aussi chez toi, en tous cas je te le souhaite

Bonne année 2009 à tous ! Ma bonne résolution cette année: 1024x768

Free n'est pas un hébergeur tout court. C'est un FAI avec un service de pages persos sympatique. Nuance !

Salut les gars, merci de vos réponses Ah ? J'avais testé avec un "allow from .abo.wanadoo.fr" (en refusant tous les autres avec un "deny from all"), et ça passait bien... Oui, mais derrière ce répertoire ce cache un script PHP assez complexe que je n'ai pas écrit, et je n'ai pas tellement envie de pourrir les sources d'un script ne m'appartenant pas (surtout pour refaire la même modification à chaque mise-à-jour). C'est un peu la réponse que je craignais. Et aussi la solution que je voulais éviter. Pour les plages IPs, effectivement, comme dit Dan, je ne connais pas celles susceptibles d'être utilisées. Me voilà parti pour une protection par mot de passe, alors Merci quand même pour votre aide et vos conseils

Salut À défaut de faire plus propre, j'aurais surtout fait autrement avec deux listes (donc deux <ul>) différentes. Une à gauche, une à droite.C'est ce qui me parait le plus simple vu ce que NesheK semble vouloir faire. Et surtout pas le moindre <div>, je les fuis comme la peste. C'est la balise à utiliser lorsque vraiment il n'y en a pas d'autre possible. Bon courage NesheK, tu deviendras bientôt "l'expert (XHTML-CSS) de la maison-mère, à qui on la fera pas à l'envers"

Salut le Hub J'ai un répertoire que je souhaite protéger, en le réservant à plusieurs IPs. Pour l'instant, j'ai ceci dans un fichier .htaccess placé dans ce répertoire Order Allow,Deny Allow from 123.123.123.123 Allow from 124.124.124.124 Problème: une des IPs est semi-fixe: elle change aléatoirement, une fois par semaine. Jusque là, et vu que la fréquence d'une fois par semaine n'est pas très élevée, je m'amuse à changer l'IP manuellement ,mais à la longue... Donc j'ai pensé au reverse DNS: cette IP a un reverse DNS qui change lui aussi, mais qui comporte toujours les mêmes éléments: AExemple-xx-xx-xx.abo.wanadoo.fr je souhaiterais donc écrire ma directive Allow en me servant du "AExemple" et du ".abo.wanadoo.fr" La documentation Apache n'est pas très prolixe en exemples à ce sujet, sauriez-vous m'aider ? Merci. PS: le contenu de ce répertoire n'est pas TRÈS critique, donc je peux me permettre d'autoriser par mégarde une IP du type "AExemple-yy-yy-yy.abo.wanadoo.fr" qui ne serait pas la bonne Mais je ne veux pas non plus autoriser tous les ".abo.wanadoo.fr".

Salut Rémi. Je n'espère aucun trafic, aucun lien (d'autant qu'ils sont en nofollow). Je stocke ma vidéo en l'appelant "hgdshjdfshkjdfqhq" (ou quelque chose de similaire selon le résultat que donne mon poing posé au hasard sur mon clavier ), ainsi je suis quasi-sûr que personne ne la visionnera sur le site de vidéos lui-même. Donc: je profite de l'hébergement, c'est toujours ça de pris. J'économise juste un peu d'espace sur mon hébergement à l'heure où la bande passante coûte des mille et des cents. je profite du lecteur Flash, car Flash a un taux de pénétration énorme. Ça m'évite de mettre du QuickTime ou du WindowsMedia qui ont un taux de pénétration inférieur. En revanche, je reste conscient du fait que ces sites peuvent à tout moment me supprimer mes vidéos à leur bon vouloir. Il convient de garder une sauvegarde de sa vidéo, c'est l'inconvénient. PS: j'ai édité ton post pour une raison orthographique qui me tient à coeur. Le mot "trafic" a toujours pris un seul F en français (il n'y a qu'en anglais qu'il en prend 2)

Sur la page [i]http://www.ovh.com/fr/particulier/produits/dottv.xml on peut aussi lire Et pourtant, ce baratin n'est qu'une grosse sonnerie (avec un s comme crocodile) Le TLD .tv est réservée aux Îles Tuvalu, point barre._ OVH reste une société commerciale comme une autre, qui cherche à appâter ses clients vers des achats de NDD nationaux (ceux avec des extentions à deux lettres) qui leur rapportent plus que des achats de NDD génériques (avec des extensions à 3 lettres et +). Il convient de rester subjectif OVH est peut-être un bon hébergeur, mais leur parole n'est pas non plus le Saint Évangile.

Salut Que ça n'apporte rien pour le référencement est une chose. Mais... Ça c'est une autre chose.Rien n'empêche de faire une réécriture de "www.domain.tld" vers "domain.tld". Un exemple ? cssvault.com

Et il y a d'autres types de mouchards dans les imprimantes: ceux qui te font passer une cartouche pleine pour une cartouche vide. Et ceux qui t'empêchent d'utiliser une cartouche "discount". cf http://www.01net.com/editorial/214058/l-en...e-le-champagne/

Je ne comprends pas. Tu présentes le problème comment étant "hardware" (puisque tu parles de "MacBook"), et ensuite tu évoques un problème de présentation de fenêtre qui ressemble à un problème "software" (donc sur l'OS, "Mac OS X"). Ça ne touche que ton MacBook ? Ou d'autres Macs aussi ? Je t'avoue que ton énoncé du problème ne me paraît pas clair

Salut La Bible de la redirection 301 en .htaccess, c'est cette page du site d'Alexandre Alapetite : Redirection Web en HTTP et HTML, notamment la partie "Redirection HTTP avec Apache". J'ai cette page dans mes favoris depuis des années. Chaque fois que je dois faire une redirection, je pioche mes infos là-bas.

Salut À mon avis: A) tu attends que les robots passent indexer les nouvelles pages, F) s'il y a de nouvelles URLs, tu places beaucoup de liens vers celles-ci, D) tu klaxonnes.

@ jmi : qui a parlé de JS ? Ma méthode préconise justement le positionnement absolu. PS: et surtout aucun <div> ! <div> est une balise qui n'a aucune valeur sémantique. Le moins de <div>, le mieux c'est.

Salut J'ai eu récemment un cas similaire. J'ai hébergé ma vidéo sur un site de vidéos avec un titre pas du tout explicite, je n'y ai pas mis de tags ni rien. Comme ça il y a peu de chances que des gens trouvent la vidéo depuis ce site de vidéos en faisant une recherche interne. Je profite juste de l'hébergement vidéo et du lecteur flash, et j'ai ai inséré le lecteur sur mon site Question réf: le site de vidéo sort après moi sur les SERPs.

Salut Nullette Un peu mon neveu ! C'est justement à ça que sert le CSS ! En fait c'est très simple: l'HTML: ne sert qu'à encadrer le contenu avec des balises le CSS: ne sert qu'à l'affichage des balises déclarées dans le document HTML Ce n'est pas plus compliqué que ça. Lynx n'étant pas un navigateur "graphique", il ne gère pas la partie "graphique" (donc le CSS). Il ne lit que l'HTML et place le contenu dans l'ordre du code source HTML.

... en n'oubliant pas que Free n'est pas un hébergeur. C'est juste un fournisseur d'accès Internet qui propose un service de pages persos ! Comme tous les autres FAI ! La seule différence c'est que Free accepte le PHP sur leurs pages persos. Ça n'en fait pas un hébergeur gratuit PHP Et pourquoi ça n'en ferait pas un hébergeur gratuit PHP ? vas-tu me dire. Tout simplement parce qu'il n'y a pas le rapport client/vendeur. Donc si demain ils veulent te virer ton site, ils n'ont aucun compte à te rendre. Ils le font, et il ne te reste que les yeux pour pleurer. La différence est énorme entre un "hébergeur gratuit PHP" et un "service de pages persos PHP", on ne le dira jamais assez Pour en revenir au sujet, c'est-à-dire faire des tests PHP sur un serveur distant. Bien sûr que Free convient (avec certaines limitations quand même). Mais j'insiste: sur un plan contractuel ils ne seront jamais ton hébergeur. (sur un plan légal, ils le sont dans la mesure où ils sont responsables devant la loi des fichiers, par exemple d'éventuels fichiers pirates, que tu pourrais envoyer sur leurs serveurs.. mais c'est un autre débat.)

Salut steph13 (ça faisait longtemps !) Un détail que tu ne précises pas: as-tu essayé sur plusieurs navigateurs ? Si oui, y'en a-t-il sur lesquels ça fonctionne ? (quand je dis plusieurs, c'est vraiment plusieurs; pas juste Explorer et Firefox) Une fois ce test effectué, remplace "window.location" par "window.location.href" et dis-nous sur quels navigateurs ça fonctionne (et sur lesquels ça refuse toujours). Troisième étape après tout cela: "window.location" est reconnu par beaucoup de navigateurs, mais ne fait partie d'aucune référence Javascript, en clair d'aucun standard. Un méthode basée sur le DOM avec un vrai script JS (pas un script trouvé sur un site répertoriant toutes les inepties du siècle dernier) te donnera de meilleurs résultats et une meilleure compatibilité inter-navigateurs. Si tu as oublié ce qu'est l'arbre DOM d'une page, une petite piqûre de rappel avec ce vieil échange que nous avons eu il y a quelque temps (ça se passe en bas de la page)

Bon à savoir, alors Oui il y a un ORDER, je me ferais un petit benchmark perso avec EXPLAIN Oui, pour ça pas de risque. Mais je note quand même Après vérif, je confirme: tous les champs sont indexés, sauf bien sur le "id" qui est en UNIQUE. Seul certains BBCodes ne sont pas interprétés dans les balises CODE et CODEBOX (quoique les deux ont un comportement un peu différent l'une de l'autre). Dans le cas du @ rien à voir avec le BBCode donc c'est un peu différent. Il s'agit de la fonction de remplacement de mot d'Invision, et elle fonctionne partout. En revanche, les modos et admins peuvent écrire de vrais @ donc comme tu le vois, je te n@rgue

Salut, et désolé de m'incruster dans cette discussion, mais je la suis avec beaucoup d'intérêt. Et j'ai une question qui me vient lorsque je lis l'échange suivant: J'ai un champ "id" en auto-increment qui compte mes enregistrements dans la table. Quasiment tous les champs sont indéxés. Cela voudrait dire que je consomme moins de ressources en faisant un WHERE id <= 50 qu'en faisant un LIMIT 0, 50 ??? (je parle pour une base qui est assez grosse et qui grossit de manière exponentielle). PS: Désolé pour les @ c'est un peu la seule solution pour éviter que trop d'adresses mail soient en clair sur les forums. Ça évite un tant soit peu la récupération par des robots collecteurs.

Salut captain ! Sur la théorie pure, c'est impossible.La notion de cascade et d'héritage en CSS fait que l'opacité appliquée à un élément-parent ne peut pas être supprimée sur un élément-enfant (dans ton cas avec un <span>). La propriété "opacity" et quelques autres fonctionnent de cette manière. Et c'est bien dommage. Toutefois, il existe une astuce autre que l'utilisation d'un PNG. Personnellement je la trouve un peu sale mais c'est toujours mieux que rien. Elle est très bien expliquée sur le le Mozilla Developer Center (qui est une mine d'or): Astuces CSS: Fond translucide