Remi

C'est marrant que tu poses la question parce que j'étais justement en train de me demander quels peuvent être les avantages de mettre ses NDD ailleurs. A partir du moment où tu contrôles tes DNS, je ne vois pas pourquoi on aurait des "explications à donner"... et c'est tout de même plus pratique de tout gérer du même endroit.

A mon avis, si tu as un problème de script qui prend trop de temps machine, tu vas te faire jeter du mediaplan aussi.

Si tu veux prendre un hébergement chez OVH c'est très simple, car tu peux faire les deux en même temps: Tu commandes un transfert et à un moment donné il te demandra si tu veux prendre un hébergement associé. Il faut juste que tu sois prête à transférer les données sur le nouvel hebergement quand il sera ouvert.

On ne peut pas faire de transfert dans la période qui précède l'expiration. Donc renouvelle en vitesse chez Gandi et ensuite fais ton transfert tranquillement (le transfert te prolongera l'expiration d'un an supplémanetaire)

Je trouve que vouloir masquer le Referer pour des raisons de "respect de la vie privée" c'est aller un peu loin... presque de la paranoïa. Ces referers avec 3 kilomètres de '+++' ou de '---' sont assez énervants parce qu'on les repère de loin dans nos tableaux de stats (ils élargissent les tableaux...!) et que l'on a effectivement l'impression d'avoir un visiteur qui arrive masqué.

La solution la plus simple reste tout de même de garder un vieux PC avec IE 5.5 dessus. L'avantage est de tester sur un PC moins puissant et sous Windows 98, ce qui correspond mieux à la configuration de nos visiteurs sous IE 5.5.

En fait, tout se joue au niveau des fichiers .conf Si tu veux tout dans le même rapport et que tu as plusieurs fichiers de logs, tu lui demandes de les regrouper en mettant dans le .conf une ligne du genre: LogFile="logresolvemerge.pl ../logs/*.log |"

Oui, ou que Google applique un filtre quelconque pour éviter de donner du grain à moudre à ceux qui voudraient mettre à jour ses techniques. Je reste avec l'impression qu'il n'affiche pas les BL les plus importants (ou les plus vieux). J'ai encore perdu des BL sur tous les sites (alors que j'en ai rajouté quelques-uns) mais bon... ça n'a aucune importance.

A propos du Flash, on entendait souvent dire "avec le haut-débit, le flash va supplanter le html". Force est de constater que ce n'est pas le cas, c'est même plutôt l'inverse qui se produit: Avec le haut débit, on est de moins en moins patient, 5 secondes de chargement est intolérable et comme de plus dans 99% des cas, flash = des titres qui arrivent en glissant, en tournant, en fondu, ... bref des effets faciles qui éloignent le moment où on va enfin pouvoir naviguer, eh bien on est déjà parti avant le fin de l'animation...

Je ne les avais même pas vus lors de ma mise à jour... Cela semble être utilisé lors de la visualisation des stats et non du calcul.

Oui, c'est parce que, une fois re-writée, l'Url repasse à nouveau dans la moulinette. Donc, là tu avais fait une boucle sans fin, donc -> erreur 500.

Pas toujours... Mais bon, on ne va peut-être pas en faire un fromage...

Non c'est bien URI... et oui, c'est bien une variable d'environnement. Mais, si tu te poses des questions, tu peux utiliser le code suivant pour voir toutes tes variables d'environnement. foreach($_SERVER as $nom => $valeur) echo "$nom -> $valeur ";

REQUEST_URI te donne ça...

Le problème est que Htmlarea adopte la convention prise par beaucoup de logiciels de création html : Enter donne un changement de paragraphe (<p>) Shift Enter donne un saut de ligne (<br>) Si tu veux que Enter donne un saut de ligne simple, tu ne pourras plus créer de paragraphe. Htmlarea utilise beaucoup les fonctions natives d'Explorer ce qui peut rendre les modifications sur le js un peu délicates. Ceci dit, après avoir jeté un oeil rapide, cela se passe au niveau de la fonction "FormatBloc"...

Autant que je me souvienne, on récupère le contenu de la zone modifiable par un POST. Donc à partir de là, tu peux faire tout ce que tu souhaites dessus avant de l'utiliser.

Il n'y a pas vraiment de textes légaux à ma connaissance sur ce point, mais l'usage parmi tous les professionnels est de mettre le client en propriétaire du nom de domaine. Le genre de situation que vous décrivez se règle de préférence à l'amiable... Changer le nom du propriétaire d'un nom de domaine est une procédure un peu lourde mais toujours possible. Si votre interlocuteur est un professionnel, il le fera sans poser de problème (parfois en prenant son temps mais il le fera ). Par contre, pour les codes d'accès ftp, c'est autre chose... surtout si c'est pour demander à un référenceur extérieur de venir faire des modifications sur le site. Sauf arrangement préalable ou clause pévue, ce n'est pas l'usage. L'usage est qu'en cas d'intention de transfert chez un autre, on mette à disposition les sources du site. Et si vous avez un contrat, ce sont bien entendu les clauses du contrat qui prévalent.

Oui, généralement en mutualisé, ce n'est que MySql qui pose problème. Et chez OVH, le 60GP est un peu victime de son succès. A 12 , c'est un produit d'appel avec peu de concurrence, mais ils sont quand même obligés de maintenir un certain niveau de qualité, car beaucoup de personnes portent un jugement sur OVH uniquement à partir de leur expérience en 60GP.

Je n'avais jamais vu ce genre de syntaxe. Cela fonctionne ? (j'ai essayé mais sans résultat)

Tu as du inverser les 2 fichiers... Après vérif: C'est l'entrée gAMA (gestion du gamma) de l'en-tête qu'il faut enlever pour ne plus avoir de pb sous IE. On peut voir l'en-tête avec un outil comme Tweakpng. http://www.webmaster-hub.com/index.php?showtopic=4392

Ah ok, si tu parles des couleurs des PNG, oui il y a une différence mais en fait c'est le même problème si je ne m'abuse. Un utilitaire comme PngOptimizer permet de contourner le problème en virant l'entrée alpha-machin de l'en-tête, mais il y a toujours une différence de couleur sous Safari.

Aurais-tu un exemple à nous donner ?

Personnellement, j'interprète l'effet Sandbox comme un mot qui désigne qu'un certain changement a eu lieu courant 2004 dans la façon dont Google prend en compte les nouveaux domaines. On ne sait pas trop quels sont ces changements, mais ce qui est sûr c'est que les "anciennes recettes" ne marchent plus vraiment. En pratique, il me semble qu'il faut plus de temps qu'auparavant pour bien positionner un nouveau domaine (ah la prime de nouveauté, c'était le bon temps ) On peut penser que Google accorde moins d'importance à l'url et aux BL, ce dernier point étant sans doute lié aux abus sur les sous-domaines et les BL de partenariat qui dénaturent l'idée de départ du BackLink (bientôt, on ne souviendra même plus qu'un BL au départ, c'était un webmaster qui recommande la lecture d'un autre site pour en savoir plus...) Toujours sur les BL, y a t-il eu des analyses sur le fait que Google ne veuille plus donner la liste des BL pour un domaine (certainement pour casser l'axiome BL => PR, mais encore...) et quels sont les BL qui restent affichés (j'ai la vague impression que ce sont les moins importants) ?

Le répertoire 'requetes' ne contient pas les logs mais de petits fichiers avec le nombre de requêtes par serveur du plan soit environ 500 octets pour une journée, les fichiers sont réunis quelque jours plus tard pour n'occuper que 15 octets par jour. A priori, c'est OVH qui s'occupe d'effacer les plus anciens. Les logs sont ailleurs et ne sont pas comptabilisés dans le quota.

Ce qui est bloqué je crois, c'est le fait de pouvoir à partir d'un plan accéder à un autre. Si ce que tu veux faire marchait, qu'est ce qui m'empêcherait de faire un include de tes scripts php et ainsi de te les pomper ? Donc ça parait logique que ce ne soit pas possible. Par contre, une idée en passant: As-tu essayé en renommant ton bout de script à inclure en .htm ? L'inconvénient est que tu ouvres la possibilité à n'importe qui de le lire, mais si tu lui donnes un nom compliqué, ça ne devrait pas poser de pb, et là c'est certain que tu pourras les inclure.