Rappelons que ce tutoriel n’est valable que jusqu’à SPIP 1.8.3 et obsolète à partir de SPIP 1.9. Il est en cours de réécriture dans l’espace privé de ce site.
Vous pouvez néanmoins réaliser ce tutoriel en omettant les fichiers .php3 et en localisant les fichiers html dans le dossier squelettes/ que vous créerez au besoin à la racine.
Dans les leçons précédentes nous avons commencé à élaborer des squelettes. Le succès de notre site risque d’être fulgurant. Pensons tout de suite aux pauvres neurones de notre ordinateur. Dans cette leçon, rien d’amusant, rien d’essentiel non plus. Les flemmards en profiteront pour roupiller au fond près du radiateur...
À partir de SPIP 1.9, le délai du cache décrit ci-dessous est défini dans le fichier html du squelette, par une balise #CACHE
{délais}, par exemple #CACHE{3600}
Résumé pour ceux-ci et pour les gens pressés : dans les fichiers d’appel de type tutoriel.php3, réglez $delais = 3600 ; au lieu de 0.
...
Au moment où une page est demandée à SPIP, celui-ci regarde si, par hasard, il n’aurait pas déjà calculé cette page auparavant. Si l’URL demandée est http://votresite.net/tutoriel.php3?id_article=12, SPIP regarde dans son sous-répertoire CACHE/ si ce fichier existe, et, le cas échéant, compare l’âge du fichier caché aux $delais fixés dans le fichier d’appel tutoriel.php3.
Dans notre exemple nous avions fixé des $delais=0 ; - d’où un recalcul systématique des pages à chaque consultation du site. Passons à $delais=3600 ; (c’est en secondes).
Notre page web n’est donc recalculée que si, lorsqu’un visiteur la demande, sa version cachée date de plus d’une heure (soit 3600 s.). Sinon, SPIP lit simplement le contenu du fichier caché [1], et renvoie le résultat sans se connecter à la base de données (sauf pour y insérer un « hit » dans les statistiques).
Comment fixer ces $delais de manière à optimiser le rapport réactivité/charge du serveur ? Pas de solution miracle, mais n’hésitez pas à fixer un délai d’une journée (i.e. $delais=24*3600 ;) ou plus pour les articles et les rubriques. Les pages de navigation les plus importantes peuvent avoir des $delais plus courts (vingt minutes ou une heure par exemple) si votre site est censé réagir à la validation fréquente de nouvelles brèves et de sites syndiqués... Si vous êtes sur un serveur partagé avec d’autres sites, soyez respectueux des autres et ne prenez pas tout le temps de calcul pour des pages qui changent rarement : ce serait d’autant plus idiot que, sur les gros articles ou sur les sommaires, le calcul des pages peut prendre quelques secondes, ce qui ralentit la consultation de vos pages...
Comment provoquer une mise à jour hors délai ? Nous venons de décider de $delais extrêmement longs, et nous repérons une fôte d’ortografe dans une page. Correction dans l’espace privé... Comment effacer tout de suite cette vilaine cicatrice du site ?
- Depuis l’espace privé, cliquer sur « Voir en ligne » déclenche le recalcul pour les pages correspondant à #URL_ARTICLE ou #URL_RUBRIQUE de l’article ou de la rubrique correspondante. C’est le cas le plus courant. Mais sinon ?
- Dans la partie « Sauvegarde/Restauration » de l’espace privé, un bouton « vider le cache » efface tous les fichiers cachés (utile si vous faites plein de modifications et avez un site très complexe, à éviter sinon).
- Toutefois, la solution la plus simple est de demander à SPIP, dans la page d’accueil de l’espace privé, de vous « poser un cookie d’administration ». Ce cookie s’incrustera sur votre navigateur, et SPIP vous reconnaîtra au moment de vous envoyer la page dans le site public : il vous proposera alors, en bas de page, un bouton « Recalculer cette page ».
Retour au contexte : On revient ici à la notion de contexte. Si le squelette est appelé avec un contexte d’id_article, d’id_rubrique ou encore d’id_breve, un autre bouton vous est proposé quand SPIP détecte le cookie : « Modifier cet article (ou rubrique, ou brève) », qui vous mène directement sur la page correspondante dans le back-office. Merci qui ?
Derniers détails :
- pour des raisons évidentes, le moteur de recherche ne
déclenche pas de cache, et les pages avec forum sont
réactualisées dès qu’une nouvelle contribution est envoyée.
- le répertoire CACHE/ dans l’arborescence du site
est découpé en 16 sous-répertoires numérotés
0, 1, 2... 9, A, B... F, dans lesquels les
fichiers cachés se distribuent quasi-aléatoirement ; cela
s’appelle « hasher le cache » et rien que pour cela mérite
bien qu’on le mentionne.
- les fichiers cachés sont exploités même si la base de données
est « tombée », ce qui garantit le site contre des pannes
transitoires du serveur mySQL.