Ce site dispose d’un squelette perso avec un formulaire dans l’espace privé pour le configurer.
Ce formulaire est très très gros.
Les données correspondantes dans spip_meta peuvent faire plusieurs dizaines de Ko.
Sous SPIP2, cela fonctionnait. Toutes les données de ce formulaire étaient bien enregistrées sous spip_meta.
En passant à SPIP3, je vois bien les données du formulaire dans l’espace privé. En tout cas, au moins au début.
Mais quand j’enregistre, une partie des données sont effacées. Elles ne sont plus en base spip_meta.
Tout ce passe comme si SPIP3 tronque les données vers la fin du formulaire.
Y’a t’il eu des limitations introduites avec SPIP3 sur la longueur ou la quantité des données enregistrables dans spip_meta ?
non aucune limitation introduite dans SPIP 3 sur la table des meta.
Cela dit, le champ valeur est limité en longueur de manière raisonnable (champ de type text limité à 65535 caractère).
Le fait que tu arrive à la limite de cette longueur signifie surement qu'il faut revoir le stockage de ta configuration, car tout ce qui est stocké dans spip_meta est chargé à chaque hit en mémoire, et 65ko de plus par hit ce n'est pas neutre.
L'API des formulaires de configuration te permet de changer le stockage :
- soit en précisant que tu ceux utiliser une autre table de meta, spécifique à ton plugin
<input type="_meta_table" value="meta_monplugin" />
stockera les données dans la table spip_meta_monplugin, mais c'est à toi de créer cette table dans ton plugin, sur le modèle de spip_meta.
Tu y accèderas ensuite avec par exemple #CONFIG{/meta_monplugin/yyyy/zzz}
- soit en éclatant les données avec une meta par valeur de ton formulaire, et en ajoutant un prefixe :
<input type="_meta_prefixe" value="monplugin" />
<input type="_meta_casier" value="" />
Tu y accèderas ensuite avec par exemple #CONFIG{monplugin_yyyy/zzz}
Dans ce cas, cela ne corrige pas le problème de performance éventuel, car tout est encore stocké dans spip_meta, mais evite d'avoir tout dans une seule valeur serializée.
Voilà presque 8 mois que j’avais commencé cette discussion.
Jusqu’à maintenant, je n’avais pas eu le temps de tester les solutions proposées.
Je vous avais promis de vous tenir au courant, alors voilà…
Cédric, j’ai essayé ta solution mais je n’y arrive pas.
Mon plugin s’appelle devis_express.
Dans le formulaire de config du plugin(configurer_devis_express.html), j’ai inséré juste après le <form…>
Cela ne fait rien d’autre que d’afficher un champs de saisie dans le formulaire.
Pourtant, j’ai bien créé une table spip_devis_express sur le même modèle que spip_meta.
Je pense que je n’ai pas compris ce que tu proposais.
J’ai aussi découvert qu’il existe un attribut meta dans paquet.xml qui permet de préciser la table contenant les conf. et les meta du plugin.
J’ai tenté un meta=“devis_express”
cela n’a rien donné.
La doc n’est pas très causante sur ce sujet.
Bon voilà, j’en suis toujours au même point.
Je fais de nouveau appel à vos lumières
et je vous promets de ne pas attendre 8 mois pour embrayer.
J’ajoute pour ceux qui auraient le même problème qu’il faut un fichier par formulaire. Mais qu’on peut regrouper les balises #FORMULAIRE_XXX dans le fichier /prive/squelettes/contenu/configurer_monplugin.html
Justement, cela me pose un problème. J"ai un formulaire qui est instancié 10 fois,
et c’est celui-là que je veux éclater en 10 meta_casier différents.
Plutôt que faire 10 fichiers différents, j’ai voulu faire un seul fichier configurer_devis_express_choix.html
qui est appelé dans une boucle :
J’ai pas l’impression que la syntaxe est académique mais ça marche.
En revanche, je fais :
pour sélectionner un meta_casier différent.
Dans le code source produit, la valeur de CHOIX est bien remplacé.
Cependant, les valeurs dans le meta ne sont pas lûes, ni écrires.
Pour débuguer, j’ai affiché un #ENV, et je vois bien toutes les valeurs du formulaire mais sans l’indice (1…10).
Tout se passer comme si le formulaire est préprocessé avant. Donc la valeur #GET{CHOIX} n’est pas prise en compte.
J'ajoute pour ceux qui auraient le même problème qu'il faut un fichier par formulaire. Mais qu'on peut regrouper les balises #FORMULAIRE_XXX dans le fichier /prive/squelettes/contenu/configurer_monplugin.html
Justement, cela me pose un problème. J"ai un formulaire qui est instancié 10 fois,
et c'est celui-là que je veux éclater en 10 meta_casier différents.
Plutôt que faire 10 fichiers différents, j'ai voulu faire un seul fichier configurer_devis_express_choix.html
qui est appelé dans une boucle :
<BOUCLE_choix(DATA){enum 1,10}> #FORMULAIRE_CONFIGURER_DEVIS_EXPRESS_CHOIX{#VALEUR}
</BOUCLE_choix>
Cela ne marche pas.
Pour récupérer le paramètre passé à la balise formulaire, j'ai fait : #SET{CHOIX,#ENV{_pipelines/formulaire_fond/args}|table_valeur{0}}
J'ai pas l'impression que la syntaxe est académique mais ça marche.
Malheureux, quel vilain hack !
En effet, pour récupérer l'argument (les arguments) d'un formulaire, il faut les declarer en arguments des fonctions charger, verifier, traiter, ce qui t'obligerait ici à les définir, et donc à perdre le bénéfice du fonctionnement automatique des formulaires configurer
En revanche, je fais :
<input type="hidden" name="_meta_casier" value="choix#GET{CHOIX}" />
pour sélectionner un meta_casier différent.
Dans le code source produit, la valeur de CHOIX est bien remplacé.
Cependant, les valeurs dans le meta ne sont pas lûes, ni écrires.
Pour débuguer, j'ai affiché un #ENV, et je vois bien toutes les valeurs du formulaire mais sans l'indice (1..10).
Tout se passer comme si le formulaire est préprocessé avant. Donc la valeur #GET{CHOIX} n'est pas prise en compte.
Non c'est surtout que _pipelines n'est pas fourni dans le #ENV lors du preprocessing pour detecter les variables, et les casiers, et n'a aucune raison de l'être.
Comment faire ?
Faire un formulaire CVT normal ou tu explicites les fonction charger, verifier, traiter.
Ou faire 10 formulaires configurer, dont le HTML est juste une inclusion du même squelette avec le numéro en argument.