Test de la mise à jour de mx google sitemaps

[gowap]

Je comprends toujours rien

1) je sais parfaitement ce qu'est une feuille xsl
2) je fais la difference entre un fichier zip et un fichier gzip (.gz)
3) je fais la difference entre un fichier physique gzip et une page web transferée du serveur vers le client avec la compression gzip des pages active

[dcz]

[gowap]

je vais pas tarder a péter un cable, la...
je coule a pic meme quand tu me dis que tu ne fais rien de spécial et que c'est exactement le fichier du cache que tu as juste mis a la racine.

[dcz]

Ah non, interdit de mal dormir pour si peut

Et avec un fichier .xml.gz ou .txt.gz ? Tu n'as rien ?
tu as essayé de DL la source de l'exemple ?

Parce qu'une image, c'est clair que c'est pas fait pour être Gun-zippé.

Aussi, il y a des différences d'en-têtes de fichiers entre les fichier Gun-zippé pour archive et ceux pour envois au navigateur.

Le module utilise la fonction gzwrite qui ne fait pas forcément exactement la même chose qu'une compression manuelle winzip ou winrar en mode Gun-zip.

Pour tout te dire, je suis loin d'être un spécialiste de la compression gun-zip, j'ai simplement pris comme base ce que nous demandais Google, un fichier sitemaps.xml ou sitemaps.xml.gz. Leur description du système n'indique pas que sitemap.php?forum est valide, même si c'est le cas. Donc, allons au plus proche de ce qui est demandé me suis-dis

J'ai donc bêtement construit des fichiers .xml.gz pour voir les headers et construire ceux du module. Je ne me suis à vrai dire pas vraiment posé la question que tu soulèves lors du développement, vu que tout se passe bien à ce niveaux.

Il faut donc croire que c'est soit une histoire d'en-tête de fichier soit une histoire de standard xml qui supporte de manière native la compression gun-zip, contrairement peut être au html qui a été définit avant la généralisation de la compression et ne l'a du coup peut être pas été autour d'une reconnaissance client de la compression gun-zip via l'extension .gz.

Un truc dans le genre je dirais.

++

[gowap]

[dcz]

hehe, on va finir par percer à jour ces mystères de compression.

Donc, tu as tout bon. Mais comme -http://www.phpbb-seo.com/test.txt.gz marche sur mon serveur (accès direct au fichier physique), j'en conclus que cela se joue soit au niveau de l'en-tête du fichier physique, lors de la fabrication de celui ci, soit au niveau serveur, genre, envois automatique de header, encore une fois, soit en fonction des en-têtes du fichier ou simplement pour tous (ou ceux d'une liste de types : xml, txt ...).

Dans tous les cas, c'est pas important, car le module se charge d'envoyer les header dans tous les cas. L'accès direct au fichiers en cache sera bien entendu impossible depuis le dossier cache.

La procédure complète c'est :

1) on vérifie la requête : type et compression;
2) Si le cache est activé, on vérifie si le fichier correspondant à la requête est a jour, et si c'est le cas, on envoi les bon header (compression type de données etc ...) et on envois le fichier tel quel (éventuellement compressé donc);
3) Si on en arrive là, on doit fabriquer la page, donc on le fait. Si le cache est activé on met le résultat en cache, après compression si nécessaire. Et on envois le tout, ou le fichier cache tel quel si le cache est activé.

Le fichier cache demandé est déclaré trop vieux si la date de création du fichier physique est plus vielle que xx heures, que l'on règle dans l'ACP.
Si le cache n'est pas activé, le module stocke la date de dernière génération du cache de chaque type de plan au sens large pour définir l'expiration des pages. Cela veut dire que dans ce cas, il n'y a pas d'expiration individuelle, mais générale pour chaque type de plan.

Les dates de création et d'expiration du fichier sont envoyés dans le header, ce qui devrait permettre aux bots d'ajuster parfaitement leur crawl.
Je pense que je vais aussi ajouter un tit coup de HTTP_IF_MODIFIED_SINCE et HTTP_IF_NONE_MATCH pour alléger encore la charge serveur en indiquant au explorateurs de se servir de leur version en cache pour ré-afficher la page jusqu'à expiration du délais définis dans les header.

++

[dcz]

Bon voilà, nouvelle version en ligne.

J'ai modifié la page http://www.phpbb-seo.com/rss-channels.xml.gz

Je pense que ça posera plus de problème a FF2 comme ça.

Et aussi, j'ai pas mal modifié http://www.phpbb-seo.com/urllist.txt.gz qui est maintenant capable de sortir plusieurs milliers d'url, à voir jusqu'à ou Yahoo! tiendra le choc Et aussi, pagination sujet et forum spécifiquement réglable pour la liste Yahoo! et les sitemaps Google.

J'ai également ajouté la notification Yahoo! sur les flux rss, que je vais donc de ce pas tester en vrai

Voilà, heu, quoi, d'autre, ah oui, j'ai testé plus avant la modularité, et ça marche au poil, voyez comment s'intègrent désormais les flux du forum anglophone : http://www.phpbb-seo.com/rss-board.xml.gz

On les retrouvent dans http://www.phpbb-seo.com/rss.xml.gz

Voili.

++

[dcz]

Et hop GYM sitemaps and RSS

Celui là, c'est un gros morceau, vous allez comprendre pourquoi ça a pris du temps