SpipLab:StructureDesRepertoires

{{{Avancement}}}

- La réorganisation des répertoires telle qu'exposée ci-dessous est à peu près terminée dans la branche "spiptmp" (où, je n'ai pas trouvé ? est-ce encore d'actualité ? mdebeaumont) du CvS. Il reste quelques broutilles.

- Il faut maintenant étudier l'organisation des FichiersDePersonnalisation.

----

{{{Pourquoi modifier la structure des répertoires ?}}}

La structure actuelle est satisfaisante sur les points suivants :
- lisibilité (simple à comprendre)
- séparation des espaces (public / privé)
- ne complique pas le travail du webmaster (le répertoire racine n'est pas trop peuplé, bien que cela soit de moins en moins vrai)

Elle ne permet pas, cependant, de mutualiser le code SPIP entre plusieurs installations (cf. MultiSPIP). Or un SPIP 1.7 décompressé fait 12 Mo à lui tout seul. Cela occupe de l'espace disque et, dans le cas de beaucoup de petits sites SPIP hébergés sur un même serveur, le cache disque (et les systèmes de type ""[PHPAccelerator->http://www.php-accelerator.co.uk/]"") devient beaucoup moins efficace.

D'autre part, le répertoire ecrire grossit un peu trop et il serait plus lisible de mettre les fichiers inclus dans un répertoire séparé.

Il faut donc à la fois :
- remodeler la structure pour permettre la mutualisation des parties "immuables" de SPIP
- tout en conservant les avantages énoncés plus haut

{{Important :}} la définition d'une nouvelle structure dépend fortement de la possibilité, ou non, de pouvoir RemonterDansLesRepertoires en PHP.

{{Important 2:}} CVS ne gérant pas les renommages et déplacements de fichiers, cette tâche sera l'une des toutes premières afin de ne pas gâter l'historique.

{{Gestion des backups}} (FrancoisSchreuer) Un aspect qui semble devoir être pris en compte également dans la réorganisation des répertoires est la facilité de backup. Il faut pouvoir isoler les éléments propres à chaque site du "moteur de spip" afin de pouvoir facilement sauvergarder ces éléments sans backuper tout le système. Ces éléments sont (en plus de la base de données) :
-* Les couples de fichiers squelettes (une option permet déjà de placer les fichiers .html dans un répertoire séparé mais il faut logiquement avoir recours à mod_rewrite si l'on veut faire de même pour les fichiers .php);
-* Le répertoire IMG;
-* Le fichier <code>mes_fonctions.php3</code> ainsi que <code>mes_options.php3</code>;
-* Le fichier <code>inc-urls-....php3</code> si l'on utilise un système de réécriture des urls et que les standards proposés par <code>inc-urls-html.php3</code> ne suffisent pas;

{{Evolution du code}} (Emmanuel Saint-James) Encore une autre nécessité de la réorganisation: la possibilité de  faire cohabiter ou de migrer vers d'autres langages que ceux utilisés actuellement (savoir PHP4, MySQL3 et HTML4). On peut penser que Spip soit à terme capable de produire des requêtes pour d'autres serveurs SQL, qu'il devienne nécessaire de coder certaines parties dans un langage plus efficace que PHP4, que certains dérivés de HTML soient nécessaires pour certaines utilisations. On pourrait alors convenir de l'organisation suivante:

- les scripts appelables par URL utiliseraient comme  seules instructions PHP:  {echo}, {header}, {if} et {include}
(pas de déclaration de fonctions, pas d'affectation) et des appels de fonctions définies dans les fichiers inclus;
- le répertoire d'inclusion comporterait au minimum 3 sous-répertoires: HTML4, PHP4, MySQL3;
- tout code produisant du HTML4 devra figurer sous forme de fonctions dans HTML4 et nulle part ailleurs;
- tout code produisant du MySQL3 devra figurer sous forme de fonctions dans MySQL3 et nulle part ailleurs;
- le sous-répertoire PHP4 contiendrait les fonctions d'utilité générale (ni HTML, ni SQL).

Chaque script appelable par URL aurait, si besoin, un homonyme dans les 3 sous-répertoires, contenant les fonctions fournissant
le service demandé dans le langage désiré. Ce nommage permettrait de relier facilement ce qui doit l'être malgré l'éloignement dans
l'arborescence, les 3 fichiers homonymes pouvant évidemment eux-mêmes faire des inclusions.

-- Peux-tu donner un exemple concret du fonctionnement d'une telle structure ? Pourquoi ne pas utiliser plus classiquement une couche d'abstraction pour la base de données ?

-- oui: le nouveau script {calendrier} et ses sbires sur le CVS depuis le 12/7/2004.

Le but visé est plus général qu'une couche d'abstraction:
on peut vouloir sécuriser les accès à la BD en ayant plusieurs utilisateurs avec des droits différents, 
ou en copiant une partie de la BD sur un serveur mirroir en lecture seule;
partant, il est bon d'avoir une API standardisée sur laquelle on va pouvoir ajouter des fonctionnalités
que les couches d'abstraction n'offrent pas, ou à un coût trop élevé.
----

{{{Brouillon, à modifier}}}

La mutualisation peut se faire de deux façons différentes :
-* pour les fichiers appelés directement par le Web (pages, images...), en utilisant une directive Apache du type ""<code>Alias</code>"" vers le répertoire partagé.
-* pour les fichiers appelés via PHP (includes, fichiers langue...), en utilisant un réglage global et des fonctions ad hoc ({include_spip()}). Le réglage global pourra être détecté automatiquement grâce à la présence d'une variable d'environnement (SPIP_SHARE_DIR) réglée par l'hébergeur sur le serveur.

|{{Répertoire}}|{{Accès Apache}}|{{Accès PHP}}|{{Partage}}|{{Ecriture}}|
|<code>/</code>|oui|oui|non|non|
|<code>CACHE</code>|{interdit}|oui|non|oui|
|<code>IMG</code>|oui|oui|non|oui|
|<code>aide</code>|oui|oui|Apache, PHP|non?|
|<code>data</code>|{interdit}|oui|non|oui|
|<code>ecrire</code>|oui|-|Apache|non|
|<code>img_pack</code>|oui|-|Apache|non|
|<code>include</code>|-|oui|PHP|non|
|<code>lang</code>|-|oui|PHP|non?|

- {{La racine}} doit être la plus simple possible et laisser place nette aux fichiers du webmestre (les squelettes) pour que celui-ci ne s'embrouille pas dans son travail. Hormis les squelettes, elle contient les fichiers suivants :
-* inc-public.php / inc_public.php3, fichier unique appelé par les squelettes
-* spip_cal.php, pour interrogation du calendrier par des outils tiers (iCal)
-* spip_cookie.php, pour pose du cookie depuis le bon niveau de l'arborescence Web (nécessaire pour la compatibilité tous navigateurs)
-* spip_login.php, pour accéder à l'espace privé
-** (NicolasHoizey) Ne serait-il pas pertinent de mettre par défaut les squelettes dans un sous-répertoire ? Cela a des inconvénients pour la logique de prise en main (les URL relatives principalement), certe, mais l'avantage de la « propreté » de la racine.
-*** (FrancoisSchreuer) Autre avantage : de cette manière, il est bcp plus facile de les sauvergarder.

- {{Le répertoire <code>ecrire</code>}} contient un fichier .php par page de l'espace privé. Répertoire partagé au niveau Apache. (Yannick: lecture uniquement, donc?).

- pour lang/ et aide/ on peut envisager un système de téléchargement automatique à la demande d'une langue, plutôt que de dowloader tout d'un coup ?

- {{Le répertoire <code>data</code>}} contient les fichiers de l'actuel répertoire ecrire/data, plus inc_meta_cache.php et inc_connect.php (Yannick: le seul en rw?)

- {{Le répertoire <code>lang</code>}} contient les fichiers langues. Répertoire partagé au niveau PHP.

- {{Le répertoire <code>aide</code>}} contient les fichiers de l'aide internationalisée. Répertoire partagé au niveau PHP et Apache (à cause des images de l'aide).

- {{Le répertoire <code>img_pack</code>}} contient les images de l'espace privé et celles par défaut de l'espace public. Répertoire partagé au niveau Apache.

- {{Le répertoire <code>include</code>}} contient tout le code partagé par plusieurs pages, que ce soit de l'espace privé ou de l'espace public

- {{Les répertoires <code>CACHE</code> et <code>IMG</code>}} gardent la même signification qu'actuellement.

- {{Le répertoire <code>NAVPICS</code>}} disparaît.

----

(François) J'arrive sans doute un peu tard, mais quelques remarques à propos de cette nouvelle organisation :

-* Ne vaudrait-il pas mieux mettre tous les répertoires partagés au niveau apache dans un seul ? Ca évite des conflits potentiels avec d'autres répertoires partagés sous apache. Par exemple:

-* Ne serait-il pas, dans la même logique, de mettre tous les éléments susceptibles d'être sauvergardés dans un seul répertoire ("perso" ou "config"), de façon à permettre les backups très facilement (il suffirait de sauvergarder .

Une séparation entre ces deux grandes parties (spip/ et config/, à quoi il faudrait ajouter le cache) offre en outre l'avantage non négligeable de complètement séparer le moteur de spip de son contenu. Pour l'utilisateur qui se trouve chez un hébergeur proposant spip en "partagé apache", plus de souci de mise à jour. Une distribution spip pourrait donc ne plus contenir que le répertoire spip.

----

{{{Gestion des inclusions (mutualisation PHP)}}}

A l'heure actuelle, on a deux fonctions distinctes : include_local et include_ecrire(). Ces fonctions gèrent l'inclusion unique (à la place d'include_once() qui n'existait pas en PHP3).

Elles seront remplacées par les fonctions suivantes :
- <code>include_local($fichier)</code> inclut un fichier depuis un répertoire non partagé
- <code>include_spip($fichier)</code> inclut un fichier depuis un répertoire partagé (donc en détectant la présence éventuelle d'un noyau SPIP partagé sur le serveur)
- <code>fichier_spip($fichier)</code> renvoie le chemin vers un fichier SPIP partagé

Dans le répertoire <code>/</code>, un fichier <code>inc.php</code> servira de point d'entrée pour définir les fonctions ci-dessus. La mise en place consiste à détecter la présence la variable d'environnement SPIP_SHARE_DIR et à définir <code>include_spip()</code> et <code>fichier_spip()</code> en conséquence.

Toute page PHP commencera donc typiquement par :

<cadre><?php

include("inc.php");

include_spip("include/auth.php");
include_spip("include/presentation.php");

(...)</cadre>

----

{{{Mutualisation Apache}}}

- L'administrateur définit une variable d'environnement <code>SPIP_SHARE_DIR</code> pointant vers le répertoire SPIP partagé (qui contient lui-même les sous-répertoires include, lang, etc.). Par exemple /usr/share/spip.

- Il définit de plus dans <code>httpd.conf</code> un Alias qui renvoie le chemin virtuel <code>/spip-share</code> vers le répertoire partagé :
""<cadre>
Alias /spip-share /usr/share/spip
SetEnv SPIP_SHARE_DIR /usr/share/spip
</cadre>""

Lorsqu'il est lancé par l'utilisateur, l'installateur (spip_loader) détecte la présence de la variable SPIP_SHARE_DIR et effectue une installation mutualisée. Pour cela, il crée un fichier <code>.htaccess</code> dans le répertoire d'installation qui permet de renvoyer les répertoires partagés vers l'endroit défini par l'administrateur système. Ces répertoires sont aussi créés en local, mais vides (pour gérer correctement les redirections lorsque le slash final est omis).

Deux mécanismes différents sont utilisés pour le renvoi vers les répertoires partagés :
- {pour les scripts} (.php, .php3), redirection vers un wrapper situé à la racine qui inclut le fichier appelé (on ne peut pas rediriger directement vers le fichier appelé à cause des problèmes d'uid/gid liés au safe mode). Le nom du fichier est récupéré dans SPIP_SHARE_FILE ou REDIRECT_SPIP_SHARE_FILE.
- {pour les fichiers statiques}, redirection directe vers le répertoire partagé (afin qu'Apache règle les en-têtes HTTP par lui-même)

Modèle de fichier <code>.htaccess</code> :

""<cadre>
# <SPIP_SHARE> do not modify
RewriteEngine On
RewriteRule ^((aide|ecrire|img_pack)/(.*\.php3?))$ spip-share.php [QSA,L,E:SPIP_SHARE_FILE=$1]
RewriteRule ^((aide|ecrire|img_pack)/(.*))$ /spip-share/$1 [QSA,L]
# </SPIP_SHARE>
</cadre>""

Modèle de fichier <code>spip-share.php</code> :

""<cadre>
<?php
$fichier = $HTTP_SERVER_VARS['SPIP_SHARE_FILE'];
if (!$fichier) $fichier = $HTTP_SERVER_VARS['REDIRECT_SPIP_SHARE_FILE'];
if (!$fichier || strstr($fichier, '..')) exit;
$dir = $HTTP_ENV_VARS['SPIP_SHARE_DIR'];
if (!$dir) $dir = $HTTP_SERVER_VARS['SPIP_SHARE_DIR'];
if (!$dir) exit;
include($dir.'/'.$fichier);
?>
</cadre>""