La composition d’une page : par quel squelette ?

SPIP utilise principalement deux types d’URL pour reclamer ses pages nommées selon :
- des URL d’objets editoriaux
- des URL de pages nommées
dans les deux cas, avec des paramètres si nécessaire

Le process de compilation et d’instanciation d’une page doit donc rechercher un squelette de même nom : dans ./squelettes sinon dans .squelettes-dist., voire -en cas d’utilisation du concept Z ou équivalent- avec des noms et/ou dossiers subordonnés.

 
 
 
 
 
 
 
 
 
 
 
 

Rappel technique : vous pouvez toujours lister les squelettes/noisettes utilisées, en rajoutant à l’URL complète SPIP le paramètre var_mode=inclure [1], et/ou utiliser le plugin SkelEditor.

 Le squelette racine

Précisons d’abord la forme standard des URL de SPIP (après décodage de l’URL-rewriting) :
- soit une URL d’objet éditorial (connu de SPIP), avec la valeur d’identifiant-clé passée en paramètre
- soit une URL de page, nommée, passé comme valeur d’un premier paramètre automatique ?page=.. avec éventuellement d’autres paramètres à suivre..

Si vous voulez revoir comment générer ces URL dans des squelettes, voyez La construction des URL : on va s’attacher ici à la création d’une telle page demandée à SPIP !

 Deux systèmes principaux

En SPIP, pour trouver le squelette racine correspondant à un appel de ?page=nom co-existent deux systèmes différents, mais qui peuvent cohabiter, (avec une priorité d’usage au premier) :

  1. le système natif de SPIP (espace public) : recherche le fichier squelette racine nom.html dans ./squelettes
  2. sinon , le système Z (utilisé implicitement dans tout l’espace privé) semble plutôt rechercher le fichier squelette page- nom.html dans un sous-dossier ./squelettes ( ./squelettes/contenu/ ou ./squelettes/content/) si est activé l’un des plugins correspondants : Zpip ou Escal, Z-core ou Spip-r principalement.
    (voir Comprendre la structure des squelettes)

Une différence complémentaire est à observer dans la composition finale : le système Z rajoute au squelette de contenu des blocs homonymes complémentaires trouvés dans les autres sous-dossiers : navigation, extra..... pour compléter et reconstituer le squelette racine.

Va démarrer alors l’interprétation du squelette, utilisant les paramètres d’appel ajoutées dans l’URL, et les sélections établies dans les critères de boucles, pour définir les contenus textuels correspondants (qui seront extraits de la base de données).

 Appels et inclusions

A partir du squelette racine, des instructions INCLURE permettent d’appeler d’autres noisettes en spécifiant leur chemin relatif , en y passant si besoin Environnement d’un squelette.
Le résultat de cette génération, obtenu à grands renforts de recuperer_fond() [2] aboutit à un squelette (mis en cache recalculable) prêt à la dernière interprétation de SPIP, l’instanciation des balises de champ par les valeurs lues dans la base de données : le résultat est une page Web affichable, également mise en cache.


Merci de nous signaler les coquilles ou erreurs qui figureraient dans cette page.

[1Même dans l’espace privé !
Voir aussi l’astuce de Maïeul signalée en Se faire aider pour debugger un squelette !

[2Cette fonction interne de php est documentée dans Programmer SPIP.


Liens visibles seulement pour les inscrits.

Article publié le 14 août 2014, et actualisé en novembre 2016 .

Répondre à cet article