Complément à [10378]: on peut maintenant sauvegarder une rubrique qui n'est pas un secteur, et on sauve en plus seulement de quoi permettre sa fusion au me niveau si besoin.  Et on sauve encore moins d'objets sans rapport avec la rubrique concernée.

pas de lien sur le statut courant de l'element (et pour les sites le bloc statut etait buggue), #1061

par je ne sais quel miracle on dirait que interface_drag_drop dans articles_tous continue a fonctionner ; mais je n'ai pas mis a jour cette partie
suppression de l'interface onglets (resoud par le vide #1037 #1045)

Auparavant, ces sauvegardes étaient construites lorsqu'un administrateur restreint déclenchait le script '''export_all''', et la sauvegarde contenait alors le contenu de toutes les rubriques qu'il administrait. Construire une sauvegarde pour une rubrique précise imposait donc de créer un pseudo-administrateur pour cette rubrique, de se connecter sous son identité et d'exécuter ce script.

A présent, ce script permet de spécifier un numéro de rubrique à sauvegarder,indépendamment des droits du demandeur. Ce procédé est plus pratique, et figure donc sur la même page que l'option de fusion pour l'opération inverse de restauration, à laquelle elle est naturellement rattachée. De plus, les dépendances sont calculées plus finement, ce qui évite de placer dans cette sauvegarde l'intégralité des tables annexes (tables des mots etc).

Pour le moment, cette sauvegarde ne fonctionne que pour une rubrique de secteur. Cette restriction devrait être levée bientôt.

A noter que cette nouvelle implémentation permet à plusieurs administrateurs de lancer chacun une sauvegarde en même temps. Même en cas de suspension des scripts, chacun d'eux reprendra là où il en était lorsque l'administrateur concerné le redéclenchera (en revanche un même administrateur ne peut toujours pas  lancer plusieurs sauvegardes simultanément, mais ce n'est pas gênant).

supprimer spip_var_export, du coup c'est php 4.2.0 minimum (mais cette fonction est dans spip.log et personne n'a rale

Allègement d'écriture: sql_fetsel n'a pas forcément besoin que ses arguments soient des tableaux. Et elle n'a pas à figurer dans le tableau d'accès à une connexion.

Reconception du script '''delete_all''. A présent ce script présente la liste des tables dans la base ayant le préfixe donné à l'installation. Cette liste permet d'examiner les tables qui seront effectivement détruites, et permet également de décocher certaines d'entre elles afin de les conserver. Enfin, elle supprime les faux messages d'erreurs quant aux tables ne faisant plus de partie de SPIP, ce script n'ayant pas toujours suivi ces évolutions.

'''ATTENTION''': toutes les tables avec le préfixe seront détruites, même celles non déclarées par la distribution standard de SPIP. C'est souvent ce que l'on veut (sinon, on aurait pas utilisé ce préfixe pour ces tables supplémentaires) mais c'est un changement par rapport à avant. Les boutons radio sont justement là pour permettre le comportement antérieur, moyennant une lecture attentive.

Cette fonctionnalité repose sur un nouvelle fonction d'abstraction, qui s'ajoute
à celle définies dans [10154][10131][10146] et [10113]:

{{{
'showbase' => fonction d'abstraction de la liste des tables en base
}}}

Par défaut, elle retourne les tables avec le préfixe standard, mais avec un argument supplémentaire elle les retourne toutes (attention en cas de mutualisation par changement de préfixe).

suite de [10330] pour la simplification de prepare_recherche() ; la modif associee suit sur le plugin indexation

La demande de publication par un simple rédacteur avait complètement disparu (Jack). Attention, inc_instituer_article a dû changer de signature, et demande_publication passe aux oubliettes (de toutes façons son graphisme est hors champ à présent).

Enfin compris le problème [10285] / [10293] : ce sont les fonctions MySQL sur date (NOW, DATE_SUB etc) qu'il ne faut pas citer si on ne veut pas se retrouver avec une date nulle.

J'ai dû en nettoyer, du code, avant de comprendre que la disparition du descriptif des rubriques dans certains n'était pas dû à naviguer mais à afficher_contenu_objet. Enfin, il y avait tellement de code mort ou redondant que ça ne fait pas de mal. Et une petite remise dans le circuit de l'ancienne interface: une page de rubrique dans lequel les boutons pour publier une brève et un article ne sont pas bien en évidence, vraiment ça ne va pas. Le reste ne devrait pas avoir bougé.

reste du code mort à la fin de spip_mysql_insert ???