prendre en compte $spip_matrice au niveau du compilateur (nécessite d'appeler une fonction filtrer($filtre, $arguments) qui chargera le fichier de définition de $filtre avant d'appeler la fonction avec les arguments)

inutile de passer safehtml sur les champs dont on est sûrs (id_truc, ceux qu'on remplit nous-mêmes, etc)

changement d'API des pipeline, de manière à les rapprocher de l'écriture des filtres dans les squelettes ; au lieu d'un Array('filtre1', 'filtre2'), un pipeline est désormais décrit sous la forme '|filtre1|filtre2'

A faire : autoriser aussi |filtre{arguments}
et pourquoi pas |?{true,false}

bug introduit par [5337] qui donne acces aux champs des jointures explicites dans les squelettes mais ne le donnait plus pour celles declarees par PHP (neofutur)

permettre l'acces aux champs d'une table de jointure explicite; ca reste lacunaire mais c'est tout de meme plus homogene que de faire la jointure et n'y avoir acces qu'en partie

nettoyage et unification de charger_generer_url(), et retour de la compatibilite ascendante sur inc-urls.php3 qu'un malheureux _EXTENSIONS_PHP (au lieu de _EXTENSION_PHP) avait flinguée

il faut passer safehtml après propre(), mais avant les filtres utilisateurs

(c) 2001-2006

Introduction d'un modele de securite a deux niveaux :
- [(#TEXTE)] : on applique propre() et interdire_script()
- [(#TEXTE*)] : on n'applique plus propre(), mais toujours interdire_script()
- [(#TEXTE**)] : on n'applique plus rien ; question seccurite tout devient possible, au webmestre de filtrer comme il se doit pour eviter toute injection de php, javascript etc.

Par ailleurs les appels a safehtml() se rationalisent un peu (mais pas encore definitif, je pense).

clarification sur l'emploi du filtre interdire_scripts (changement de nomenclature dans le code, a fonctionnalite equivalente)
attention ca casse un peu l'API pour ceux qui ont des balises persos.

laisser une fonction de definition de balise "passer la main" si elle le souhaite (Pif) + exemple avec la balise #POINTS dans le cas d'une boucle {recherche}

exemple : [(#BALISE|MaClasse::maMethode)]

mauvais retour de boucles récursives (nic;o & paolo); code gourmand, mort ou mal structuré dans le calcul des champs SQL par le compilateur

transformation des repetitions de critere d'égalité sur un meme champ en un IN + HAVING count(*) = cardinal (Patrick Guermonprez); début du nouveau decompilateur

j'ai échappé de peu au savon avec le champ POINTS: la fonction rindex-pile n'était pas en phase avec la nouvelle API

encore un petit bug sur les espaces dans les arguments imbriqués,  et début d'extension des arguments de Inclure

deport (enfin) de l'analyse des balises de langues dès le phrasé, avec introduction de 2 nouveaux noeuds dans l'arbre de syntaxe abstraite. Permet d'avoir des champs # comme argument de leur filtre, et elimine la recherche de <multi> a chaque appel des filtres et typo et ses traitements redondants

quel bazar dans ces filtres: FORMULAIRE_RECHERCHE et URL_LOGOUT avec un paramètre déclenchaient un "parse error", LOGO_DOCUMENT ignorait le filtre "fichier" et le reste de ces attributs apparaissait comme du texte, et je dois en oublier. Bon, petite avancée vers les filtres imbriqués en séparant dès le phrasé la fonction de filtre de ses arguments

accepter  [(#ENV{bar,#ENV{foo}})] ou     [(#ID_ARTICLE|filtre{bar,#ENV{foo}})] (mais pas plus, du moins pour l'instant)

- {'#ID_ARTICLE'} donne la chaine '#ID_ARTICLE', tandis que {#ID_ARTICLE} donne la valeur compilée de la balise #ID_ARTICLE
- debug de l'erreur commitée au précédent envoi : {' '} qui donnait la même chose que {''} et plantait le login (Paolo, Peggy)

({"'toto'"} ne marchait pas)

petit bug de param_balise qui allait chercher {19} dans l'expression [(#LOGO_DOCUMENT||reduire_image{19})]