captain_torche

Je voulais dire par là que sa solution ne servait à rien : un robot d'indexation se comportant grosso modo comme une navigateur, il suivra des liens depuis d'autres sites, mais pas depuis un moteur de recherche. Il est donc impossible que le referer présent dans le cache google comporte l'url de google. Surtout qu'il est tout de même suffisamment simple de "capturer" un referer et de l'analyser plutôt que de monter tout un mode opératoire qui se révèlerait au final inutile

Objectifweb -> pourquoi se prendre la tête comme ça ? Surtout que les robots d'indexation ne "cliquent pas sur les liens depuis un moteur de recherche". Il faut effectivement utiliser la méthode de Fanou, en sachant qu'elle n'est pas "sûre" à 100%. Mais de toutes façons, ce n'est pas trop grave (je pense) si l'on n'affiche pas la phrase spécifique à un utilisateur qui a désactivé l'utilisation des referer.

Pour un portable, je sais pas comment ça se passe. Faudrait que tu trouves des infos pour voir si la carte graphique est facilement extractible.

Il a plus de chances qu'il s'agisse de la carte graphique, selon moi (présence d'"artefacts" lorsqu'elle est beaucoup sollicitée, puis tout le temps).

Le SDZ ? Je l'y ai vu quelques fois. Et bienvenue, au fait !

Dans n'importe quel cas, si tu souhaites faire autre chose que valider un formulaire, il faudra utiliser du JavaScript. Si tu ne souhaites que valider un formulaire, la balise <input type="image" src="tonimage.jpg"> est valide, et est l'équivalent d'un <input type="submit"> En ce qui concerne la balise <button>, elle n'a d'autre but que de faire apparaître un bouton neutre (qui n'effectue aucune action). De plus, elle est dépréciée, et il faudrait idéalement utiliser un <input type="button">.

Tu utilises mal l'objet "button", c'est pour ça. ll vaudrait mieux que tu utilises l'objet input, qui est fait pour ça : <input type="image" src="tonimage.jpg" onclick="tonaction(); return false">

Rien à voir avec le CSS, donc Sinon, Windows affichera "image JPEG" quelle que soit son extension (jpg ou jpeg). Pour pouvoir connaitre l'extension exacte d'un fichier, va dans le menu "Outils -> Options des dossiers", onglet "affichage", et décoche la case "masquer les extensions des fichiers dont le type est connu".

Il n'y a aucune mention d'un fichier .jpg dans ton CSS. Il serait bon de le mettre à jour.

Il y a deux possibilités : - comme l'a dit Vincent, une erreur de requête - mais il peut aussi y avoir un problème de connexion à la base Tu peux avoir un aperçu de l'erreur en modifiant la ligne de ta requête comme suit : $chercher = mysql_query ("SELECT * FROM livre WHERE date!='xx' ORDER BY id DESC LIMIT $PremierMessage,$MessagesParPage") or die(mysql_error());

Dissocier l'annonce du prix, permet d'avoir un historique de ce dernier.

Ton htaccess, tel qu'il est rédigé, empêche l'accès aux fichiers ... même pour ton propre site ! Il faut que tu autorises ton site à les consulter ! RewriteEngine On RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://www.tonsite.com/.*$ [NC] ReWriteRule .*\.mp3$ - [NC, F] Avec le paramètre NC pour que mp3, MP3, Mp3 et mP3 soient compris.

Pour l'envoi d'email, il te suffit d'utiliser la fonction mail() de PHP. En ce qui concerne les adresses IP, il faut que tu utilises la variable $_SERVER['REMOTE_ADDR']. Par contre, sache que le contrôle par adresse IP n'est pas "fiable", en cela qu'une adresse IP est amenée à changer (les adresses IP dynamiques sont encore nombreuses). Si tu veux contrôler les membres, il serait plus approprié de leur créer un compte asscié à une adresse e-mail (avec validation du compte via l'e-mail).

Ca serait plus simple de constater sur pièces, avec l'url du site en question (que tu peux également mettre en signature). Pour ce qui est des orthographes voisines, c'est parfaitement normal que tu ressortes mieux placée : comme tu t'en doutes, les sites utilisant cette orthographe "accidentelle" sont beaucoup moins nombreux (il y a donc moins de concurrence sur ces mots-clés).

Tu n'es apparemment pas victime de la sandbox (qui est juste un déclassement de pages "jeunes" ayant un trop grand nombre de backlinks), sinon ton site n'apparaîtrait pas en bonne position sur certains termes. Ce qui doit se passer, c'est que Google fait la différence entre le terme "aéroport" et "aeroport", et que ton site contient plus fréquemment le terme accentué. Pour ce qui est de Genève et de Zurich, il y a deux possibilités : - le terme Zurich est plus fréquemment utilisé dans tes pages - il y a une plus forte concurrence sur le terme Genève, et les sites apparaissant avant le tien sont mieux optimisés sur ce terme.

Il te sufit de mettre dans une variable le code HTML, puis de renvoyer le contenu de ce code. <?php function html($titre) { $html = "<html><head><title>$titre</title></head><body>"; return $html; } ?>

Tu pourrais poster la ligne de connexion à la base (en masquant le pass) ?

Ce que je veux dire, c'est que comme il n'y a pas de preload de l'image, l'image en rollover met un peu de temps à s'afficher. En conditions normales de surf, l'utilisateur lambda cliquera sur le lien bien avant que le rollover ne s'affiche, d'où sa relative inutilité.

J'ai testé, et ça ne marchait pas. Ca me semble logique : le navigateur ne peut pas avoir accès à la structure interne (donc cachée) du serveur, si ?

J'ai essayé, mais il faudrait tout de même réinterpréter l'affichage des images (et je n'ai pas trouvé comment faire). Parce que <img src="/www/site1/IMG/">, ça marche pas des masses

Ca ne fonctionne pas non plus sous IE7 : il a donc toujours besoin qu'on lui spécifie un curseur en .cur.

Mutualiser les logos de deux sites partageant la même base de données SPIP Problématique : Nous partons du principe que nous avons deux sites (siteA.com et siteB.com), tous deux utilisant SPIP. Le site A, généraliste, comporte beaucoup de rubriques et d'articles. Le site B, spécialisé, ne reprend que le contenu d'une rubrique spécifique du site A. Si la gestion des articles ne pose pas de problèmes, la récupération des logos associés aux articles est plus pointilleuse. En effet, SPIP vérifie la présence physique de l'image dans son répertoire avant de l'afficher. S'il ne trouve pas l'image, il ne l'affichera pas. Fichiers modifiés : ecrire/inc_version.php3 et ecrire/inc_logos.php3NB : Ceci n'est pour l'instant testé qu'avec SPIP 1.8.3 Etape 1 : Afficher les logos du site A Principe de fonctionnement des logos dans SPIP Lors de l'ajout d'un logo à un article, ou une rubrique de SPIP, rien n'est ajouté en base. SPIP se contente de créer une image, nommée artonxxx.jpg, ou rubonxxx.jpg (avec xxx correspondant à l'id de l'article/rubrique), dans son dossier IMG. Lors de la génération des pages, SPIP vérifie donc la présence de ce fichier, et l'affiche le cas échéant. Dans notre cas, nous n'avons aucune image dans le répertoire IMG sur le site B; SPIP n'affichera donc pas les logos associés. Il faut donc que nous modifiions le fichier définissant le répertoire IMG, pour le faire pointer vers celui du site A. Cette déclaration se trouve dans le fichier ecrire/inc_version.php3, à la ligne 372 : define_once('_DIR_IMG', _DIR_PREFIX1 ."IMG/"); Il nous faut donc pour l'instant le faire pointer vers le site A : define_once('_DIR_IMG', "http://www.sitea.com/IMG/"); Pour l'instant, cela ne fonctionne pas encore : SPIP utilise la fonction file_exists() de PHP pour vérifier l'existence du fichier, qui ne fonctionne qu'en local sur les versions de PHP antérieures à PHP5. Il nous faut donc modifier les appels à cette fonction, pour en utiliser une autre qui supporte les appels distants à une url. J'ai choisi fopen(), conscient que la demande en ressource doit être supérieure à la première fonction. Il faut ensuite éditer le fichier ecrire/inc_logos.php3, pour remplacer tous les appels à la fonction file_exists, de la forme : if (@file_exists($fichier)){ par des appels de la forme : if (@fopen($fichier, 'r')){ Une fois ces modifications faites, cela fonctionne pour les logos appelés sans traitement. Il faut par contre permettre au script de gérer le redimensionnement des images. Etape 2 : permettre le redimensionnement des images du site A Problème rencontré : Sans modification au script actuel, SPIP tente d'enregistrer les fichiers redimensionnés dans le répertoire http://www.sitea.com/IMG/, qui n'existe bien évidemment pas sur le site. Il nous faut tout d'abord définir un répertoire où figureront les images redimensionnées. Pour ce faire, nous allons ajouter une ligne, dans le fichier ecrire/inc_version.php3, idéalement après la ligne que nous venons de modifier : define_ONCE('_DIR_IMG_CACHE', _DIR_PREFIX1 . "IMG/"); J'ai ici réutilisé le répertoire IMG, tout simplement. Pour finir, il faut spécifier que les images redimensionnées doivent être enregistrées dans ce répertoire spécifique. dans le fichier ecrire/inc_logos.php3, dans la fonction creer_vignette. Il suffit d'éditer ces trois lignes : if ($destdir) { $destdir = creer_repertoire(_DIR_IMG, $destdir); } $destination = _DIR_IMG . $destdir . $destfile; pour les remplacer par : if ($destdir) { $destdir = creer_repertoire(_DIR_IMG_CACHE, $destdir); } $destination = _DIR_IMG_CACHE . $destdir . $destfile; Tout fonctionne parfaitement dorénavant !

Je reformule plus simplement (mais j'ai trouvé une réponse que je détaillerai ici dans l'après midi) : J'ai un premier site (sitea.com), généraliste, avec un grand nombre de rubriques et d'articles, utilisant SPIP. J'ai, sur le même serveur, un second site (siteb.com), utilisant la même base SPIP que sitea.com, mais spécialisé dans une rubrique précise : on reprend les articles de cette rubrique, ainsi que leurs visuels. La rédaction des articles se fait dans tous les cas sur l'interface de sitea.com Si la récupération des articles se passe sans problème (ils sont extraits de la base), celle des images (ou plutôt des logos) est un peu plus problématique : comme SPIP recherche d'abord l'existence de l'image dans son répertoire IMG, il ne me l'affiche pas sur le siteb.com (vu que siteb.com/IMG/ est vide).

Sachant qu'IE6 utilise le cur par défaut, ça serait plus parlant si on n'essayait qu'avec le PNG

Après, c'est un choix : j'imagine que le nombre de serveurs mettant en quarantaine les mails au format HTML est très limité comparé à ceux qui le laisseront passer.