#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.

la description des vieilles bases n'a plus rien a faire dans le noyau suite a la sortie en plugin de la fonction de dump XML

les filtres pour les pages de l'espace prive sont deplaces dans inc/filtres_ecrire qui est inclu au calcul, si on est bien dans l'espace prive

Extraction de la sauvegarde/restauration de SPIP dans l'extension dump : Export/Import de la base en XML

Remise en ordre de l'installation : reprendre leprocessus de la branche 2.1 qui installe les extensions

SPIP est un plugin presque comme les autres : navigation.xml devient core.xml, qui pourra aussi contenir des declarations de pipeline.
On supprime le traitement derogatoire de ce fichier pour la construction du bandeau d'icones, en le compilant avec les autres plugin.xml
On pourrait aussi y definir la version de SPIP, mais pour l'instant on garde l'info dans inc_version, et on la reinjecte juste apres lecture de core.xml pour eviter de devoir l'ecrire dans deux fichiers.

les exec et action configurer qui servaient a gerer l'ajax des scripts de configuration/ sont renommes en exec et action configuration, ce qui est plus coherent, et laisse la place pour la page
exec=configurer&cfg=xxx qui sert a presenter le #FORMULAIRE_CONFIGURER_XXX (naturellement ajax)

On introduit donc une rupture de compatibilite avec les configuration/ eventuellement presentes dans des plugins, qui utiliseraient ajax_action_post('configurer'...). 
Sur la zone, cela ne concerne que le chantier du plugin breves, non utilisable actuellement, et la configuration du plugin indexation.

renommer la page de configuration des contenu en exec=configurer_contenu, ce qui libere exec=configuration

ces raccourcis de langue sont devenus tres incomplet et cette page peu usitee est avantageusement remplacee par certains plugins, on l'oublie donc.

- Tous les prive/squelettes/contenu/page-configurer_xxx
sont recenses, et les pages qui ne sont pas deja dans la navigation sont ajoutees au menu configuration avec :
titre = <:configurer:configurer_xxx_titre:>
icone = images/configurer_xxx-16.png
autorisation : autoriser(bouton,configurer_xxx)

- Tous les formulaires/configurer_xxx
sont recenses, et ceux qui ne sont pas deja dans un page-configurer_xxx ou linkes directement via exec=configurer&cfg=... sont ajoutes au menu configuration avec :
titre = <:configurer:configurer_xxx_titre:>
icone = images/configurer_xxx-16.png
autorisation : autoriser(bouton,configurer_xxx)

le squelette prive/squelettes/contenu/page-configurer.html permet de generer un exec automatique pour un formulaires/configurer_xxx, en l'appelant via
ecrire/?exec=configurer&cfg=xxx
(on garde l'argument cfg en clin d'oeil)

La fonctionnalite introduit de fait pleins d'entrees dans le menu configuration/ qui vont disparaitres au fur et a mesure de la migration des pages de configuration de l'espace prive en squelettes
Pour eleminer un bouton disgracieux du menu configuration, il suffit de definir son autorisation a false, ce qui interdira aussi l'appel du formulaire correspondant via exec=configurer

Il faudra voir a l'usage si la fonctionnalite n'est pas trop genante en generant trop systematiquement une entree dans le menu configuration.

gerer l'acces interdit par un appel direct a un exec php 403 pour eviter une redirection moche (fil)
cela implique de ne plus faire une verification de doublon dans f_jQuery, mais celle-ci bloquait deja pour le calcul asynchrone des squelettes par cache_cool