Manque de données sur certains post de bigup (disparition les liaisons de document) #4861
Closed
opened 9 months ago by marcimat
·
14 comments
Loading…
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
En relation avec spip/medias#4872
Lorsqu’on change un document dans l’espace privé, qui est lié à plusieurs articles ou rubriques, seul 1 lien est conservé.
Il semble que le problème vienne des appels à
bigup.getFormData()
.https://git.spip.net/spip/bigup/src/branch/master/javascript/bigup.js#L812
Cette fonction ne prends pas en compte le cas (subtil ?) d’avoir plusieurs hiddens avec un name multiple, sans l’attribut
multiple
La fonction voit bien qu’il y a N inputs
<input type="hidden" name="parents[]" value="article|1">
<input type="hidden" name="parents[]" value="rubrique|1">
Mais au final ne mettra qu’un élément dans le tableau de sortie.
À comparer peut être avec l’évolution de leur fonction chez dropzone.js
f50d1828ab/src/dropzone.js (L1487)
qui s’appuie sur FormData().append()on pourrait pas utiliser la fonction serialize de jQuery.forms qu'on embarque déjà et qui fait le job de façon robuste ? (mais je sais pas si elle fournit au même format les données du form...)
Alors
Permet de remplir un FormData() effectivement, et le .append() crée bien 2 entrées pour l’input.hidden
parents[]
Cela dit forcément ensuite ça ne s’utilise pas pareil qu’un bête tableau tel qu’il y avait…
Notamment on ne peut plus faire
Mais ça devrait devenir qqc comme
Sauf que ce faisant on obtient, après l’upload a priori réussi du fichier
Que je ne vois pas d’où ça vient
Alors pour le 'append' c’est qu’il faut passer une option à
jQuery.ajax
pour dire de pas toucher au formData… et on peut pas l’envoyer depuisjQuery.post
, donc il faut le réécrire avec.Ce qui donne ce diff, pour l’un des JS.
Avec ça j’arrive à modifier un fichier de document sans que ça ne modifie ses liens avec.
Ou donc en plus court en réutilisant les fonctions de jQuery forms:
(data est alors une string, donc le delete qui vient ensuite est penible, mais on peut l'éviter en préparant un data et un data_verifier)
À l’heure où tout semble aller vers une sortie de jQuery pour du plus vanilla, je suis pas certain qu’utiliser une fonction de jquery.form soit le plus adapté.
Quoi qu’il en soit, la fonction de dropzone.js ignore certains champs volontairement, que j’avais complété avec les input.file et les submit. Pour tout récupérer les champs d’un formulaire, le mieux actuellement est de faire un :
Ici (#4862) je propose une méthode donc identique quasimement (.buildFormData()) et une métohode pour simplifier l’ajax ensuite (.send()). Je ne l’ai appliqué pour le moment que sur un seul formulaire.
À voir ?
Donc si je suis bien, #4862 permet de fixer spip/medias#4872 et donc remplacerait spip/medias#4898 ?
Oui @b_b.
Du coup, je me demande s’il faudrait pas faire des branches 3.1 (pour SPIP 4.1) et 2.1 (pour SPIP 4.0) pour bigup, comme on ajoute une fonction ?
Et éventuellement une 1.1 pour SPIP 3.2 ?
Ou pas la peine ?
Je trouve "étrange" de faire une branche X.Y, autant on le fait pour SPIP, mais pour un plugin (même du core) ça me parait un peu "too much". Oui on ajoute une fonction, mais à la base c'est surtout pour corriger un bug.
D'autant plus que pour la branche concernant SPIP 3.2, pas grand monde pourra en bénéficier par SVP puisqu'il le zip n'est pas dans le dépôt de la zone mais celui du core (cf mon questionnement récent à ce sujet https://github.com/geodiversite/geodiversite/issues/29).
Ok. bah ça sera plus simple :p
Bon, je suis plutôt partie pour faire propre au moins pour les branches SPIP 4.1 (c’est fait, branche 3.1, à laquelle j’ai ajouté tes triggers #4860)
et SPIP 4.0…
J’ai également fait une branche 1.1 avec ces reports, pour SPIP 3.2
Donc on peut fermer le ticket ?
On ferme.