Formidable : changement du mode de stockage => besoin de faire bouger des plugins

Dev
#1

Bonjour à tous et toutes,

ce message s’adresse principalement aux personnes qui créent/maintiennent des extensions de formidable. Il présente un changement à venir dans la manière dont formidable stocke les enregistrements en BDD, puis il pose quelques questions.

Le problème principal

Formidable est amené en stocker en BDD des données tabulaires, à savoir

  • les saisies
  • les traitements
  • les réponses pour les champs multivalués (type checkbox) et les saisies fichiers

Pour l’heure, tout cela est serialisé via serialize(). Nous souhaitons passer en json_encode() via la PR https://git.spip.net/spip-contrib-extensions/formidable/pulls/111/.

En effet, la serialisation PHP en BDD posent plusieurs problèmes :

  • très sensible en cas de corruption de la BDD (par exemple après une restauration);
  • incompatible avec la manière dont SPIP gère les emoji.

Solution proposée

L’idée est donc de sortir une nouvelle version qui :

  • au lieu de ‹ serialize ›, utilise json_encode() pour stocker les futures insertions (aka : lorsqu’on crée ou modifie un formulaire existant / une réponse), sans faire une conversion en série à la MAJ
  • ce qui veut dire qu’on aura en BASE les 2 types de stockages
  • ceci pour ne pas avoir une fonction de migration qui pourrait prendre un temps certains…

On propose par ailleurs deux fonctions :

  • formidable_deserialize() qui tente dans l’ordre :
    - un json_decode()
    - un unserialize() sinon
    - à défaut, renvoie la chaine telle qu’elle
  • formidable_serialize pour serialiser (actuellement : elle appelle json_encode())

On garde par ailleurs filtrer_tenter_unserialize() (deprécié) qui se contente d’appeler formidable_deserialize() .

Enfin, on passe directement les valeurs deserializées des traitements et des saisies dans le $args des fonctions de traitements.

Problèmes

Le problème : il y a des plugins qui deserializent les traitements/saisies pour divers usages.
J’ai fait un grep « serialize » sur les plugins de la zone qui contiennent formidable dans leur nom, et j’ai commencé à faire des ajustement dans des branche formidable_PR_111.

J’ai eu plusieurs cas

1. Des plugins que j’ai commencé à rendre compatible, mais qui sont aussi compatible spip 3.2

Pour ces plugins, trois possibilités :

  1. soit on décide de les rendre SPIP 4.0 compatible seulement
  2. soit on reporte dans formidable v4 (pour spip 3) la fonction formidable_deserialize() (je renoncer à reporter le reste, car il y a désormais pas mal de divergences). Mais attention, cela veut dire que dans paquet.xml il faudra indiquer une version minimale de formidable qui divergerait selon que l’on est en SPIP 4 ou en SPIP 3…
  3. soit on utilise pour ces plugins filtre_tenter_unserialize_dist() qui :
    - existe en formidable v4
    - existe également en formidable v5 (simple appel à formidable_deserialize())
  4. Soit on teste la présence de formidable_deserialize() (proposition de @cerdic https://git.spip.net/spip-contrib-extensions/formidablepaiement/pulls/4#issuecomment-37240)

Ces plugins sont :

=> Personnellement, et @rastapopoulos me rejoint, je serai pour le 1

2. Les plugins concernés mais qui ne sont pas compatible SPIP 4, et donc pour lequel je ne change rien

  • formidable_fusion de @touti
  • formidable_identification de @kent1
  • formidable_importer_reponses de @kent1
  • formidableinscription de @touti
  • formidable_quizz de @rastapopoulos

3. Les plugins que je gère et que je vais rendre compatible SPIP 4 uniquement (si ce n’est pas déjà le cas)

  • formidable_participation_destinataires_supplementaires
  • formidable_ts
  • formidable_rio

Questions

J’aimerais donc, pour les personnes concernées (@tcharlss, @rastapopoulos qui m’a deja donné son avis, @cerdic, @touti):

  • vos avis sur le cas 1
  • vos agrément pour que je fasse les modifs / releases en fonction de la décision prise
  • faut-il pour formidable faire un up de y seulement, ou bien un up de x ?

Mon idée étant de sortir les nouvelles version de formidable et des plugins concernées en bloc, idéalement le WE prochain.

Merci d’avance pour vos avis

Maïeul

Formidable 5.2.0
#2

C’est certainement ce qu’il y a de plus clair à faire pour éviter de s’emmêler les pinceaux.
Merci Maieul pour toutes ces recherches et dev

#3

Bon, finalement sur suggestion de @cerdic, on ne rompt pas les compatibilités (sauf pour formidable_participation_destinataires_supplementaires, un peu plus complexe), on fait juste des tests d’existence.

VOir Formidable 5.2.0 pour les plugins concernés.