Au début il y a le squelette
Supposons donc un squelette dans lequel se mêlent avec allégresse les instructions de diverses natures : HTML bien sûr, SPIP aussi, mais aussi PHP et Javascript.
Bien sûr, dans un coin du site, il y a aussi la base de données MySQL qui contient les infos « contenu » des articles.
Puis souffle le vent dans le cache
Ensuite il faut savoir qu’il y a un cache avec SPIP : chaque page est précalculée lors de son premier affichage. Ce résultat est stocké dans le cache, et c’est ce cache qui est ensuite appelé pour affichage.
La moulinette SPIP ne fait QUE traiter le code SPIP. Pour chaque boucle, SPIP interroge la base de données et génère en ligne le résultat (développé) correspondant aux réponses de la requête générée par la boucle et appliquée à la base de données.
A bord du cache
Dans le cache, il n’y a plus aucune instruction SPIP, car elles ont toutes été calculées. Par contre, il y a encore tout le code PHP résultant de l’interprétation du langage SPIP, et tout le source PHP ou Javascript présent en tant que tel dans les squelettes, qui est traité par SPIP exactement comme si c’était du simple texte, au même titre que du HTML.
Il y a 3 conséquences à cela :
- si du code PHP ou javascript est contenu dans les critères d’une boucle, il ne sera PAS exécuté et ne pourra PAS être pris en compte dans le calcul de la boucle. Ce sera uniquement le code "source" qui sera pris en compte et le résultat sera donc erroné.
- si du code PHP ou javascript est contenu à l’intérieur du corps d’une boucle, il sera dupliqué en autant d’exemplaires que la boucle fera d’itérations, exactement comme tout le reste du contenu. Et il s’exécutera à chaque fois. Parfois ce sera approprié, parfois ça ne le sera pas.
- si votre squelette contient du code php, ce code se retrouvera tel quel dans le fichier de cache, et l’exécution se refera à chaque appel de la page : ces parties ne bénéficieront PAS du cache.
En conséquence de ce qui précède, l’utilisation de php est à proscrire dans les squelettes SPIP, car ce code n’est pas « caché » : pour bénéficier pleinement du cache, on utilisera uniquement SPIP, pas PHP. Pour cela, on réécrira le code php en SPIP en utilisant des éléments évolués du langage SPIP depuis la version 1.9 :
- filtres conditionnels : ?, oui, non, ...
- balises #SET, #GET, #EVAL, ...Il est également toujours possible d’utiliser des filtres créés sur mesure : fonctions écrites en PHP, mais dont l’utilisation par spip, en tant que filtres appliqués à des balises, bénéficie toujours du cache. C’est cette solution qu’on utilisera quand on ne pourra pas se passer de traitements PHP complexes : pour bénéficier du cache, on les déportera dans des filtres.
Pour l’affichage
C’est le contenu du cache qui est appelé.
- Le contenu PHP s’exécute sur le serveur et génère la page que reçoit le navigateur de l’utilisateur (c’est pour lui qu’on fait tout ça, faut pas l’oublier !).
- Le contenu Javascript s’exécute dans le navigateur.
En conclusion : SPIP d’abord !
- Eviter le php en dur dans les squelettes, et plutôt mettre ce php dans des fonctions qui seront appelées en tant que filtres dans les squelettes.
- Pour bien mélanger PHP, Javascript et SPIP, se souvenir de l’ordre de préséance entre eux :
- SPIP d’abord développe les boucles
- le cache mémorise ce résultat intermédiaire
- PHP exécute le cache et sert la page au navigateur
- Javascript s’exécute dans le navigateur
Aucune discussion
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
