Report de r108693 : Report de r108692 : le titrage des documents a partir du nom de fichier est un peu restritif, on donne la possibilite de definir sa regle via une fonction inc_titrer_document_dist surchargeable

Revert de r106288 par svn merge -r106288:106287 . car entites_html n'est pas toujours chargee, donc risque erreurs fatales, et le probleme a ete traite en amont dans la fonction _T de maniere plus generique

echapper les entites du nom de fichier/source quand affiche dans les messages d'erreur (Jarrod Farncomb)

Il arrive parfois que des documents images soient téléversés avec la mauvaise extension par rapport à leur contenu réel. Par exemple recevoir un fichier.jpg alors que son contenu est du png.
On corrige cette subtilité lorsqu’on ajoute un document. Dans ce cas le nom du fichier reçoit en complément la nouvelle extension (il devient donc ici fichier.jpg.png), et on le stocke
dans le bon répertoire (ie: IMG/png/fichier.jpg.png). Quelques logs au passage de ces cas.

- une action "desordonner_liens_documents" est ajoutée (un peu sur le même fonctionnement que dissocier_document)
- une action "Réinitialiser l’ordre" est ajouté en fin de liste (visible si un rang_lien au moins est défini)
- les actions affectant l'ensemble des documents en fin de liste sont placées dans une div ".actions-liste"
- les documents déplaçables sont encadrés aussi d'une div (.sortable) essentiellement pour éviter de pouvoir les déplacer au dessus ou au dessous de la pagination ou des actions globales.

Cela permet d'ordonner les documents attachés à des objets éditoriaux. L'ordre est stocké dans la colonne "rang_lien" de la table "spip_documents_liens".

Lorsqu'on édite un document, ne pas réassocier les objets qui sont déjà liés au document, cela évite de perdre des informations en refaisant les liaisons (des rôles par exemple).

Report de [99305] : Ne jamais préjuger d'où sont utilisées les choses : si on utilise une API, on DOIT inclure la librairie nécessaire.

Report de r98560 : plusieurs petits bugs sur les documents distants mal formates qui pourraient exister en base par des operations peu avouables, on teste systematiquement que le fichier ressemble bien a une URL avant de s'y fier

report de r96344 :  Lorsque des roles sont présents, faire en sorte que les boutons "Détacher" et "Supprimer" enlèvent effectivement tous les rôles.

Le comportement n'est pas modifié s'il n'y a pas de colonne de rôle, juste que la spec des fonctions objet_dissocier() indique
bien que sans précision, seul le lien avec le rôle par défaut est dissocié, ce qui ne semble pas le comportement souhaité ici.

différents fix avec php-cs-fixers. Fixers appliqués ici :

	'encoding',                // utf8
	'eof_ending',              // un saut de ligne en fin de fichier
	'elseif',                  // elseif plutôt que else if
	'function_call_space',     // espaces sur fonctions
	'function_declaration',    // espaces sur fonctions
	'function_typehint_space', // espaces sur fonctions
	'linefeed',                // sauts de ligne \n uniquement
	'lowercase_constants',     // true, false, null en munuscule
	'lowercase_keywords',      // mots clés PHP en lowercase
	'method_argument_space',   // espaces sur appels de fonctions
	'multiple_use',            // use unique sur fonctions anonymes
	'newline_after_open_tag',  // ouverture de php… et c'est tout sur cette ligne
	'operators_spaces',        // espaces de part et d'autres des opérateurs binaires
	'parenthesis',             // pas d'espace juste après parenthèse ouvrante, ou avant parenthèse fermante
	'php_closing_tag',         // pas de fermeture de php
	'short_tag',               // tag PHP corrects
	'trailing_spaces',         // pas d'espace qui traîne en fin de ligne
	'visibility',              // déclarer 'public / private / protected' sur les méthodes

Fix https://core.spip.net/issues/3617 : passer $set a objet_modifier_champs pour qu'elle ne detecte les conflits sur $_POST que quand c'est pertinent

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

Fix https://core.spip.net/issues/3433 : ajouter le contenu du document qu'on vient de supprimer a l'appel a post-edition

Report de r89155 : Fix https://core.spip.net/issues/3380 : il faut verifier les droits d'associer/dissocier les documents a un objet dans le formulaire editer objet.
Pour cela on cree 2 autorisations associerdocuments et dissocierdocuments qui par defaut reposent sur autoriser(modifier).
+ n'afficher le lien 'modifier' sur un document que si on a bien le droit de le modifier

Notices et erreur php en moins :  n'est pas défini dans l'une des fonctions de suppression de document. Dans le squelette de formulaire d'ajout de document, la variable fichier_upload revient parfois avec un tableau array(0) => ''. Je ne sais pas du tout quand elle sert, parce qu'en dehors de cela, elle semble tout le temps valoir ''. 

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