Suite à notre discussion d'hier soir sur IRC, je fais un petit résumé des choses à faire pour à terme aboutir à "pouvoir uploader un ou des documents avec Formidable".
1) Compléter cvtupload pour pouvoir fournir une saisie fichiers.html / fichiers.yaml qui fournisse une présentation pour l'envoi de 1 à n fichiers en tenant compte de ce qui a été développé dans CVtupload pour le stockage temporaire de fichier en cas d'erreur sur les autres champs du formulaire
-> changer la page de démo pour utiliser cette saisie
-> cette saisie sera simple, fonctionnelle en HTML 4 sans js ou autre. On pourra après faire des plugins qui étendent cela en HTML 5 / avec du js pour du plus convivial
2) Compléter cvtupload de telle sorte que le $_FILES prennent en compte le nouveau chemin temporaire dans tmp/cvtupload (afin, j'imagine qu'il y a une constante quelque part)
3) déplacer l'ensemble des outils de vérifications d'une saisie d'envoi dans le plugin verifier
4) fusionner ces outils en un seul outil à options qui permette de vérifier, selon les paramètres:
- le mime type + extension avec trois options possibles:
- tous les mime types autorisés par spip
- uniquement les mimes types d'image (png/jpg/gif)
- des mimes types spécifiques
- la taille max
- si image, largeur maximum/dimension
5) s'assurer qu'en cas d'échec lors d'un test de vérification, le fichier temporaire est supprimé (après réflexion, je pense que c'est déjà le cas dans CVT upload)
6) une fois tout cela fait, on peut s'attaquer à la partie formidable (sous-plugin à part? ou directement dans formidable?):
-Cas de traitement "enregistrer les réponses"
- les fichiers sont stockés dans config/formidable_upload (PERMANENT_INACCESSIBLE/formidable_upload)
- ils ne sont accessibles qu'aux gens qui peuvent lire les réponses, via une action
- éventuellement possibilité d e:
- supprimer ces fichiers
- envoyer ces fichiers vers la médiathèque
- la question reste ouverte de savoir comment on gère si on a simplement "envoyer un mail":
- envoi en PJ ? mais quid si trop lourd? quid de la sécurité?
- Stockage temporaire dans un répertoire qui est vidé de ses fichiers les plus anciens régulièrement, et envoi du lien dans email?
Voilà, dis-moi si on s'est bien compris, si je n’ai rien oublié d'important, etc.
-> changer la page de démo pour utiliser cette saisie
Pas forcément, ou alors deux pages/formulaires différents : du point de vue "cvtupload", Saisies est un truc en plus facultatif, il "fournit" une saisie qui est compatible avec son fonctionnement, mais n'importe quels champs file habituels fonctionnent avec (puisque le but est de compléter l'API CVT générique, et possiblement un jour l'intégrer au core si ça marche bien, donc sans rapport avec Saisies).
6) une fois tout cela fait, on peut s'attaquer à la partie formidable
(sous-plugin à part? ou directement dans formidable?):
Directement dans Formidable, pour moi. Peut-être en nécessitant cvtupload, mais en fait non, même pas besoin :
1) s'il y a une saisie "fichiers" ça sera forcément que cvtupload est utilisé
2) et en fait même si ça vient d'autre part on s'en fiche, puisque le but est de rendre cvtupload transparent en remettant le FILES, donc le traitement dans Formidable utilisera le FILES générique.
On pourrait même ne rien attendre de précis et utiliser FILES si remplit mais ça ne serait pas bien pour la sécu puisqu'on peut (avec les outils de devs du navigateur) injecter le HTML qu'on veut dans un formulaire et ainsi envoyer des fichiers même si pas prévu au départ.
Donc à priori le but serait de tester s'il y a des saisies de type "fichiers" et faire des choses en conséquence.
D'ailleurs, c'est pas juste pour "traiter" : cvtupload attend qu'on déclare explicitement les champs de type file, afin de savoir lesquels il doit gérer. Donc Formidable (ou Saisies !?) doit lui déclarer avec la fonction attendue, si on en trouve.
-> changer la page de démo pour utiliser cette saisie
Pas forcément, ou alors deux pages/formulaires différents : du point de
vue "cvtupload", Saisies est un truc en plus facultatif, il "fournit"
une saisie qui est compatible avec son fonctionnement, mais n'importe
quels champs file habituels fonctionnent avec (puisque le but est de
compléter l'API CVT générique, et possiblement un jour l'intégrer au
core si ça marche bien, donc sans rapport avec Saisies).
-> ok, très bien on fera une demo supplémentaire
6) une fois tout cela fait, on peut s'attaquer à la partie formidable
(sous-plugin à part? ou directement dans formidable?):
Directement dans Formidable, pour moi. Peut-être en nécessitant
cvtupload, mais en fait non, même pas besoin :
1) s'il y a une saisie "fichiers" ça sera forcément que cvtupload est
utilisé
2) et en fait même si ça vient d'autre part on s'en fiche, puisque le
but est de rendre cvtupload transparent en remettant le FILES, donc le
traitement dans Formidable utilisera le FILES générique.
On pourrait même ne rien attendre de précis et utiliser FILES si remplit
mais ça ne serait pas bien pour la sécu puisqu'on peut (avec les outils
de devs du navigateur) injecter le HTML qu'on veut dans un formulaire et
ainsi envoyer des fichiers même si pas prévu au départ.
Donc à priori le but serait de tester s'il y a des saisies de type
"fichiers" et faire des choses en conséquence.
D'ailleurs, c'est pas juste pour "traiter" : cvtupload attend qu'on
déclare explicitement les champs de type file, afin de savoir lesquels
il doit gérer. Donc Formidable (ou Saisies !?) doit lui déclarer avec la
fonction attendue, si on en trouve.
donc proposition:
1. La saisie (qui pour le moment est cvtupload, mais qui sera déplacée dans saisies si cvtupload est intégrée dans le core) fournit les informations à cvtupload
2. formidable regarde FILES, mais pour des raison de sécurité s'assure que cela correspond bien à une saisie déclarée de type FICHIERS