L’organisation des fichiers n’est plus forcément dictée par une logique fonctionelle, mais aussi par une contrainte d’optimisation des chargements de fichier.
Le but est de ne charger que ce qui est strictement nécessaire.
Comment cela fonctionne-t-il ?
Le visiteur interroge une url titre.html
- GET titre.html réalisé par le navigateur
- SPIP regarde si le fichier CACHE/a/titre_jdsjfdfjskfl14564.gz
- le nom a/titre_jdsjfdfjskfl14564.gz est calculé a partir de l’url, du dossier_squelette. C’est le $chemin_cache
- les opérations de cette étape sont traitée dans ecrire/public/cache.php
- le nom a/titre_jdsjfdfjskfl14564.gz est calculé a partir de l’url, du dossier_squelette. C’est le $chemin_cache
- si la page en cache n’existe pas ou est perimée
- si le squelette compilé CACHE/squelette/titre.php n’est pas disponible
- phase de COMPILATION du squelette
- le squelette titre.html est chargé
- il est compilé dans CACHE/squelette/titre.php
- transformation des boucles, balises … en code php
- phase de COMPILATION du squelette
- Phase de CALCUL du squelette compilé CACHE/squelette/titre.php
- le fichier php est executé pour produire le fichier CACHE/a/titre_jdsjfdfjskfl14564.gz a jour
- si le squelette compilé CACHE/squelette/titre.php n’est pas disponible
- le fichier CACHE/a/titre_jdsjfdfjskfl14564.gz est evalué pour prendre en compte le code php restant (code php inclus dans les squelettes notamment)
- Opérations réalisés par les scripts de ecrire/public/
- un post rendu est réalise pour certaines operations spéciales (ex:surligner les mots de var_recherche pour servir une page apres une recherche)
Les accès à la base de données n’interviennent qu’a compilation/calcul. Ces accès sont couteux, et ils sont donc à éviter dès que la page calculée est en page.
Bon a savoir !
- La requête var_mode=calcul provoque un CALCUL du squelette compilé présent en cache
- La requête var_mode=recalcul provoque une COMPILATION du squelette puis son CALCUL
Les invalideurs
Ils sont gérés dans une table spip_cache
Tout un tas d’invalideur existent, liés chacun a un type d’évènement.
Ils servent à invalider toutes les pages liées à l’invalideur
Lorsque l’évènement propre à l’invalideur - un nouveau message dans un forum pour un invalideur forum - arrive, toutes les pages liées sont supprimées du cache.
Dixit _fil_, ca gagne a être connu, mais c’est pas encore super clair pour moi … Donc je vous en dis pas plus pour le moment !
Les subtilités du cache
Dans la 1.9, la gestion du cache prend en compte l’url par laquelle la page est demandée, le nom du fichier fond (une même page peut donc être servie par des fonds différents sans problème de cache), le dossier squelette (permet de personnaliser tout le design du site en fonction du profil utilisateur (cookie, navigateur, utilisateur identifié, adresse IP...).
Applications pratiques :
Proposer des habillages différents du site en fonction du nom de domaine par lequel il est appelé, pour un site multi-enseignes par exemple
Proposer des fonctions supplémentaires sur un site « corporate » pour les personnes qui surfent depuis l’adresse IP de la sociéte
Restreindre l’accès du site à une partie des visiteurs
Vos commentaires
# Le 14 avril 2007 à 18:56, par Bernt
En réponse à : SPIP 1.9 - Comment fonctionnent les appels d’une page de la partie publique ?
Depuis mon passage en version 1.9, je suis souvent obligé de vider le cache de mon routeur pour accéder à mon site.
Par ailleurs, une fois que j’ai vidé mon routeur, je suis aussi obligé de vider le cache de spip car je m’aperçois que des pages sont mal calculées.
Qui a déjà rencontré ce problème ?
Cordialement. BS
Répondre à ce message
# Le 28 mars 2006 à 18:17, par Loiseau2nuit
En réponse à : SPIP 1.9 - Comment fonctionnent les appels d’une page de la partie publique ?
Quelqu’un pourrait -il développer un peu ce passage ci SVP ? J’avoue être super séduit par l’idée mais ne voit pas trop comment la mettre en place...
Répondre à ce message