Dudu

header et no-cache ne sont pas 2 notions différentes: je parlais de mettre un "header no-cache" c'est-à-dire envoyer en PHP un en-tête qui va forcer la désactivation de la mémoire cache soit des navigateurs soit des proxys. Voici le code à mettre (issu du manuel PHP) <?php // Date du passé header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // toujours modifié header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); // HTTP/1.1 header("Cache-Control: no-store, no-cache, must-revalidate"); header("Cache-Control: post-check=0, pre-check=0", false); // HTTP/1.0 header("Pragma: no-cache"); ?> Il faut le mettre le plus haut possible dans le code

C'est le cas chez moi Par contre, mets un petit header no-cache en haut de ton code PHP dans l'index: j'ai du rafraîchir la page pour voir le changement.. et çà fera certainement le coup à tes visiteurs [edit] et enlèves le header dans quelques jours si tu ne veux pas tripler ta bande passante inutilement [/edit]

Bonjour là-dedans Je vous explique mon souci: j'ai un bot nommé ConveraCrawler qui vient indexer les pages d'un de mes sites. Jusque là, pas de quoi fouetter un chat. Sauf que cet animal n'en a strictement rien à faire de la bande passante De plus, je ne vois pas trop quel est son but. Pour info: * bande passante: j'ai un petit script PHP qui enregistre les requêtes dans ma base de données. Là par exemple, dans PhpMyadmin, j'ai un peu plus de 2 pages entières de Convera * but: sur le site de ConveraCrawler il est écrit: "The information gathered by ConveraCrawler will be indexed and made accessible via one or more publicly-accessible web sites in the near future." Donc il n'y a pour l'instant aucun site web où l'on puisse visualiser les résultats (et le bot indexe le web depuis plus d'un an: avril 2004). De plus, il est aussi dit sur le site de Convera-tout-court, ceci: "Convera is a leading provider of information infrastructure software products that enable enterprises and government agencies to access, organize and utilize unstructured information." donc il apparaît qu'ils bossent pour les gouvernements et les grandes entreprises (et je me contrefous autant de l'un que de l'autre). Je pense donc à rajouter ses IPs dans mon htaccess (et/ou de lui associer une belle petite ligne dans robots.txt). Mais je voudrais votre avis d'abord, car il n'est pas dans mes habitudes de bannir un robot comme çà. Donc mes questions: - quelqu'un connaît-il Convera et ConveraCrawler ? - quelqu'un l'a-t-il déjà banni ? - pensez-vous que je doive le bannir ? Merci d'avance PS: Au fait, sur leur site, ils s'excusent par avance des excès de bande passante monopolisée en arguant qu'ils sont pressés d'indexer tout le web. Çà me paraît un peu facile

Ah oui? Le problème doit plutôt venir de là alors car le solution du padding ne fonctionne pas... Arf, j'avais pas vu que le #text n'avait pas de largeur définie Oui, définis-lui une largeur.. et si çà ne résoud pas le problème, colles-lui un padding-right

Ce qui ne va pas c'est la sémantique. Cet extradiv est calé en utilisant de la grosse bidouille qui tache Il serait préférable de mettre l'image en fond de page par exemple

En fait, les textes ne "débordent" pas, ils sont juste collés au bord droit du <div> On le voit en augmentant la taille du texte. En fait, il faudrait ajouter un padding-right à #text çà devrait résoudre le problème Au passage, tu devrais en profiter pour débugger un peu le code HTML: je pense notamment au <div id="extraDiv2"> () et au formulaire de bas de page qui mélange tableaux imbriqués et divs inutiles Si tu as besoin d'aide là-dessus, n'hésites pas

Ce qui est drôle, c'est qu'en suivant les liens connexes en bas de page de l'article, on tombe rapidement sur une page disant Bientôt, quelqu'un va déconseiller Firefox, ensuite ce sera au tour d'Opera, puis Safari, etc etc.. D'ailleurs pour Firefox, le cas est déjà apparu récemment, en fait. Je ne sais plus qui conseillait aux utilisateurs Windows d'utiliser Explorer en attendant une mise-à-jour de Firefox. Çà fait un peu "bataille de cour de récré" tout çà Bienvenue dans un monde plus sûr sans clé de registre C'était mon mini coup de gueule de la journée. Çà va mieux maintenant

Idem: je vois les adsenses sur les 2 sites. Par contre, embauches.fr est complètement illisible. Configuration: Mac OS X.3 / Safari 1.2 Hope this helps PS: il est sûr et certain d'avoir le javascript activé ton client ? Peut-être une piste

Hello Çà m'a l'air un peu compliquée ton histoire. Grosso modo: * oui il est possible de se servir de Dotclear comme CMS et finalement plus tellement comme blog * ne pas que les billets s'écrasent parait beaucoup plus dur. Une solution est de supprimer l'accès à index.php s'il n'est pas suivi d'une variable et de coder une petite page php qui en serait l'équivalent, et qui plutôt que de lister le contenu des billets, serait disposée de la manière dont tu souhaites le faire * pas de calendrier, çà parait simple: tu vas dans les templates et tu supprimes le div adéquat. Ou tu le remplaces par un contenu de ton choix. Si tu souhaites le virer de l'URL (/index.php?2005/05/28/...) ce sera un chouïa plus complexe. Notamment pour les mises-à-jour * pour les archives: idem * Non, il n'y a pas cette option de basculement blog->CMS dans l'interface d'administration. Pour cause Dotclear est un blog, non un CMS Sinon, plus simple: opter pour Plume, qui est un CMS ressemblant beaucoup à Dotclear

Ce sont les 60gp qui sont souvent lents Et le Hub, fort heureusement, n'est ni sur un plan 60gp, ni même sur un mutualisé: ce que disait Anonymus un peu plus haut. Pour relativiser, le 60gp est un plan "bas de gamme" dans l'offre OVH. Bas de gamme, mais également très populaire (voir les stats de netcraft à ce sujet). Un peu normal donc qu'il souffre de ces problèmes de lenteur.. En revanche, pour les erreurs SQL je le redis: ce n'est certainement pas dû à la faible charge des serveurs, c'est plutôt les scripts faisant appel à la base de données qui laissent des connexions persistantes Le site dont je m'occupe en ce moment et qui est sur un 60gp OVH a tout son contenu dans la base de données, donc à chaque page, des scripts PHP viennent puiser dedans. Et pourtant je n'y ai jamais vu aucune erreur SQL

max_user_connections c'est un peu le cas typique du script PHP qui a plein de requêtes SQL persistantes. Ce n'est pas vraiment fréquent que ce soit dû à l'afflux de visiteurs.Pour les lenteurs en revanche je suis d'accord (et je pense aussi à migrer ce site soit vers un autre hébergeur, soit vers un autre plan) Concernant l'image, il va certainement falloir demander l'autorisation à la Voix du Nord [edit] en fait non, l'article et la photo sont disponibles sur le site de la Voix du Nord [/edit]

La dernière fois où tu as écrit le mot "panel" c'était tout à l'heure, dans ce message, et le sujet a l'air d'être toujours debout

Attention aussi à ne pas confondre le temps que Google met pour traiter la requête (qui est indiqué sur la page de résultats, en gaut à droite) et le temps que met la page à s'afficher: ce sont deux notions différentes Mais effectivement, si la page met 30 secondes à s'afficher, il y a nécessairement un problème. Çà ne le fait que pour les moteurs de recherche ? Peut-être peux-tu essayer de vider le cache navigateur, ce sera un bon début

Pour les 60gp je confirme. Je n'étais pas sur Internet hier à ce moment, mais à la lecture de ce sujet je viens de regarder les logs d'un site hébergé chez OVH en 60gp, et effectivement entre 14h et 16h nada Bizarre par contre que le site d'OVH ait été touché et pas le Hub. Normalement, un hébergeur installe son propre site sur les meilleurs de leurs serveurs. Bon, en tous cas, c'est pas çà qui en fait un mauvais hébergeur ou qui vient entâcher cette success story (qui effectivement est assez remarquable, merci Mincoin). Ce serait à répétition, pourquoi pas...

Normalement oui Disons qu'il m'est arrivé le cas inverse (je suis sur Mac) et j'ai pu ouvrir le fichier. En général, les histoires de compatibilité impossible Mac/PC sont des rumeurs de village (je connais les 2 systèmes).

Tiens, pan sur le bec, le Dudu J'ai appris un truc, merci de l'info

Ah.Ben j'apprends quelque chose alors, j'ignorais complètement çà vu que le référencement n'est pas du tout mon domaine Merci de l'info. PS: j'ai l'impression que ni toi ni Jeanluc n'ont compris la dernière phrase de mon précédent message. Je disais juste que je pensait au début à un truc fictif comme Google nous y a beaucoup habitué. Et qu'en fait non, peut-être pas Bon je reviens à une lecture passive de ce sujet, j'ai plus à y apprendre qu'à y intervenir..

Pour te donner une comparaison, c'est un peu comme si tu disais:"je suis un architecte. Ma maison ne tenait pas dans l'espace entre les deux immeubles mitoyens, donc pour l'instant j'ai enlevé les briques: çà tient" Styles tes listes en CSS, accordes leur une largeur bien définie, enlèves-y les gros points qui vont se mettre devant chaque item par défaut etc etc.. il n'y a aucune raison pour que çà ne tienne pas dans un espace défini Mais remets les briques.. enfin les <ul> je voulais dire

Je me réponds moi-même, mais à la lumière de vos messages postés entre-temps..On dirait donc que ce n'est pas un hasard.. Bon, je n'ai gagné aucune place (enfin si, une place pour chaque Google étranger.. super), je n'ai rien perdu non plus. Par contre, si côté "moteur de recherche" rien n'a vraiment changé, le côté "bot" a l'air de drôlement s'affoler -> Googlebot indexe puis réindexe, puis reréindexe puis.. re.. etc.. Mes logs d'accès de cette semaine sont tout bonnement illisibles, y'a du Google partout Moi qui en lisant le début de ce sujet m'était dit "tiens, encore une idée marketing de Google pour faire parler de lui.. à tous les coups, certains vont voir d'énormes changements qui seront en fait complètement psychologiques.."

En fait, en XHTML on n'a pas le droit aux majuscules dans le code C'est pas moi qui fait un caprice, si vous voulez râlez allez voir le w3c C'est dû à la parenté XML de l'XHTML, et c'est autant une règle qu'une convention. Donc si on ne peut pas écrire <div id="Footer">, on ne peut nécessairement pas écrire dans sa CSS -> #Footer Sauf qu'effectivement, Mumulafrite est encore en HTML 4, au temps pour moi.. n'empêche que c'est une bonne habitude à prendre dès maintenant car un jour ou l'autre il faudra bien passer à un autre doctype (puis un autre, puis un autre, on n'arrête pas le progrès..) Puis effectivement, c'est aussi une bonne manière d'éviter les erreurs de casse donc d'interprétation

C'est bien ce dont je me doutais Je suis assez déçu de m'apercevoir que mes efforts pour t'aider servent à duper de manière plus ou moins classieuse des moteurs de recherche via des procédés qu'ils répriment (et dont ils ne sont pas dupes.. çà peut aller jusqu'au blacklistage). Bref, j'ai commencé à t'aider, donc je continue mais bon... Je vois que tu as changé l'appellation de l'ancien "footer" À mon avis, tu devrais virer les déclarations a pour n'en garder que l'essentiel. Comme ceci par exemple a:link { color: #404040; text-decoration: none; } a:visited { } a:hover, a:focus { text-decoration: overline underline; } a:active, { } Çà nettoirait un peu les différentes déclarations de tailles de lien. Surtout que par défaut (a:link) ils ont la même taille que le corps de texte normal. Donc inutile de re-préciser la taille, à part pour embrouiller les navigateurs À ce propos, l'ordre pour noter les différents pseudo-formats associés aux liens doit toujours être :link, :visited, :hover, :active

La déclaration du footer est en double maintenant: en haut, en bas.. Il y a clairement une interférence avec d'autres règles. Celle du a:link en particulier Tu définis que tout ce qui se trouve dans le footer va avoir une taille de 4px puis juste après tu définis que tous les liens vont avoir une taille de 10px.. Vu qu'en CSS, c'est toujours la dernière déclaration qui l'emporte -> les liens font 10px, qu'ils soient dans le footer ou non. Un peu hors-sujet, 2 remarques: - enlèves tous ces "font-family" de ta CSS ! Le principe des feuilles de styles en cascade est que les déclarations s'appliquent par cascade: Donc, en attribuant la font-family à body une bonne fois pour toutes, il n'est nul besoin de le réécrire à chaque ligne. - les liens en bas de page sont déjà très peu visibles avec 10 pixels. À quoi serviraient-ils en étant plus petits ? À quoi, de manière générale sert un lien s'il ne doit pas être cliqué ?

Ben non pas logique... si les balises <a> sont imbriquées dans le <div id="footer">, aucune raison que celles-ci ne soient pas affectées par le changement de taille. Une petite URL pour qu'on puisse voir ? [edit] visiblement, c'est sur webfolie, lien dans ta signature.. bouge pas je regarde [/edit] [edit 2] ok vu c'est l'ordre de déclaration qui n'est pas bon dans ta CSS, mets la ligne concernant le footer tout en bas de la CSS [/edit 2]

Sauf ton respect... oui Lorsque tu définis une id dans le code html, il faut que le nom associé soit précédé d'un # dans la CSS. Lorsque tu définis une class dans le code html, il faut que le nom associé soit précédé d'un . dans la CSS. C'est la règle de base à savoir par cœur Donc, en l'occurence, tu as oublié le #. D'autres part, il y a quelques autres erreurs dans le code que tu donnes ne jamais utiliser de majuscules. Tout doit être en minuscules. Supprimes le align="center" de ton code HTML pour le remplacer avantageusement dans ta CSS par un text-align: center; Ne redéfinis pas la font-family si c'est la même que celle définie pour le body (ce dont je suis à peu près persuadé) Donc les codes corrigés donnent <div id="footer"> #footer {font-size: 4px; text-align: center;} Par contre, 4 pixels c'est vraiment miniature, tu seras certainement amené à augmenter un peu la taille (9 pixels me paraît l'idéal)

Je réponds ici plutôt qu'à ton MP car si quelqu'un a un jour le même problème, il sera peut-être content de retrouver cette discussion et d'y lire d'éventuelles pistes pour résoudre son problème Donc grosso modo, tu as exactement le même souci en installant le script au bon endroit. Bien. D'abord, il faut que tu crées un fichier index.html vide dans ton dossier 'sessions'. C'est très important, car y sont référencés tes id-sessions , et pour des questions de sécurité, il ne convient pas que tout le monde puisse les lire. Ensuite: Est-ce que l'installation du script s'est déroulée avec succès ou as tu un peu forcé la main malgré certains messages d'erreurs pour installer "de force" l'application ? Ensuite, que dit PhpMyAdmin sur cette table et sa présence ? N'y a-t-il pas un problème de préfixe ? Ps: je rappelle que je ne suis pas utilisateur de PhpMyNewsletter, je ne suis donc pas le plus apte à répondre aux questions concernant ce script