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.
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) 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) :
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é.
La mutualisation peut se faire de deux façons différentes :
Détail des répertoires :
| Répertoire | Accès Apache | Accès PHP | Partage | Ecriture |
| / | oui | oui | non | non |
| CACHE | interdit | oui | non | oui |
| IMG | oui | oui | non | oui |
| aide | oui | oui | Apache, PHP | non ? |
| data | interdit | oui | non | oui |
| ecrire | oui | - | Apache | non |
| img_pack | oui | - | Apache | non |
| include | - | oui | PHP | non |
| lang | - | 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 :
Le répertoire ecrire 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 data 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 lang contient les fichiers langues. Répertoire partagé au niveau PHP.
Le répertoire aide 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 img_pack 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 include contient tout le code partagé par plusieurs pages, que ce soit de l’espace privé ou de l’espace public
Les répertoires CACHE et IMG gardent la même signification qu’actuellement.
Le répertoire NAVPICS disparaît.
(François) J’arrive sans doute un peu tard, mais quelques remarques à propos de cette nouvelle organisation :
| spip/ | nouvelle url de l’interface privée |
| spip/inc | |
| spip/lang | |
| spip/aide | |
| spip/img_pack |
| config/skel | tous les squelettes |
| config/db | lieu où se place par défaut le dump de la base réalisé depuis spip |
| config/img | l’actuel /IMG |
| config/data | l’actuel /ecrire/data |
| config/upload | l’actuel /ecrire/upload |
| config/mes_fonctions.php3 | |
| config/mes_options.php3 | |
| config/mes_urls.php3 | l’actuel /inc-urls.php3 |
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.
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 : include_local($fichier) inclut un fichier depuis un répertoire non partagé include_spip($fichier) inclut un fichier depuis un répertoire partagé (donc en détectant la présence éventuelle d’un noyau SPIP partagé sur le serveur) fichier_spip($fichier) renvoie le chemin vers un fichier SPIP partagé
Dans le répertoire /, un fichier inc.php 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 include_spip() et fichier_spip() en conséquence.
Toute page PHP commencera donc typiquement par :
Au niveau système
L’administrateur définit une variable d’environnement SPIP_SHARE_DIR 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 httpd.conf un Alias qui renvoie le chemin virtuel /spip-share vers le répertoire partagé :
Sur l’installation locale
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 .htaccess 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 .htaccess :
Modèle de fichier spip-share.php :