1. Les pièces jointes à un article ou une rubrique sont importées sous forme de documents distants. Il faut donc donner l'URL du site d'où provient la sauvegarde dans le menu demandant la fusion.

2. Identification de chaque article de la sauvegarde avec un article de la base installée, s'ils ont meme titre et si leurs rubriques mères ont été identifées.

A noter qu'on pourrait comparer les deux dates de mise à jour pour décider de quand meme écrire les champs de la sauvegarde si sa version de l'article est plus récénte. Allant plus loin, on pourrait utiliser la table des versions pour décider quel est plus récent de chaque champ, et offrir ainsi une véritable ''synchronisation'' entre 2 sites fonctionnant en miroir. A approfondir.

1. accéler la recherche quand on les utilise 
2. prévenir le compilateur que les couples de ces tables sont uniques. 

et à présent:
3. empecher automatiquement les doublons lors d'une fusion entre une sauvegarde et la base courante.

(Redémarrage apres perte des 3 derniers dépots). Un include mal placé pour le menu ''Dans la même rubrique'' pour les brèves.

Pour ce millésime, un sacré bug de résolu: 2 raccourcis (->) rapprochés dans une sauvegarde pouvait rendre celle-ci illisble. 

Ce nettoyage à la petite cuillère s'accompage d'une accélération de la relecture des sauvegardes, Regexp et allocation ayant été évacué au maximum du petit
analyseur syntaxique. Mais ça vaudrait le coup de regarder si passer carrément
à SAX ne sera pas encore plus performant.

Tâche #685, suite de [7952]. Les raccourcis ->rubNN, ->breveNNN >NNN pour articles etc sont eux aussi translatés lors d'une fusion. Petite réécriture des fonctions sur raccourcis pour pouvoir partager le code.

Ce dépot corrige aussi un bug dans l'identification des rubriques, visible seulement pour plusieurs occurrences d'une rubrique, apparaissant dans un certain ordre. Du coup le tableau PHP recopiant la table SQL transitoire est rendu global, car trop souvent passé par référence. Il n'est pas impossible finalement que des jointures sur cette table et les autres ne soit pas plus efficace finalement.

Reste à faire pour achever cette nouvelle fonctionnalité:

- fusion des auteurs et importations des tables auxiliaires sur les auteurs
- référencement des pièces jointes et des logos, à partir de l'URL de la source.
 

evaluating scripts returned by an ajax request with <!-- and //--> fails in IE

Tâche #685, suite de [7952]. Lors d'une fusion, chaque rubrique d'une sauvegardes est identifiée à un rubrique présente sur le site si elle a meme titre et et qu'elles sont toutes les deux des secteurs (i.e. de id_parent nul) ou que leur id_parent aient été eux-memes identifiés l'un à l'autre.

Tâche #685, suite de [7991]: la fusion est à présent blindée contre une reprise pour cause de TimeOut ou autre. Et la 2e passe est provoquée par un 302, c'est plus clair.

Tâche #685, suite de [7971]: certains cas tordus de fusion ne marchait pas bien, et il y avait matière à optimisation. La fusion avec une sauvegarde aux anciens est à retester; mieux vaut mettre à jour la base visée avant insertion en attendant.

fix bug http://jquery.com/dev/bugs/bug/446/

Erreur d'arrondi dans le numero de la base, qui empechait la mise a jour. Ne plus appeler maj_version qu'avec une chaine dorénavant (complet hasard que ce bug ne soit pas remonté plus tot).

Un peu radical certes, mais vu les différences d'interprêtation stylistique entre les différents navigateurs, mieux vaut encore laisser les styles des formulaires par défaut.

Au moins seront-ils correctement pris en charge par chaque navigateur.
De plus, ça évite d'induire en erreur le débutant en css.

mots_edit ne redirige plus n'importe ou, et exploite l'API modifier ; corrige un bug dans cette API qui ne demandait pas de reindexation

Il n'y a pas de raison que les input submit soient dans une div quand tous les autres input sont dans des p.

Petit confort: les "No nnn" des articles et des breves dans les tranches et le cartouche Dans_la_meme_rubrique sont des liens vers le formulaire d'édition.

quand on joue a un champ pour un autre, il faut retourner le nom d'origine car sinon le critere conditionnel ne peut etre appliqué ...

permettre aux plugins de gerer eux memes des jointures ou des criteres tordus pas automatisables par extension de la syntaxe de :
$GLOBALS['exceptions_des_tables']['forms_donnees']['id_mot']=array('spip_forms_donnees_champs', 'valeur', 'forms_index_exception');
-> un troisieme argument optionnel comme nom de fonction qui fait le boulot de index_exception()
$GLOBALS['exceptions_des_jointures']['forms_donnees']['id_mot'] = array('spip_forms_donnees_champs', 'valeur', 'forms_calculer_critere_externe');
-> une dimension intermediaire pour specifier une jointure sur une table uniquement, et un troisieme argument optionnel comme nom de fonction qui fait le boulot a la place de calculer_critere_externe_init()

Tâche #685, suite de [7952]. Lors de l'insertion d'une sauvegarde, encoder celle-ci dans le charset courant du site, sinon c'est le bazar. Marche aussi quand on insère une sauvegarde à l'ancien format (1.2) mais pas à l'anté-diluvien (non numéroté).

Tâche #685, suite de [7952]. Les groupes de mots présents dans la sauvegarde à fusionner sont identifiés à ceux présents dans la base si leur Titre sont égaux. Idem pour les mots, si leur Titre sont égaux ET que leur groupe a été lui aussi identifié à un groupe présent (ce qui implique 2 passes sur le fichier de sauvegarde, plus entre les 2 une collecte des groupes identifiés). Du coup, la fusion ne porte plus seulement sur les tables principales, mais aussi sur les 6 tables de jointures par les mots.