a verifier dans IE7 qui gere mal les <button>

Déplacement des fichiers de breves dans le plugin (http://zone.spip.org/trac/spip-zone/changeset/41282).

exec/iconifier ne sert plus

Déplacements de fichiers dans le plugin sites  (http://zone.spip.org/trac/spip-zone/changeset/41105)

#FORMULAIRE_CONFIGURER_ARTICLES regroupe configuration/articles configuration/futurs et configuration/redirection

tentative d'amenagement des pages de configuration avec la reprise du menu deroulant en colonne gauche
ce qui devrait permettre d'eviter les onglets superieurs
il y a de l'alignement a faire, c'est encore brouillon

Les deux configuration/locuteur et configuration/referenceur sont regroupees en un seul #FORMULAIRE_CONFIGURER_MULTILINGUISME, ce qui devrait resoudre #1652

supprimer les occurences de inc_discuter() qui est remplace par une insertion dans le pipeline afficher_fiche_objet par l'extension forum
Il reste le cas particulier des messages, dont les forum ont vocation a disparaitre et devront etre remplaces par des messages de reponses

evacuer la version PHP de la page de configuration des langues, des la barre onglet correspondante, et branchement de la version squelette (et definition des onglets dans core.xml)

hierarchie : utiliser un squelette unique pour afficher le chemin avec un bouton changer qui charge en ajax le selecteur de rubrique (#1634)
Doit on encore garder le selecteur de rubrique dans le formulaire d'edition ?

rangement : les exec qui utilisent une authent FTP par inc/admin et declenchent une action scriptee dans base/xxx s'appellent de preference (et en coherence) exec/base_xxx. A defaut si exec/base_xxx n'existe pas, inc/admin renvoie sur exec/xxx comme avant pour assurer la compatibilite.

On renomme 
- admin_repair en base/repair et exec/base_repair
- delete_all en base/delete_all et exec/base_delete_all
pour s'y retrouver

Suite au début de migration des mots en plugin (http://zone.spip.org/trac/spip-zone/changeset/41050), on se déleste des fichiers et parties intégrées (telles quelles)

Il reste le cas du formulaire de declaration d'une autre base, issu de l'installation. Mais il faudra traiter son cas specifiquement, on le laisse donc comme ca pour le moment.

Ne faudrait-il-pas ranger ces  modules dans un dossier dedie ?

page pour vider le cache en squelette + integration de la fonction 'desactiver temporairement le cache'/'reactiver le cache' 
Dans tous les cas, le cache se reactive automatiquement au bout de 24h pour eviter tout oubli.

initialiser a chaque hit la globale $spip_pipelines, qui grossit au fil du temps, a peu d'interet puisque elle n'est vraiment utile que dans inc/plugin lors de la construction des pipelines compiles.
On remplace donc cette declaration globale par la declaration xml dans core.xml. Celu-ci migre depuis prive/ vers ecrire/ puisque c'est le repertoire source d'ou partent les inclusions.
Toutes les fonctions appelees par des pipelines qui etaient dispersees sont regroupees dans deux fichiers inc/pipelines.php et inc/pipelines_ecrire.php

La seule autre utilisation de spip_pipelines concernait la compilation des balises dynamiques lorsqu'un pipeline y etait passe en contexte (CVT). On remplace le test d'existence a cet endroit par un flag dans la fonction pipeline() qui demande d'ignorer silencieucement l'absence du dit pipeline en cas de non existence.

Il reste le cas des declarations || sur le pipeline styliser pour forcer l'appel en queue de pipeline, qui n'est pas couvert par la syntaxe actuelle des plugin.xml. Un point a ajouter dans la DTD en cours de realisation.

Le seul cas que l'on ne couvre plus est la possibilite pour les plugins de surcharger la globale spip_pipeline pour enlever/modifier un appel du core ou d'un autre plugin. Il faudra peut etre ajouter pour cela un pipeline sur la construction des pipelines. On y reviendra si les cas sont vraiment indispensables.