Séquence de démarrage

Le snippet ci-dessous décrit, dans les grosses mailles, la séquence de démarrage de SPIP, au 30 janvier 2025.

C’est décrit au niveau fichier. Et ça devrait nous permettre de savoir par quoi un appel HTTP passe, pour déterminer les impacts d’un changement dans la séquence.

Valable pour les versions 4.3, 4.4, et 5.x, en s’arrêtant à l’appel éventuel de recuperer_fond() , moment à partir duquel la séquence passe au compilateur puis au rendu.

1 « J'aime »

Et voici une « vue » de l’arborescence de base d’un SPIP :

Si vous n’avez pas de compte gitlab, ce n’est pas grave, voici une copie au 31 janvier 2025 :

.                       # (répertoire racine) (lecture seule) (exposé sur le web) (assets)
├── .htaccess           # (facultatif)
├── IMG                 # (accessible en écriture pour le user web)
├── config              # (non-accessible en écriture pour le user web) (à protéger pour l'accès par le web)
|   └── bases           # (facultatif) (accessible en écriture pour le user web)
├── ecrire              # Noyau ET espace privé.
|   |                   # Livré dans la distribution classique. Mis à jour avec elle.
│   ├── index.php       # Point d'entrée back-end
│   ├── inc_version.php # Bootstrap commum
│   └── prive.php       # Point d'entrée auth public
├── lib                 # (facultatif) (accessible en écriture pour la gestion des plugins par le web)
├── local               # (accessible en écriture pour le user web)
├── plugins             # (facultatif)
|   └── auto            # (facultatif) (accessible en écriture pour la gestion des plugins par le web)
├── plugins-dist        # Extensions de SPIP activées automatiquement et non désactivables.
|                       # Livrées dans la distribution classique. Sont mis à jour avec elle.
├── prive               # Là où est installé le jeu de squelettes par défaut de l'espace privé de l'application.
|                       # Livré dans la distribution classique. Mis à jour avec elle.
├── spip.php            # Point d'entrée front-end (éventuellement via `./index.php`)
├── squelettes          # (facultatif)
├── squelettes-dist     # Là où est installé le jeu de squelettes par défaut de l'espace public de l'application.
|                       # Livré dans la distribution classique. Mis à jour avec elle.
├── tmp                 # (accessible en écriture pour le user web) (à protéger pour l'accès par le web)
└── vendor              # Dépendances composer. (à protéger pour l'accès par le web)
    └── autoload.php    # Autoloader.

ça coïncide avec la séquence de démarrage, c’est heureux.

les trucs entre parenthèses indique une ou des conditions des répertoires :

  • répertoire racine : là où est installée la distribution SPIP
  • exposé sur le web : le serveur web (apache ou autre) fait pointer une URL sur le répertoire
  • lecture seule : si le contenu de ce répertoire n’est pas modifiable, ainsi que ces sous-répertoires, sauf mention contraire, c’est une bonne chose.
  • à protéger pour l’accès par le web : il est impératif que ce répertoire ne puisse être accédé à travers un navigateur web.
  • non-accessible en écriture pour le user web[1][2] : Il est fortement recommandé d’empêcher le user web de pouvoir écrire dans ce répertoire
  • facultatif : comme son nom l’indique, si ce répertoire n’est pas présent, SPIP doit fonctionner quand même
  • accessible en écriture pour le user web : le user web doit pouvoir écrire dans ce répertoire
  • accessible en écriture pour la gestion des plugins par le web[3] : upload de plugins depuis l’interface graphique de SPIP
  • assets : ce répertoire, et ses sous répertoires, contient des resources (css, js, images, documents) qui doivent être accessible par le web.
  • multiple : il peut exister plusieurs occurences de ce répertoire

  1. Sauf lors des étapes d’installation, et parfois de mise à jour, via l’interface web. ↩︎

  2. Sauf si une base SQLite est installée dedans (config/bases/spip.sqlite) ↩︎

  3. Pour spip/svp ↩︎

Si on essayait d’avoir un sous-répertoire ./public (déjà évoqué à la fois sur ce forum et dans quelques issues gitlab) ça pourrait donner l’arborescence décrite dans Arborescence de la distribution standalone de SPIP ($21) · Extraits de code · GitLab

Le problème qu’il faudrait résoudre, c’est de réduire l’accès par le web à un seul point d’entrée et d’introduire un « routeur PHP » dans la séquence d’exécution au bon endroit, d’un part, et de résoudre aussi le problème des assets distribués par des composants qui ne sont plus exposés sur le web : 2 sujets très complexes.

Une autre hyptothèse, dans une approche d’installation SPIP « mutualisée »

Si les 2 problèmes mentionnés plus haut sont résolus, ce type d’installation ne pose pas de problèmes supplémentaires.