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.

Fix http://core.spip.org/issues/3181 : consistance de l'API editet_objet, support du parametre $set sur xxx_inserer

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)

Mauvaise requête sql

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.

Report de r66464 : Post publication des articles : les documents ne prenaient pas le bon statut&date associes (Ferme https://core.spip.org/issues/2849)

Mise a jour des annees pour les Copyrights (je ne connais pas l'utilite de cette info mais autant s'aligner sur les fichiers du core)

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)

Ferme http://core.spip.org/issues/2632 : permettre de dissocier un document associe a la creation d'un article

Un #CACHE sur le modele case document perturbait les affichages au retour du changement de mode
Au passage on normalise l'action changer_mode_document (autorisation et utilisation de document_modifier plutot que sql_updateq)

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)

et utiliser son message d'erreur eventuel en retour pour le faire remonter vers l'interface utilisateur (CVT)
quand il y a lieu

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

on passe action=instituer dans post_edition, et non operation=instituer
de meme, homogeneisons en passant action partout

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

c'est un cas particulier car une rubrique est publiée des qu'elle contient un document qui l'est donc aussi.
il faut depublier la rubrique et mettre a jour le statut du document quand on supprime un lien document/objet

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

Lorsqu'on dissocie un document ajoute lors de la creation d'un article (ou autre), on appelle l'action/dissocier_document avec un id_objet negatif. Ne pas se prendre les pieds dans le tapis lors de la decomposition de $arg
(résoud accessoirement http://core.spip.org/issues/1990, mais sans aucun rapport avec la cause initiale du ticket)