Sauf pour les importes depuis f&t, vu que tjr en .yaml + chaine de
langue + maintien compat historique

On en profite pour passer systématiquement datas à `saises_chaine2tableau()`, afin
de profiter systématiquement de `_T_ou_typo()` (même si en l'occurence,
ca passait deja tout le temps, on ne sait jamais pour l'avenir si on
stocke autrement les saisies de formidable...)

Evitons de donner le même nom à la variable qu'on veut retourner et à
celle qui sert de réceptacle à preg_match(), sinon on peut renvoyer en
cas de nom match un tableau array(array(empty)) ce qui n'est pas le
souhait.

remplacement des @@ : s'assurer de ne pas avoir des espaces trainants dans les champs, notamment si on fait (@truc@)

Quand on va chercher les réponses du visiteur en cours, on ne doit pas forcer à ce qu'il ne puisse que re modifier si déjà publié. Si c'était en modération à priori, sa réponse n'est pas validé par un admin mais c'est sa réponse quand même, elle n'est pas à la poubelle, donc il peut continuer de la modifier si on est en option modifiable.

implode(): Passing glue string after array is deprecated. Swap the parameters

Il arrivait parfois, lorsqu'on modifiait une saisie d'un formulaire
existant, et qu'on validait la modif des saisies, que formidable nous
disait que le formulaire avait été modifié en base, alors que ce n'était
pas le cas.
Pourquoi cela ?
Parce que le md5 des saisies initiales stocké par le plugin saisies
était faite à partir des saisies passés au squelette.
Or lorsqu'on passe un tableau en contexte de SPIP, celui transforme
tout `integer`en `string`.
Cela posait problème si les yaml indiquait des paramètres par défaut
sous forme d'entier et pas sous forme de string.
En effet le md5 initial était calculé par saisies sur un tableau du type
````
0 =>
    array (size=4)
      'options' =>
        array (size=4)
          'type' => string 'text' (length=4)
          'size' => string '40' (length=2)
          'autocomplete' => string 'defaut' (length=6)
          'nom' => string 'email_1' (length=7)
      'verifier' =>
        array (size=2)
          'type' => string 'email' (length=5)
          'options' =>
            array (size=1)
              ...
      'identifiant' => string '@5e5bed05e689c' (length=14)
      'saisie' => string 'email' (length=5)
````
Alors que la vérification par formidable se faisait sur un tableau du
type

````
0 =>
    array (size=4)
      'options' =>
        array (size=4)
          'type' => string 'text' (length=4)
          'size' => string 40 (length=2)
          'autocomplete' => string 'defaut' (length=6)
          'nom' => string 'email_1' (length=7)
      'verifier' =>
        array (size=2)
          'type' => string 'email' (length=5)
          'options' =>
            array (size=1)
              ...
      'identifiant' => string '@5e5bed05e689c' (length=14)
      'saisie' => string 'email' (length=5)
````
Forcément les hash n'était pas les mêmes, et cela provoquait une erreur.

Pour éviter cela, on imite le comportement de spip avant de calculer le
hash lors de la vérification: on transforme recursivement dans le
tableau les `integer` en `string`.

SPIP 3.0 n'est plus supporté. On passe donc en compat spip 3.1 minimum , ce qui permet d'utiliser recuperer_url, de faire une requete HEAD plutot que GET, pour vérifier que le fichier est inaccessible

nouveau raccourci pour le message de l'accusé de réception : @message_retour@. Permet de prendre le message standard de retour de formulaire puis de le compléter

c1baaee2 était un peu trop fort. En effet, si jamais on a un identification par id_auteur sans anonymisation, alors la variable PHP peut être pertinente

Amélioration de l'anonymisation dans le cadre une d'identification par identifiant de la personne identifiée. Modification légère de la base.

Possibilité d'utiliser une méthode d'identification par l'identifiant de la personne identifiée tout en anonymisant les réponses.

si on veut la forme brut d'un saisie qui renvoie un tableau, transformer correctement ce tableau avant

les valeurs n'ont pas dans _request() mais dans l'enregistrement d'une
réponse. On peut donc facilement utiliser le raccourci @@ pour afficher
une présentation particulière d'une réponse donnée (cas d'usage : un
plugin perso pour une application métier).

Du coup on fait appel à cette fonction pour affiche_resume_reponse() en
gardant la compatibilité ascendante de ce qui est passé au pipeline
homonyme (dont je doute que qui que ce soit l'utilise, mais c'est une
autre affaire).

l'espace privé affiche pour un formulaire donnée le formulaire, sans passer d'identifiant explicite de réponse précédente. Du coup l'option d'identification par id de réponse plantait (erreur sql). On corrige cela (Florence Henry, contrib)

méthode d'identification de la réponse à éditer : par passage explicite
de l'identifiant, sans tenir compte ni du cookie, ni de l'id_auteur.

fichiers dans tmp/cvtupload. C'est une précaution, si jamais le
déplacement merdouille.

Cvtupload a son propre mécanisme de nettoyage de son dossier.

verifier que l'erreur de fichier est strictement égal à zero. Si c'est équivalent à zero, c'est juste qu'il n'y a pas de fichier (envoi multiple de fichier). Et du coup ca ne sert à rien de faire un traitement dessus.

En plus cela provoquait des fausses erreurs en essayant de zipper des fichiers inexistants. Bizarrement cette erreur se produisait qu'en cas d'ajax.

ne pas proposer de ne pas stocker l'id_auteur si jamais on utilise l'id_auteur pour identifier une réponse et qu'en plus on a besoin d'identifer une réponse