les revisions du contenu de spip_articles passent dans l'API commune inc/modifier ; la gestion des revisions est presque un pugin desormais

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

mettre les boutons au bon endroit meme s'il y a des < /HTML > dans la page (un forum pourri par exemple) (togg, #671)

allow multiple async uploads (upload more images not waiting for the complete upload of the former one)

amelioration des possibilites de surcharge de autoriser(), sans obliger a passer par charger_fonction()

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.

amelioration de l'API pour editer un article, et des notifications (en effet comme la notification a besoin de calculer l'url et d'avoir le bon contenu texte, on doit la faire APRES sauvegarde des donnees)

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

Suite [7834], on retrouve a nouveau la ligne fautive dans le squelette à partir du résultat. En revanche les valeurs transmises au débusquer dans le cas d'une modèle sont toujours à revoir.

Le validateur xml intégré à Spip et appelable depuis le débusqueur souffrait de quelques incohérences (depuis l'introduction du plugin "affichage_final" peut-etre). Il est à nouveau accessible, en mettant '$xhtml = "sax";' dans mes_options. La déduction de la ligne fautive dans le squelette à partir de la ligne fautive dans le résultat ne remarche en revanche pas encore, mais le problème a l'air plus général car les arguments de debug_sequence déclenche un Warning sur le modele "pagination". Tout ça est neutralisé par un @ ligne 450 de compiler.php, et un test préventif ligne 235 de debug.php mais il faudra y revenir.