Mécanismes de fabrication des pages publiques et privées

Depuis la version 1.9 de SPIP, il n’existe que deux points d’entrée pour le site :

La page demandée est précisée dans un cas comme dans l’autre par les arguments GET ou POST associés à la requête. Nous verrons plus loin quels sont les principaux.

À de très rares exceptions près (a priori customisation), tous les autres scripts présents dans l’arborescence ne sont pas exécutables directement mais uniquement incluables. Ils sont d’ailleurs en général "protégés" par un test initial :

Ceci vérifie que la constante _ECRIRE_INC_VERSION est définie, ce qui ne sera pas le cas si le script est chargé directement.

Cette constante est définie par ecrire/inc_version.php qui constitue la clé de voute de l’architecture SPIP. Ce script est en effet inclus pratiquement en tout début par les index public ou privé.

Pour l’index public, cela passe par l’inclusion initiale de ecrire/public.php : mis à part cet include, on peut voir que cet index est pratiquement vide.

ecrire/inc_version.php

Ce script est commun à tous les composants de SPIP. C’est lui qui procède aux définitions, initialisations et inclusions de base qui déterminent le fonctionnement de tout le reste. Il initialise les constantes et les variables globales nécessaires au fonctionnement de SPIP, notamment celles assurant sa portabilité sur les différentes plates-formes.

Assez tôt lors de son chargement, il inclut les fichiers :

  • inc/utils.php, où figurent les fonctions indispensables à SPIP (voir plus loin)
  • le script optionnel hors distribution nommé
    mes_options.php
    qui permet de moduler cette initialisation sans avoir à modifier le fichier
    inc_version.php.

Déroulement du code :

  • définition de la constante "clé" _ECRIRE_INC_VERSION vue plus haut ;
  • définition des constantes représentant les répertoires de base de SPIP et en particulier _DIR_RACINE, racine du site, et _DIR_RESTREINT, répertoire ecrire/ sur lesquelles toutes les autres constantes de dossier seront basées (voir le détail dans le code) ;
  • recherche, sans encore l’inclure, du script config/mes_options.php [1] ;
  • initialisation de l’ensemble des globales de base de SPIP dont les variables de personnalisation (voir glossaire de SPIP.net) ;
  • inclusion de inc/utils.php ;
  • inclusion de mes_options.php optionnel ;
  • appel de spip_initialisation() si mes_options.php ne l’a pas déjà fait (en particularisant éventuellement cette initialisation). Elle prend en paramètres les quatre répertoires de base de SPIP : config/, IMG/, tmp/ et local/ et :
    • définit à partir d’eux tous les répertoires nécessaires à SPIP et les droits qui leur sont affectés ;
    • récupère et désinfecte tous les arguments de la requête : GET, POST, COOKIES et environnement serveur ;
    • installe le module de lecture/écriture/suppression de fichiers nécessaire entre autres à tous les caches ;
    • commande le chargement des métas, la configuration de SPIP, depuis la base de données... et incidemment la connection à cette base ;
  • charge les plugins à partir du cache tmp/charger_plugins_options.php en regénérant si nécessaire ce script.

Si l’on est en cours d’installation, inc_version.php a un fonctionnement particulier que nous n’aborderons pas ici.

inc/utils.php

Ce script ne réalise aucune action mais définit les fonctions utilitaires fondamentales de SPIP. Il y en a plus d’une cinquantaine ! Voici les plus importantes :

  • find_in_path() : afin de permettre la customisation du site, la plupart des fichiers (scripts, squelettes ou fichiers servis comme les images...), sont recherchés dans le "path", dans l’ordre, les répertoires :
    • squelettes : ceux optionnellement définis dans $GLOBALS['dossier_squelettes'] et squelettes/
    • des plugins activés
    • ecrire/
    • dist/
    • racine du site
  • include_spip() : permet d’inclure un script php selon le schema précédent, donc de le surcharger en fournissant une alternative (communément appelée "fork").
  • charger_fonction() : scenario identique mais adapté à une fonction, celle-ci pouvant être définie n’importe où. Le mécanisme cherche d’abord la fonction sous son nom() puis si pas trouvée, sous nom_dist() comme c’était fait historiquement (tous les fichiers de SPIP sont chargés par ces deux dernières fonctions).
  • spip_log() : utilitaire permettant de faire des logs, typiquement dans tmp/spip.log, important pour la mise au point et le suivi d’un site. A noter qu’étant basée sur un var_export(), on peut lui passer tout type de paramètre à tracer.
  • spip_query() : (en voie d’obsolèscence cf. l’api sql) toutes les requêtes SQL doivent passer par cette fonction. Important, il faut préciser les noms des tables comme spip_nomtable, la fonction se chargeant de remplacer "spip_" par le véritable préfixe des tables de l’installation.
  • _q() : (en voie d’obsolèscence cf. l’api sql) cette fonction protège les variables incluses dans une requête SQL (échappement). Il est fondamental de passer toute variable utilisée dans une requête SQL si on veut éviter des attaques par injection.
  • _request() : permet de récupérer des variables argument de la requête, sans se préoccuper qu’elles viennent d’un GET, POST ou COOKIE et en étant assuré qu’elles sont "nettoyées" correctement.
  • spip_initialisation() vue plus haut.

config/mes_options.php

Ce script optionnel permet de configurer les constantes, variables et fonctions de SPIP "à sa sauce".

On peut :

  • y adapter les variables de personalisation (globales), par exemple les dossiers squelettes spécifiques ou le type d’url propre utilisé ;
  • redéfinir des fonctions dépendant du mécanisme xxx_dist() ou plus généralement chargées par charger_fonction() ;
  • définir des "constantes" PHP : en effet, une fois définie, une constante PHP ne peut plus être changée dans la session.

En particulier, il est possible dans ce fichier personnel d’invoquer la fonction spip_initialisation() pour définir les répertoires de données et, par exemple, disposer ainsi de plusieurs sites sous SPIP utilisant une seule distribution (l’appel standard de cette fonction, plus loin dans inc_version.php, sera automatiquement neutralisé).

Argument de requête principal

Comme on l’a vu, les seuls accès à SPIP se font par index.php à la racine ou dans ecrire/. La page demandée est précisée par les arguments accompagnant cette requête. Ce peut être par GET ou POST.
Ces arguments peuvent être explicites ou générés par l’url rewriting lorsqu’on utilise les urls propres.

Il s’agit de :

  • page : c’est l’unique argument pour l’espace public. Il précise la page demandée comme sommaire (le défaut), article... Il est interprêté par ecrire/public.php pour déterminer le fond principal (le squelette.html du même nom que l’argument page) à renvoyer après l’avoir "rempli" en fonction des autres paramètres de la requête comme id_article.
  • action : bien que ce paramètre soit aussi interprêté par ecrire/public.php, il s’agit ici d’une requête effectuant (si tout va bien) une modification dans les données du serveur. SPIP fournit un mécanisme permettant de sécuriser une telle requête. Le script qui sera utilisé est action/xxx.php où xxx est la valeur de action.
  • exec : c’est typiquement l’argument d’une url "privée". Sa valeur xxx donne le script ecrire/exec/xxx.php qui sera utilisé.

Voir Étendre SPIP

Notes

[1Historiquement, ecrire/mes_options.php

, par Aurélie