Tâche #605 sur la messagerie, mais il reste encore qq accès en écriture à la BD pour clore cette tâche. Et qq variables indéfinies en moins.

desactivation de l'envoi par mail a webmestre des tentatives des spammeurs ; maintenant qu'on sait que ce piege fonctionne, on peut mourir silencieusement, c'est bien

Variable indéfinie dans l'URL vers le forum interne d'un site, on ne pouvait jamis poster. De plus c'était plein de code mort (variable $new jamais passée par http et meme pas déclarée globale), la TODO en début de fichier ayant été faite sans mise à jour du commentaire et de la suite. Mais c'est un peu inquiétant de ne pas retrouver trace dans le script action/editer_site de la globale de configuration ''moderation_sites'' ni du message d'erreur ''avis_site_introuvable''.

Correction de #679: non sélection ajax de la rubrique dans l'édition d'un site. Il a fallu sortir l'artillerie lourde: validation xml de sites_edit (qui n'avait pas été faite) et error_reporting_all sur tous les fichiers inclus pour arriver à la variable indéfinie coupable. On va finir par le mettre d'office le error_reporting_all.

une mechante affectation en reference faisait planter php4 et apache (retour de bug a faire a l'auteur ?)

lorsqu'un critere dynamique est present ( {par #ENV{tri}} ), prevoir qu'on peut vouloir faire tri=hasard, la syntaxe {par hasard} pouvant faire croire que c'est techniquement la meme chose que {par id_article} ...

se baser d'abord sur la table spip_documents pour attraper le vrai type si il est connu (plus fiable que l'extension)

ne pas accepter n'importe quelle extension (fil)

le filtre |compacte : unifier compacte{css} et compacte{js} sur le mode fichier->fichier et contenu->contenu ; reste a trouver moins moche que spip_get_file_contents comme nom de filtre :)

on utilise javascriptcompressor (www.devpro.it) pour limiter la taille de la spip.php?page=jquery.js ; a noter contrairement a 
compacte_css ici c'est un flux qui est traite, pas un fichier (qui a une meilleure idee?)

Tache #685, suite de [8368]: lors d'une fusion d'une sauvegarde, on importe les logos on/off des rubriques quand elles en ont. Incomplet car ça suppose que les logos sont à l'emplacement standard (IMG/), ce qui n'est pas forcément le cas (surtout en mutualisé) il faudra donc rajouter cette information dans un nouveau type de sauvegarde (idéal) ou le demander dans le formulaire (pas terrible). Par ailleurs on peut se demander si on ne devrait pas proposer cette option lors d'une restauration non fusionnante: s'il s'agit d'avoir un miroir d'un site qui continue d'exister, et non une restauration SQL sur une site ayant toujours son répertoire de logos etc, ça serait très utile. 

A examiner aussi: importer tous les logos. Mais le nombre de requetes http peut
faire peur (6 essais pour chaque entité: on/off et gif/jpg/png).