Anatomie des squelettes

L’essence d’un site Spip, sa "substantifique moëlle", c’est l’information qui est stockée en base de donnée (articles, auteurs...) via l’arrière boutique, la partie privée de Spip.

Le squelette s’occupe de la présentation de ce contenu, et pour le visiteur, c’est plutôt la devanture, ce qui ne correspond pas forcément à l’idée qu’on se fait d’un squelette.

C’est vrai en regardant les choses de très haut mais en fait, la présentation d’un site ne dépend pas uniquement du squelette : elle dépend aussi des images et des styles (les CSS qui définissent couleurs, dispositions etc.). En conclure que le squelette est une peau et que les styles sont l’habillage, serait pourtant inexact, car le squelette a aussi pour rôle de structurer le contenu en définissant quelle partie on va présenter et comment on va la présenter. Il donne une forme à un contenu, de la même manière qu’un squelette donne sa forme à un corps. Donc oui, notre squelette est bien un squelette !

Techniquement, le squelette est un fichier qui contient du code SPIP, c’est à dire des "boucles", des "balises" et des "filtres" entremélées avec du code HTML, le terme HTML étant à comprendre au sens large (CSS, php...). En général ce fichier correspond à une page de visite (URL), un squelette de page. Par extension au squelette de page, on parle aussi de squelette de site pour l’ensemble des fichiers du site en englobant tous ceux qui ne sont pas des squelettes (images fichiers .css etc.).

Si l’on appelle une page de squelette directement avec un navigateur, (http://.../article.html?id_article=99) ça ne donne pas grand chose de bon : le navigateur reçoit du code Spip qu’il ne comprend pas et essaie d’afficher la page tant bien que mal. C’est pourquoi il faut passer par Spip qui agit coté serveur : (http://.../article.php3?id_article=99 en syntaxe Spip traditionelle : ante 1.9). L’appel à article.php3 va mettre en branle le compilateur Spip qui va lire le fichier squelette article.html pour produire un résultat à partir des informations de l’article 99 trouvées en base de données ; c’est à dire que tout ce qui n’est pas boucle ou balise sera laissé tel quel tandis que les balises (#TITRE,...) seront remplacées par la valeur qu’elles ont pour cet article et que les boucles permettront de répéter des blocs de HTML.

Le résultat de cette compilation ne contient plus que du code HTML, celui d’origine et celui qui vient du code Spip. Ce résultat est analysé par le serveur Web (Apache) pour traiter le code php s’il y en a. Le résultat de cette seconde passe est, cette fois ci, une pure page HTML qui est envoyée à votre navigateur et mise en cache.

Le cache est celui du squelette et pas celui du navigateur. Le mot cache n’est pas trés approprié pour quelque chose qu’on veut montrer, mais il s’agit tout simplement du résultat de la compilation Spip qui est gardé en mémoire, dans un fichier du serveur, qui reservira lorsque d’autres visiteurs du site demanderont l’article 99. L’intérêt c’est d’économiser une compilation à chaque visite. L’inconvénient, c’est que le cache continuera à être servi même si l’article 99 a été modifié après la compilation. Heureusement, l’administrateur Spip peut forcer une nouvelle compilation avec le "recalcul" (qui s’applique à une page) ou le "vidage de cache" (qui s’applique à tout le site) et de toute manière, le recalcul sera automatique au bout d’un délai standard de 24 heures.

On a parlé de code Spip. Effectivement Spip est bien un langage, inspiré de la structure d’une base de donnée, qui s’intègre naturellement avec php (d’ailleurs, le compilateur Spip, tout comme la partie privée sont codées en php) et qui est surtout très facile a appréhender pour qui connait un peu le HTML. En voilà un exemple, cas simplifié d’une page d’accueil affichant les 10 derniers articles du site ; tout au moins leur début ; :

On a aussi parlé de CSS. Le principe du CSS est de séparer la forme du fond, ç’est à dire pour HTML de séparer la présentation du texte. En général, les styles CSS sont regroupés dans un fichier .css qu’il suffit de modifier pour obtenir un spectaculaire changement de look. On serait alors tenté de croire que la présentation du site est entièrement régie par les CSS, en oubliant que les styles utilisés doivent être appelés depuis la page HTML. Un changement radical de présentation exige à la fois une modification du squelette (au sens des *.html) et des CSS, images etc.

On fait appel au php lorsque le langage Spip atteint ses limites. Dans le Squelette Epona, c’est le cas pour le calendrier. Plus précisémment l’affichage du calendrier est réalisé en php, tandis que la partie extraction des données d’agenda est faite par une boucle Spip qui est conçu pour cet usage. Il y a aussi les fichiers de traduction (incontournable pour un squelette multilingue) et mes_fonctions.php tout aussi incontournable pour ajouter ses propres filtres.

Tant qu’à compléter le tableau des langage utilisés, mentionnons le cas du Javascript que l’on peut trouver partout où il y a du HTML, mais ceci concerne plutôt les interactions entre l’utilisateur et le navigateur. Dans le squelette Epona on en trouve à dose homéopathique pour les menus.

Mais revenons au codage Spip et aux squelettes. On a vu que la notion de squelette s’appliquait à une page (au sens Http/html) et à un site, or Spip connaît la notion de fichier et sait les emboîter avec l’instruction INCLURE. De sorte que tout bout de code Spip peut prétendre à la dénomination de squelette même s’il n’est qu’un morceau de page. Pour celui qui réalise son squelette, il est alors tentant de fragmenter à outrance pour améliorer la factorisation de code. D’un autre coté c’est au détriment de la lisibilité et des performances. De ce point de vue, Epona n’est pas un grand consommateur d’INCLURE et se limite aux appels de fichiers php et aux appels d’éléments communs à toutes les pages du site : le logo et le menu de navigation.