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)

et en ignorant les consignes de langue du public dans la fonction correspondante

bouton "Deplacer" et non "Changer"
En float right pour ne pas faire croire qu'il est associe a l'objet, mais au chemin en general
placeholder pour l'animation ajax

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 ?

un debut de fil d'ariane universel (ah ben tiens c'est possible avec #INFO_TITRE sur le dernier objet expose !)

le pipeline affiche_hierarchie ne devait pas etre bien utilise puisque id_parent=0 car reaffecte dans le corps de la fonction

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.

le form de connexion etant utilise aussi dans l'espace prive, il faut pouvoir l'injecter sans jquery lorsqu'il est deja present

oups : le pipeline recuperer_fond passe tout le tableau, il faut passer uniquement le texte a afficher_xxx

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

delete_all contenait une fonction pour lister les tables et les afficher en liste a cocher, comme la sauvegarde et la restauration. Mutualisons tout cela dans base/dump du core

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.

les #BOUTON_ACTION sont styles par defaut comme des boutons submit. Pour retrouver une apparence de lien, il faut leur ajouter la classe link en 3eme argument

$fond peut etre un tableau, dans ce cas il n'est pas pertinent d'essayer de brancher les pipeline affiche_xx, et on evite d'y appliquer strncmp 

branchement automatique des pipelines affiche_gauche, affiche_droite, et affiche_milieu pour les exec en squelettes.

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.