Les squelettes des balises dynamiques peuvent à présent envoyer des en-tetes HTTP (balise CACHE), le compilateur donne les moyens de les récupérer pour les placer au début de l'envoi final vers le client.

Fusion de la sérire de fonctions balise_formulaire_traitement et de la série de globale formulaire_traitement_collecte à l'intérieur de la série de fonctions balise_formulaire. Les couples de fonctions _stat et _dyn restent en place.

Il y avait beaucoup de variables et d'arguments inutiles dans menu_lang et menu_lang_ecrire, dont l'un avait le gros défaut de faire boucler la nouvelle API
(la balise menu_lang a besoin de la valeur de menu_lang qui n'est pas forcement
une variable d'URL mais, sait-on jamais, une balise. A eviter). Il y a peut-etre une simplification excessive, pourtant le multi-linguisme semble toujours marcher.

is_readable est plus complet que file_exists quand on veut lire (inc_utils); simplification (code mort) dans inc_presentation

attention le Hack pour assurer l'aide en ligne sur SPIP.NET ne disparait pas totalement (il implique de passer les urls de l'aide en ligne de façon relative)

Depuis que les URL sont toujours produites en absolue, pas la peine d'en rajouter une couche dans les notifications (Cedric, #148)

Un bug comme celui-la [6006] fait partie des rares cas où meme un partisan de l'eXtreme Programming comme moi exige un commentaire. En prime, un peu de doc sur une fonction contre-intuitive

Suppression du rawurldecode avant le http303 dans le cas d'une 'action' dans l'espace public avec parametre 'redirect': ca decodait une fois de trop et c'est ça qui faisait planter en cas de double redirection cf [5999]. A noter que certains scripts de l'espace privé on aussi un champ 'action', ce n'est pas très heureux.

 (Cedric)

intégration du patch #144 sur inc_flock, qui permet de limiter le nombre de fichiers lus par preg_files, et d'utiliser ecrire_fichier sans ftruncate (Cedric)

Champagne ! Et pas seulement parce que extension_squelette disparait  car inutile avec la nouvelle API de trouver_squelette

Mauvais double retour sur valider+répondre, a cause du squelette qui trancodait les entites html. Mais finalement le rawurldecode avant le redirect est-il bien necessaire?

Suite de [5996]: il y avait des ''urlencode'' dans les squelettes. Et un peu de ménage dans les boutons de forums.

Utilisation exclusive de ''rawurlencode'' et ''rawurldecode'', remplaçant ''urlencode'' et ''urldecode'' pour unifier les traitements (on prend celle qui suit un RFC, le 1738). 
Transformation obtenue par:
for i in $(grep -l url..code *p */*p */*/*p);
do 
echo "=====$i";
sed 's/\(url..code[^a-z]\)/raw\1/;s/rawraw/raw/' $i > x; 
mv  x $i
done  

La visualisation des mots-clé dans les forums vu de l'espace privé, ca devait pas passionné les foules. Et le nombre d'invariants dans cette itération de recursion non plus.

nouvelle API de public_trouver_squelette, explicitant langage but et langage cible et fichier dans son resultat

nouvelle API de public_trouver_squelette, explicitant langage but et langage cible dans son resultat

Rentrer la possibilité de changer la recherche des  squelettes dans la mécanique générale de la surcharge.

Eviter les - dans les noms de fichiers, afin de pouvoir identifier nom de fonctions et nom de fichier

Rentrer la possibilité de changer la syntaxe des squelettes dans la mécanique générale de la surcharge. Permet entre autres d'inclure des squelettes qui n'ont pas nécessairement la meme syntaxe que l'incluant

Eviter les - dans les noms de fichiers, afin de pouvoir identifier nom de fonctions et nom de fichier

Oubli de traiter le cas des jointures hors criteres dans la nouvelle API de celles-ci [5981]. Pas encore totalement unifié cependant