gros menage dans l'envoi de documents pour utiliser spip_action plus efficacement. il y a encore un peu de boulot a venir

detruire le cache des meta des le debut de l'install, sinon ca aiguille sur l'adresse de la version reinstallee qui n'est pas necessairement la meme. Et ne pas oublier de charger inc_meta quand il y a aussi une MAJ de la base

Dans les formulaires : pourquoi faire compliqué quand on peut faire simple : entites_html est le filtre par défaut de [(#ENV{truc})] !

[5416] avait promis qu'il y avait plus simple pour le changement de couleur. Exact, mais en plus c'est sans XSS a tous les etages (la honte).

unification des tables d'indexation (spip_index), ce qui permet de rendre
le moteur de recherche plus générique, et donc éventuellement de l'étendre
à d'autres tables, ou de changer les poids, ou de faire des calculs portant sur
l'ensemble des mots indexés, voire des boucles sur l'ensemble des objets indexés
... (cf. http://zone.spip.org/trac/spip-zone/changeset/1724 )

eclatement de inc_auteur_infos pour qu'il soit exclusivement inclus par include_fonction, tandis que le nouveau venu est exclusivement inclus explicitement

le chgt de couleur faisait n'importe quoi, suite au passage par la case inc.php3 de spip_style. Ca remarche comme avant, bien qu'il y ait peut-etre plus imple

eclatement de inc_sites_tous pour qu'il soit exclusivement inclus par include_fonction, tandis que le nouveau venu est exclusivement inclus explicitement

memoriser dans included_files le Path et non le Basename, pour pouvoir charger la fonction F_dist ET sa surcharge F si besoin

replacement de ecrire/iframe_action.php par ./sip_action?action=instituer, pour changer le statut de qqch de manire plus rapide (pas de chargement de preferences) et plus sure (controle l'action, plutot que le demandeur qui n'etait d'ailleurs pas toujours bien controle)

laisser passer la feuille de style a l'install, c'est-a-dire sans exiger le cookie. Par ailleurs, retirer de inc_upgrade ce qui n'est pas necessaire au script upgrade

c'est l'ultime tentative pour ne pas recréer l'objet à chaque appel (souci de perfs)

joli XSS a double detente. A noter qu'un appel a sites_edit communiquait un parametre 'redirect' que celui-ci ignorait

Suite du depot precedent: le probleme semble ne se poser que pour les url referencant un repertoire mais sans '/' avant le '?'. On le rajoute et on a de nouveau des URL absolues pour la plupart des envois en post

Un formulaire avec un champ action en adresse absolue AVEC parametres
(donc de forme "http://PATH?arg1=val1....") et un champ method de valeur POST est transmis d'autorite en GET par les navigateurs, alors que si le champ action est en adresse relative (donc de forme "PATH?arg1=val1...") la transmission
a bien lieu en POST !

En consequence, SPIP n'utilise finalement les URL absolues que pour les methodes GET, jamais pour les POST. Ce depot enterine ce choix, a l'aide de la fonction genere_url_ecrire qui admet un nouvel argument optionnel indiquant si l'on veut une URL relative (par defaut) ou absolue. La fonction generer_url_post_ecrire utilise donc systematiquement la deuxieme forme. Les appels a ces deux 
fonction ont ete reecrits pour verifier les cas d'utilisation.

bug avec safehtml() : une fois planté par un "<style>" non fermé, il efface tout. Il faut le reset() plus fortement (à programmer en mode OO ?)

Passage en Post de tous les formulaires GET, car ceux-ci ne seront plus compatibles avec l'extensibilite de SPIP. Celle-ci devra utiliser du coup _REQUEST pour recuperer le nom de l'action a faire, on l'instaure tout de suite. Version standard toujours operationnelle, mais l'extensibilite ne s'obtient pas encore apres execution de spip_migre

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}