Début de la tâche #685. Spip propose à présent de fusionner la base courante avec les tables principales d'une sauvegarde, moins la tables des types de documents (qui est commune à tous les Spip car en lecture seule) et la table des auteurs (pour éviter les conflits sur les noms de login). Pour une base contenant déjà N rubriques, les secteurs (i.e. les rubriques de premier niveau) de la sauvegarde recevront un numéro supérieur à N, ainsi que leur sous-rubriques dont les champs id_parent et id_secteur seront eux aussi modifiés pour conserver l'arborescence. Idem pour les champs id_rubrique et id_secteur des articles, brèves, forums, et syndications de la sauvegarde. De meme, le champ id_groupe de la table des mots de la sauvegarde tiendra compte de la renumérotation des groupes de mots introduits lors de la fusion.

Ce qui n'est pas (encore) fait: 
 * l'importation des documents joints, et a fortiori la renumérotation des pseudo balises emb,doc,img dans les champs SQL;
 * l'importatio des logos;
 * la fusion des 2 tables d'auteurs, si nom et/ou login identiques
 * la fusion des 2x2 tables de mots et groupes de mots si meme titre
 * l'importation des tables auxiliaires (mots/auteurs d'un article...)

En l'état actuel des choses, cette option de restauration est surtout intéressante pour qui possède une collection d'articles sur un site Spip (par exemple en local) et veut importer d'un bloc cette collection sur un autre. En jouant sur le statut d'administrateur restreint (on peut en créer une juste pour l'occasion), il est possible de n'importer qu'une partie d'une site d'origine, puisqu'une sauvegarde effectuée par un administrateur restreint est réduite aux rubriques qu'il administre.

Egalement dans ce dépot: 
 * la fonction _q() n'entoure plus de guillemets un nombre
 * en cas de sauvegarde avortée, on arrive à garder la connexion au site.

Suite de [7921]: l'appel de la fonction tenant compte des options de configuration (et sa définition standard) migre dans le fichier construisant le formulaire d'édition d'article, afin d'etre disponible à partir d'un squelette.

Pour donner un exemple, voici un bout de squelette S qui fait apparaitre le
formulaire, avec des options de config perso config_S, et retour vers lui-meme:

[(#ID_ARTICLE|inc_editer_article_dist{#ID_RUBRIQUE,0,'./?page=S', config_S})]

L'ajout de champs supplémentaires dans le formulaire reste à améliorer: il
faut rajouter un filtre éliminant les balises form-/form englobantes puis 
les remettre.

Mettre le raccourci en colonne gauche plutot qu'à la fin de la page, c'est plus pratique. Et conformité XHTML.

Concentrer la configuration du formulaire d'édition dans une seule fonction, ca facilite la surcharge.

Nouvelle facilité d'edition d'article à partir de l'espace privé: la fonction inc_editer_article est découpée en autant de fontions que de champs à éditer dans la table, chacune de ces fontions pouvant etre utilisée dans une squelette construisant un formulaire légèrement différent de la fonction sus-nommée.

Aussi dans ce dépot: passage en compatibilité XHTML de toutes les composantes de la page articles_edit, sauf 2 balises en majuscules écrites en dur dans les fichiers de langue, il faudra faire une passe là-dessus.

Le formulaire d'édition d'un article est à présent un filtre appelable d'un squelette, sous le nom de inc_editer_article_dist (et sous réserve qu'il a été préalablement chargé dans mes_fonctions et assimilés). Il a été purgé de toutes ses variables globales (car elles n'ont de sens que dans l'espace privé) qui sont passées dans un tableau qu'on peut remplir différemment à partir de l'espace public. Mais il faut surtout donner une url de retour pour le script qui enregistre les données. Evidemment, il faut avoir les droits d'accès en écriture sur l'article pour que la validation ne soit pas refusée.

L'intention première de cette nouvelle fonctionnalité est de permettre l'inscription libre de rédacteur dans un site géré par LDAP: il n'est en effet pas souvent possible ni souhaitable de laisser en libre écriture un tel annuaire, aussi la technique des formulaires accessibles de l'espace public est ici indispensable. Mais on peut utiliser cette fonctionnalité pour d'autres raisons, en particulier des squelettes assez proches d'un Wiki, 

Comme pour l'arrivée du filtre de calendrier, la chose est actuellement encore assee brute, l'ergonomie et la présentation sont à améliorer.

show the button to manage empty messages, even when all of them are deleted, because they could be reactivated in a later moment

Définition de _SPIP_AJAX dans spip_init pour tester une fois pour toutes la présence du cookie spip_accepte_ajax: vu l'importance grandissante d'Ajax dans Spip, il était temps de mutualiser. Aussi dans ce dépot: petite correction dans tranches_requetes sur les articles, la présence d'une petition n'y était signalée que pour la première tranche.

Symétrique de [7876]: ne pas utiliser une variable X s'il existe un charger_fonction(X). Et corrections de qq oublis.

Rationnalisation du code: charger_fonction(X) est affectée à la variable $X. Prélude à une affectation au niveau global.

Tâche #328 et rationnalisation du cod: les fonctions de inc/utils produisant du code HTML et des entetes HTTP sont évacuées ailleurs. En particulier, la plupart des redirections étant à present dans les scripts de action/, redirige_par_entete passe dans inc/headers. Plus un peu de partage de code ici ou là.

Possibilité d'appliquer l'indenteur XML sur les scripts de l'espace privé. Quant cette option est en action et qu'on est admin, une page non conforme XML prise en charge par débusqueur qui affiche le code HTML en numérotant les lignes, et emet le message d'erreur avec un lien vers la ligne fautive.

Cette option est déclenchée par la globale xml_indent, en attendant de tirer
au clair l'usage de la globale xhtml dans la fonction _T.

Conformité XHTML du script accueil. Reste un '<b><div>..' produit par tranches_bandeau qui induit de réécrire tous ses appels.

Le triple bouton reglant l'affichage textuel et/ou non des icones du bandeau principal ne marchait plus. L'icone d'info-perso était encore là pour les admins restreints. Solution au pb de [7788] pour etre enfin conforme XHTML. QQ globales indéfinies qui faussaient parfois l'affichage.

La détermination du répertoire des sauvegardes pour admin restreints étaient encore percée, on unifie un peu mieux tout le code autour. Et pourquoi soudainement un fichier bourré de ^M ?

Tâche #587 sur inc/boutons et inc/rubriques, lequel est expurgé de ses productions HTML afin d'être chargé plus rapidement par les scripts d'action. Et pas de include et charger_url superflus évacués.

afficher_contenu_rubrique pour la racine dans le cas ou des articles y seraient (consecutif a un import par exemple)

suppression du répertoire de dump à l'installation. Il est créé à la volée, comme CACHE/, sessions/ et les autres.

Bientôt la même chose pour upload/ et ses sous-répertoires.