- l'installateur est corrigé en conséquence
- une solution, à tester, qui permet de créer certains sous-répertoires de tmp/ (sessions/ et CACHE/)

Suite à quelques essais (pas toujours réussis il est vrai) et échanges divers, l'installation de Spip, notamment en mutualisé, repose à présent sur les symboles suivants:

- plusieurs constantes _DIR_* au début de inc_version définissent les répertoires où se trouvent les sources, considérées comme inaccessibles en écriture car partageable par plusieurs sites.

- ensuite, plusieurs constantes _NOM_* définissent le nom (relatif) des fichiers et répertoires propres et indispensables à chaque site utilisant Spip, savoir 

	define('_NOM_CONFIG', 'mes_options');	
	define('_NOM_TEMPORAIRES_INACCESSIBLES', "tmp/"); 
	define('_NOM_TEMPORAIRES_ACCESSIBLES', "var/");
	define('_NOM_PERMANENTS_INACCESSIBLES', "etc/");
	define('_NOM_PERMANENTS_ACCESSIBLES', "IMG/");

	var/ comportant les images réduites créé dynamiquement
	tmp/ jouant le role d'ecrire/data  et comportant egalement CACHE/
	etc/ jouant le role de ecrire/ en tant que repertoire accessible en écriture.

- inc_version ne définit plus de fontions, mais charge immédiatement inc/utils qui à l'inverse ne fait que définir des fonctions.

- inc_version charge ensuite le fichier ecrire/mes_options.php (pour compatibilité) ou etc/mes_options (préférable aujourd'hui);

- enfin, il appelle la fonction d'initialisation ainsi:

	@spip_initialisation(
	       (_DIR_RACINE  . _NOM_PERMANENTS_INACCESSIBLES),
	       (_DIR_RACINE  . _NOM_PERMANENTS_ACCESSIBLES),
	       (_DIR_RACINE  . _NOM_TEMPORAIRES_INACCESSIBLES),
	       (_DIR_RACINE  . _NOM_TEMPORAIRES_ACCESSIBLES)
	       );

ce qui va définir les 4 répertoires accessibles en écriture à la racine du site, et initialiser toutes les autres constantes (notamment _SPIP_CHMOD).

- toutefois l'inclusion de mes_options peut neutraliser cet appel soit partiellement (en définissant quelques unes des constantes normalement définies par spip_initialisation qui ne pourra plus agir dessus) soit totalement (en appelant lui-meme spip_initialisation avec d'autres arguments que ceux ci-dessus).

Une application typique est de mettre dans ecrire/mes_options.php (ou etc/mes_otpions.php) les lignes suivantes:

define('_SPIP_CHMOD', 0770);

if ( preg_match(',/([a-zA-Z0-9_-]*)[/?],',$_SERVER['REQUEST_URI'],$r)) {
	if (is_dir($e = _DIR_RACINE . 'Ajouts/' . $r[1]. '/')) {
		$cookie_prefix = $table_prefix = $r[1];
		define('_SPIP_PATH', 
			_DIR_RACINE . 'Ajouts/' . $table_prefix  . '/:' .
			_DIR_RACINE.':'.
			_DIR_RACINE .'dist/:' .
			_DIR_RESTREINT);

		spip_initialisation(
		       ($e . _NOM_PERMANENTS_INACCESSIBLES),
		       ($e . _NOM_PERMANENTS_ACCESSIBLES),
		       ($e . _NOM_TEMPORAIRES_INACCESSIBLES),
		       ($e . _NOM_TEMPORAIRES_ACCESSIBLES)
		       );

		if (is_readable($e .=  _NOM_CONFIG . '.php')) include($e);
	}
 }

La première ligne réduit l'accès aux répertoires et fichiers créés par le serveur http à ce seul serveur. 

A partir de l'URL du script appelé, les lignes suivantes déduisent un nom qui doit etre le nom d'un sous-répertoire Ajouts dans l'installation de Spip. L'exécution de ce script commence donc par déclarer les 4 sous-répertoires spécifiques au site, ainsi que le préfixe de ses table SQL. Au cas où existerait un fichier etc/mes_options pour ce site spécifique, celui est également chargé.

L'utilisation des constantes _NOM_* permet donc de disposer d'un ensemble de répertoires et fichiers qui n'ont meme pas à savoir s'ils utilisent une installation mutualisée ou non de Spip.

ATTENTION: il faut bien voir que les fonctions de inc/utils ne seront vraiment utilisables qu'après appel de spip_initialisation, car les constantes qu'elles utilisent (_DIR_TMP, _DIR_IMG etc) ne sont pas encore définies à l'entrée de mes_options (c'est justement ce qui permet de les personnaliser).

permettre d'installer, pas de mes_options dans _DIR_CONFIG (logique a reviser); deplacement de spip_abstract_quote dans les vieilles_defs

preserve l'environnement (2Ko d'economie sur le source quand meme .. :p )

quelque chose m'echappe peut-etre, mais il n'y a visiblement plus aucune raison que cette fonctione ne soit pas dans inc/utils

On déplace la définition de _SPIP_CHMOD dans un fichier à part (il concerne le file_system, pas la base de données) dans config/. Il s'appelle chmod.php, c'est original...

Ce qui marche mieux pour le surcharger dans mes_options.php, et c'est inc_version.php qui lui donne une valeur par défaut, le cas échéant. Ce fichier est crée pour une nouvelle installation. Sur une mise à jour, il ne se passe rien, on fait du 777 comme avant.

config/ abrite donc potentiellement deux fichiers, ça prend son sens maintenant :)... et on pourrait imaginer que ldap soit indépendant de la même manière... mais rien ne presse...

ça règle un soucis de création du cache en fichier plat aussi (cf. #635)

Suite de [7668]: il faut distinguer les noms des répertoires et leur localisation absolue pour faciliter la mutualisation.

rustine pour _SPIP_CHMOD (toggg: [http://thread.gmane.org/gmane.comp.web.spip.devel/37325/focus=37325])

la fonction spip_initialisation_parametree prend désormais 4 paramètres représentant les 4 répertoires non partageables d'un SPIP.
_DIR_CHMOD, s'appelle maintenant _SPIP_CHMOD et est calculée à l'installation de spip. On colle la constante dans le fichier de connection.
On ajoute le répertoire tmp_img/ qui servira de base aux données volatiles mais devant être accessible via http. C'est là qu'on calculera tous les images réduites, (à tester)
On en profite pour faire une très légère toilette au page d'installation. C'est pas encore fantastik ;)

TODO: la vérification des sous-répertoires de tmp/ en écriture, voire, leur création à la volée

revision des ajax_action_declencheur() a cause d'un bug debile de Safari... j'espere que ca ne casse rien, mais ca permet de contourner un truc bizarre dans le plugin async_upload/, ou l'operation de recopie des noeuds correspondants aux documents ajoutes cassait le onsubmit.

L'espace privé passe en XHTML 1.0 transitionnal: suite aux nombreuses réécritures de ces derniers temps pour placer du Ajax à tous les coins de formulaire, le code HTML de l'espace privé est à présent très proche de ce standard. Les erreurs restantes sont pour la plupart communes avec le HTML4, il n'est donc plus nécessaire de conserver ce Doctype anté-diluvien.

Ce dépot résoud aussi #617 (qui a involontairement permis de trouver des
non conformités XHTML).

nommage daté et incremental des noms de sauvegarde dump_20061008_000.xml.gz pour echapper a un ecrasement malveillant
liste radio des dumps disponibles pour la restauration

Suite [7549]: Introduction de la fonction ajax_retour utilisés par TOUS les scripts envoyant une réponse Ajax. Cette fonction est en fait le bout de code figurant auparavant dans index.php qui n'a ainsi plus besoin de distinguer les deux formes de retour et est donc plus court.

Cette simplification a été rendue possible en inversant le chantier prévu lors de la [7310]: les scripts en réponse Ajax utilisent echo, via ajax_retour. Un fichier index.php comportant l'unique echo de tout le code PHP de l'espace privé reste l'objectif final, mais il est préférable d'unifier d'abord ainsi, et de basculer lorsque chaque script de exec/ ne comportera plus qu'un seul echo.

Tâche #328 sans douleur: utils.php inclue les retraités, mais les jeunes contrib' sont invitées à couper le cordon à leur majorité.

Tâche: #328: include_ecrire part dans maison de retraite inc/vieilles_defs.php. Après retrait de son dernier rôle de figuration.

Permettre la surcharge des etapes d'installation. En profiter pour les mettre dans un répertoire différent, inc/ devenant vraiment trop gros. Et extension de charger_fonction pour qu'elle accepte des répertoires de profondeur quelconque (pas encore utilisé finalement mais ça finira par servir).

introduction de _DIR_CHMOD, une constante permettant de définir les permissions des fichiers créés par spip.

Suite de [7435]: migration de img_pack, qui ne pouvait déjà plus rester dans ecrire/, avec son .htaccess potentiel, depuis que le squelette agenda (via ses filtres associés) référence certaines images de img_pack. Ce répertoire comportant aussi quelques css, le bilan définitif de toutes ces migrations est le suivant:

- toutes les .css se trouvent dans dist/, les scripts de l'espace privé retrouvant les siennes car il utilise systématiquement find_in_path (qui contient dist/) pour les retrouver;

- toutes les images auparavant en img_pack se trouvent à présent dans dist/images (constante _DIR_IMG_PACK changée en conséquence)

- toutes les vignettes de documents se trouvent en dist/vignettes (la constante _DIR_IMG_ICONES_DIST a donc cela comme valeur, apres avoir connu IMG/icones, ecrire/img_pack/icones puis dist/img/icones)

- toutes les icones de la barre de saisie se trouvent en dist/icones_barre (la constante _DIR_IMG_ICONES_BARRE a donc cela comme valeur, apres avoir connu IMG/icones_barre, ecrire/img_pack/icones_barre puis dist/img/icones_barre)

Et (inchangé pour ce dépot) tous les javascripts sont dans dist/javascript.

L'utilisation de Spip avec LDAP et plus généralement avec un .htaccess dans ecrire/ provoquait des demandes d'authentification dans l'espace public,
suite à la migration (pour cause de mutualisation) dans ecrire/img_pack/icones et ecrire/img_pack/icones_barre, des icones autrefois dans IMG/icones et IMG/icones_barre. Problème similaire avec les fichiers Javascript qui ne peuvent plus etre dans ecrire/ lorsqu'ils sont référencés dans le squelette agenda. 

En conséquence, création d'un répertoire dist/img comportant trois sous-répertoires: les 2 d'icones mentionnés ci-dessus, et un répertoire javascript/ contenant tous les .js auparavant dans img_pack. Le changement est transparent pour les icones, car ils étaient référencés par deux constantes qu'il a suffit de redéfinir:

define('_DIR_IMG_ICONES_DIST', _DIR_RACINE . "dist/img/icones/");
define('_DIR_IMG_ICONES_BARRE', _DIR_RACINE . "dist/img/icones_barre/");

Pour Javascript, introduction de la constante:

define('_DIR_JAVASCRIPT', (_DIR_RACINE . 'dist/javascript/'));

et utilisation de celle-ci dans les squelettes et les .php référençant ces fichiers.

A terme il faudra prévoir la migration de tout le reste de img_pack, le squlette agenda ne faisant que préfigurer un partage des ressources entre les deux espaces.

Chargement des zip: ne pas proposer le déballage si aucun fichier n'est déballable. En revanche, proposer un 3e mode: le déballage ET le conservation telle quelle. Attention, il y a une locution à traduire (ie un apppel de _L).

une fonction find_all_in_path qui retrouve l'occurence utilisee par find_in_path d'un type de fichier (defini par un $pattern) dans un sous repertoire eventuel du chemin

donc on aplatit que si il y a 'data'

le retour du premier appel d'un pipeline non déclaré, au format array, n'etait pas applatit par la fonction pipeline
Manque de chance, le pipeline agenda_rendu_evenement etait déclaré de facon erronee (rendu_evenement).
2 bugs en un donc, corrigés d'un meme coup

petite proposition. Methode SET pour _request() qui permet de xxx dans $_POST['var'] si on ecrit _request('var', xxx);

_request('var') fait toujours son boulot ...

Fusion des parametres d'URL var_ajax et var_charset en un seul: var_ajaxcharset. Elle est mise d'office par les fonctions javascript utilisant Ajax, et aussi par ajax_action_auteur dans l'argument Redirect, pour etre repéré par la séquence à la fin de index.php. A noter que celle-ci est en fait inutile sauf pour le mini-navigateur de rubrique, on devrait pouvoir s'en passer totalement à terme.

report de [7281] et [7282] de la branche 1.9 vers le repertoire spip/ (gros bug ajax sur charset iso-8859-1)

Les fonctions spip_query et spip_connect admettent un argument supplémentaire optionnel indiquant un serveur de base de données. Le résultat de spip_connect est la fonction à appeler pour effectuer une requete au serveur. Ces fonctions de requetes sont indiquées dans un tableau statique indexé par les différents serveurs. Le tableau est vide au départ, et s'enrichit lors du  premiere appe de spip_connect avec un argument nouveau, S. A ce moment, spip_connect charge le fichier base/S.php et invoque la fonction sans argument base_S censée initialisée la connexion au serveur et retourner le nom de la fonction de requetes. Cette fonction est mémorisée dans le tableau statique, afin qu'aux appels suivants, spip_connect retourne immédiatement cette fonction. Ainsi, spip_query peut appeler systématiquement spip_connect sans perte de performances.

Cette interface est complètement transparente dans le cas habituel. La globale db_ok (qui n'apparait plus que dans base/db_mysql et une fois à l'installation)  est en particulier toujours disponible, mais doit etre considérée comme obsolète: il faut appeler spip_connect() pour savoir si la base est disponible et initialiser la connexion si ce n'est fait.

L'utilisation principale de ces changements est de pouvoir appeler spip_query(requete, serveur) dans les fonctions implémentant les modèles de fonctions de abstract_sql.php. En particulier, la fonction par défaut spip_query_db qui repose sur des globales décrivant la connexion standard, peut etre remplacée par une autre fonction  s'adressant à un autre serveur SQL, tout en profitant de toutes les autres fonctions de db_mysql.