Warning, changement des urls spip
Toutes les urls spip changent avec la 1.9 ( qui mériterait d’être une 2.0 j’insiste lol ), tous les fichiers de spip ( espace public mais aussi /ecrire ) changent, Il est donc important pour que les liens vers votre site fonctionnent encore d’utiliser le fichier htaccess.txt fourni ( voir cei dessous ).
De plus n’hesitez pas a verifier les droits ( permissions unix ) des fichiers car de nombreux nouveaux fichiers seronr crees.
La version de Spip en cours de développement vise à terme
l'installation d'une unique distribution utilisable pour tous les
hébergés d'un meme serveur.
Idéalement, chaque hébergé aurait comme
seuls scripts standards dans son répertoire personnel:
index.php (egal à l'actuel page.php3, donc utilisant les squelettes)
ecrire/index.php (egal à l'actuel inc.php3)
Et deux répertoires accessibles en ecriture par le serveurs http:
- l'un, visible des navigateurs, et correspondant à IMG/ sauf les
icones standards
- l'autre, non visible des navigateurs, incluant CACHE/ ecrire/data,
ecrire/upload et un fichier qui serait la fusion de l'actuel
inc_version.php et du inc_connect personnel, plus des informations
permettant de charger les fichiers de la distribution commune.
Le but poursuivi est d'économiser de l'espace disque pour chaque
hébergé, et potentiellement d'améliorer les perfomances globales des
hébergeurs accueillant de nombreuses copies de Spip, en permettant à
cette unique exemplaire de résider plus souvent dans le cache du
serveur http.
Nous espérons atteindre ce but de manière transparente pour tous ceux
qui utilisent Spip sans modifier ou explicitement referencer les
fichiers PHP standards (donc Spip tel quel, ou avec des squelettes
originaux .html). Pour les autres, en particulier beaucoup des
contributions sur spip-contrib, il faudra tenir compte du
déménagement des fichiers de Spip si l'on veut profiter de cette
version partagée (mais il sera toujours possible de se télécharger
une version complète personnelle). Afin de ne pas renouveller une
autre fois un tel changement, on profitera de l'occasion pour:
- laisser tomber les trompeuses extensions.php3,
- donner une possibilité de personnalisation de l'espace public (sans
aller jusqu'à sa réécriture sous forme de squelette, encore trop
lointaine).
On en a également profité pour faire une chasse systématique aux
failles de sécurité.
Pour parvenir au but fixé, nous allons procéder en plusieurs étapes,
la première concernant le répertoire ecrire, et la présente annonce
est un appel à commentaire sur les difficultés que pourrait poser sa
métamorphose. Les problèmes posés par les autres repertoires seront
abordés ultérieurement.
Le repertoire ecrire actuellement disponible sur le dépot SVN
totalise 70 scripts (fichiers provoquant une execution) et 130
bibliothèques (fichiers contenant seulement des déclarations).
Tous les bibliothèques seront déménagées dans un répertoire de
distribution indiqué par la constante _DIR_INCLUDE, avec un léger
renommage pour disposer d'une identité de nom entre un script, sa
bibliothèque et sa fonction principale pour les rares fois où ce
n'est pas déjà le cas.
Presque tous les scripts actuels se contentent de charger le fichier
inc.php3 qui invoque la fonctionnalité désirée en se fondant sur la
globale $SCRIPT_NAME fournie par le serveur http. Le basculement vers
un script unique sera obtenu en remplaçant les appels ecrire/X.php3
actuels (environ 600 dans le code) par ecrire?spip_execute=X, ce qui
provoquera le chargement de la bibilothèque X et l'invocation de la
fonction X censée y etre définie. Par mesure de sécurité, le script
unique executera la séquence:
if (!$f = (find_in_path($spip_execute))) $f = _DIR_INCLUDE .
$spip_execute
unset($spip_execute);
include($f);
$spip_execute();
chaque bibliothèque étant supposée réaffecter $spip_execute à la
fonction à invoquer.
Ce dispositif permet à la fois de se protéger de l'exécution de
fichier non prévu à cet usage, et d'ouvrir la porte à la
personnalisation de l'espace privé via find_in_path et une
réaffectation de $spip_execute à autre chose que la fonction standard
associée.
Il y aura du travail à prévoir sur la définition des url propres etc
vu le nouveau nommage des scripts. Les scripts actuels, encore
compatibles avec celles-ci, resteront disponibles pour copie
éventuelle dans le répertoire personnel (leur taille est inférieure
au Ko à présent et on peut les factoriser par des liens,
l'encombrement sera donc négligeable).
Par ailleurs, les répertoires ecrire/lang, ecrire/polices, ecrire/
charsets, ecrire/safehtml ecrire/img_pack, IMG/icones et IMG/
icones_barre seront eux-aussi déménagés dans la distribution commune,
avec une constante _DIR_X spécifique mentionné dans le fichier de
personnalisation.
> Quelqu'un voit une solution ?
Tentative de résumé du problème.
On a donc trois critères à articuler entre eux :
* accès http oui/non
* accès en écriture pour le serveur oui/non
* à backuper oui/non
La combinatoire donne... 8 possibilités (donc 8 répertoires :( ?)
Schématiquement, le plus simple pour combiner tout ça serait peut-être
bien une structure de répertoires ressemblant à ceci :
mon_site_spip/
public/
img/
squelettes/
prive/
dump_base/
config/
plugins/
polices_perso/
upload/ (?)
donnees_provisoires/
miniatures/
cache/
data/
upload/ (?)
Lors de l'install, il faudrait donc demander les droits d'écriture sur
donnees_provisoires/ et sur mon_site_spip/img/ (les sous-répertoires de
donnees_provisoires/ pouvant être créés automatiquement) et poser deux
fichiers .htaccess "deny from all" sur donnees_provisoires/ et
mon_site_spip/prive/.
Ca fait deux répertoires en écriture au lieu de quatre actuellement,
avec l'avantage qu'il suffit de rapatrier le répertoire mon_site_spip/
et rien d'autre pour backuper tranquillement un site SPIP.