permettre de ranger ses formulaires personalisés dans squelettes/formulaires/ (les fichiers php associés pouvant soit rester dans ecrire/balise/ soit etre personalisés aussi et placés dans squelettes/balise/)

Les essais de mutualisation (cf ticket #186 très bien extrapolé par http://www.spip-contrib.net/Un-noyau-SPIP-1-9-plusieurs-sites) ayant révélé quelques oublis, introduction d'une fonction spip_initialisation_parametree qui définit les répertoires et fichiers qui doivent absolument etre définis et qui ne sont pas mutualisables. Il suffit donc à mes_options d'appeler cette fonction avec les répertoires  souhaités pour etre certain de ne rien oublier.

Cette mise au carré a provoqué la disparition de la constante _DIR_INCLUDE qui n'est en fait plus utile depuis que Spip est mutualisable.

A noter que spip_initialisation_parametree exige 2 répertoires en arguments
et non un seul, car data/ upload/ et inc_connect sont traditionnellement dans
ecrire/ et non à la racine comme les autres. Il serait utile de revenir 
là-dessus à terme, et de geler ecrire/ comme répertoire en lecture seule.

Aussi dans ce dépot: petit partage de code autour de minipres.

Fil & Emmanuel

modif importante du code du portfolio : on laisse le lien vers le fichier image (accessibilite) mais en javascript on substitue l'adresse de la page qui affiche l'image au sein de l'article (le &id_document=X) ; cette modif permet d'eviter que les moteurs de recherche ne chargent les 36 versions de mon article (si j'ai 36 images) ; elle permet aussi de faire des plugins genre lightbox qui ont besoin des URLs des images. Seule perte de fonctionnalite : sans js on n'a plus la jolie presentation de chaque image in situ.

Complément à [6830]: le texte disant s'il s'agit d'abonnés de forums ou de rédacteurs est décidé par le code PHP, le squelette n'en sachant rien.

Le formulaire d'inscription souffrait de quelques incohérences: en cas d'erreur (mauvaise adresse mail etc) le formulaire n'aparaissait plus, donc impossibilité de corriger la saisie.

Mais surtout, depuis qu'il est possible d'avoir simultanément des visiteurs et des rédacteurs spontanés, il faut pouvoir dire auquel de ces deux publics est destiné le formulaire. Cette balise accepte donc maintenant un argument qui doit valoir "redac" ou "forum" selon le cas. Elle admet aussi un argument supplémentaire de libre interpétation (par exemple un numéro de rubrique ou d'article si l'on veut filtrer les inscrits par leur mail pour ce numéro) et un troisième qui est considéré comme le nom de la balise recevant le focus.

permettre un tri dynamique sur un champ issu de jointure : le champ de tri dynamique n'est préfixé par le nom de la table que si il en fait effectivement partie. Dans le cas contraire, on le laisse tel quel, en esperant que ca matchera un champ issu d'une jointure...

retablit le bon fonctionnement XHTML des raccourcis [<dov3|center>->url], qui avait saute suite a l'introduction des fonctions calculer_url_xxxxx, cf. http://forum.spip.org/fr_184158.html

Réhabilitation des familles de typo habituelles dans l'espace privé (pas de "Bitstream Vera Serif")

trop d'enthousiasme sur la mise en cookie des informations du visiteur : le nom et l'email suffisent ; pas la peine de stocker l'url donnée

gros bug dans la conversion des entites HTML : dès qu'une conversion était demandée en mode "secure", toutes les suivantes étaient aussi sécurisées, ce qui avait pour conséquence, par exemple, que la syndication importait non plus du html mais du html échappé (on voyait les tags apparents).

forcer le filtre |?{a,b} à avoir deux arguments : ça évite des parse error terribles quand on a un filtre "mal écrit" du genre |?{1}

mais ça permet désormais de faire :

[(#BALISE|?)]      (aspire les données et ne sort jamais rien)
[(#BALISE|?{yo})]  (affiche "yo" si la balise est non vide)
[(#BALISE|?{yo,spip})]  (cas habituel)

retour des boutons d'admin sur les pages 404 (très pratique notamment pour les articles dépubliés, car le bouton sait reconnaître l'id_article)