Regles : 
- un espace après chaque virgule
- un espace avant et apres chaque '='

Quand une largeur maxi ou hauteur maxi d'image 'est definie, plutot que de generer une erreur, on reduit automatiquement le fichier uploade si l'option 'Générer automatiquement les miniatures des images' a été activée. Du coup il faut verifier la taille (en ko) apres, car si on a reduit l'image elle a des chances d'etre moins lourde aussi.

Quand on insere un document distant, essayer d'en lire les meta-info en en recuperant les premiers 512ko.
Permet de recuperer les dimensions d'une video distante (ca semble marcher sur mp4 et webm, a confirmer sur les autres types de fichier)

Après déplacement du fichier dans IMG/, on regarde si on peut récupérer une taille du fichier, si on ne peut pas, c'est qu'il fait 0 octets et donc corrompu (ou problématique et inutile)

On ajoute cette vérification sur la génération du zip (au cas où)

Vérifier si un fichier existe et n'est pas de taille 0 au début de l'ajout de document, avant la copie du fichier, évite d'avoir de mauvaises surprises avec des fichiers mal uploadés de taille 0.

Permettre à tous les objets autorisant des documents (pas seulement les articles & rubriques) d'insérer des documents (et de les prendre en compte surtout ensuite) au moment de la première création de l'objet.
(Eric Ouvrard - http://thread.gmane.org/gmane.comp.web.spip.user/173775)

detection des extensions un peu laxiste, qui faisait refuser des urls licites avec timestamp fournies par oEmbed pour les vignettes

Le media d'un document (image, video, audio, file) utilise par convenance dans l'interface ne peut dependre en dur de l'extension du fichier :
avec oEmbed, on peut se retrouver a integrer toute sorte de media au format html
Du coup on revoit la structure de la base :
spip_types_documents porte un champ media_defaut (renommage de l'ancien media) utilise comme valeur par defaut du media si non renseigne quand un document est ajoute
spip_documents porte son propre champ media, qui est peuple en fonction de media_defaut, sauf si renseigne lors de l'ajout du document
(ie via fonction de description ou pipeline)
Revision du code partout ou on referencait media, en dispatchant sur l'un ou l'autre selon les cas
upgrade de la base (en deux fois)

http://core.spip.org/issues/2304

utilisation de la fonction objet_test_si_publie() pour publier un document en fonction du statut des objets liés

on renomme de façon cohérente pour tous les objets
xxx_inserer
xxx_modifier
xxx_instituer

Les points d'entrée de l'API sont donc
action_editer_xxx pour le traitement global d'un post
xxx_inserer et xxx_modifier pour les operations elementaires

xxx_instituer n'est pas un point d'entree et ne devrait pas etre appelee en direct : il faut passer par xxx_modifier.

Le fichier inc/modifier contenait de façon centralisee des fonctions
revision_xxx pour les objets historiques de SPIP (essentiellement utilisées par les crayons)
Cette construction centralisée n'est pas facilement extensible. On evacue donc chaque fonction dans le action/edtier_xxx de l'objet concerné, et on propose en remplacement un point d'entrée unique
revision_objet($objet,$id,$c)
qui va dispatcher vers la fonction xxx_modifier de l'objet, ou a defaut la fonction generique objet_modifier de 
 action/editer_objet. Les fonctions revision_xxx sont par ailleurs dépréciées.
 
Les anciennes fonctions insert&set sont toujours definies et renvoie vers la fonction a nommage conventionnel, pour eviter trop de rupture de compatibilité

verifier plus en amont que le type de fichier qu'on essayer d'uploader est autorise pour eviter de creer des repertoires fantomes inutiles.
Du coup on deplace la verification du type image dans une fonction verifier_document_mode_image,
et ces fonctions de verifications sont appelees deux fois :
- une fois avant copie du fichier dans IMG/
- une fois apres analyse détaillée du contenu du fichier
Les fonctions ne doivent pas refuser a tort un document a la premiere passe si les infos ne sont pas completes

quand on arrive pas a inserer un document en base de donnees, il est de bon ton de le dire plutot que de faire croire que tout s'est bien passe ...

generaliser le cas derogatoire du mode=vignette pour permettre a des plugins d'ajouter des documents avec d'autres modes
Il suffit de fournir une fonction surchargeable inc_verifier_document_mode_xxx_dist() pour que celle ci soit appelee au chargement d'un document dans le mode xxx

[en cours] merge avec le plugin mediatheque  (les documents ne sont plus fonctionnels en l'etat, ne pas mettre a jour dans cette version hors contexte developpement)

Extension medias qui accueille la prise en charge des documents du core. Version preliminaire : extraction des fichiers du core sans modification notable