Saisies

Publié le : 27 mars 2010 – Dernière modification le 4 novembre 2023 – par Maïeul, RastaPopoulos – 751 commentaires

75 votes

Le plugin Saisies facilite le développement des formulaires, en proposant des méthodes et outils pour déclarer et vérifier les champs.

Introduction

Créer un formulaire est une tâche toujours un peu répétitive : les champs ont souvent les mêmes propriétés, le même accompagnement (message d’erreur, explication ...) et la même structure HTML. Ce plugin est un outil d’aide au développement, ayant pour but de faciliter et d’accélérer l’écriture des formulaires.

Pour cela, Saisies propose plusieurs mécanismes (balises, API PHP) pour générer et manipuler plus facilement les champs des formulaires. De cette manière, les squelettes de formulaires sont :

plus lisibles : il n’y a que le strict nécessaire dedans, pas de répétition ;
intégrés au fonctionnement CVT de SPIP, notamment pour la gestion des erreurs sur les champs ;
automatiquement compatibles avec les recommandations HTML/CSS de SPIP.

Dans la présente documentation, nous présentons la manière de construire un formulaire avec Saisies de la méthode la plus robuste à la méthode la moins robuste.

Les méthodes moins robustes sont présentées pour deux raisons :

ce sont les méthodes les plus anciennes. On trouve encore beaucoup de code les utilisant ;
il est parfois nécessaire de passer par là, pour des réglages fins.

Pour utiliser l’API complète PHP, vous devez installer ou nécessiter le plugin YAML dans votre plugin. Ce n’est pas le cas quand on utilise juste la simple balise, ce pourquoi c’est à vous de le nécessiter.

Dans la présente documentation, lorsqu’un code est entre chevrons (comme <ceci>), vous devez le remplacer par une valeur correspondant à votre projet.

Cette documentation est valable à partir de la version 4.11.0 ou du plugin.

Méthode 1 : déclarer un formulaire CVT complet en PHP

Principe

Saisies augmente l’API CVT de SPIP avec une fonction formulaires_<nomduformulaire>_saisies() afin de déclarer l’ensemble des champs d’un formulaire et leur vérification dans une unique syntaxe. Cette fonction permet également de déclarer différents réglages de formulaire, tel que :

le label du bouton de validation final ;
l’utilisation en multiétapes.

Grâce à ce mécanisme, pour les cas les plus courants, les fonctions formulaires_<nomduformulaire>_charger() et formulaires_<nomduformulaire>_verifier() deviennent facultatives. Saisies s’occupera de tout suivant votre déclaration. Seule la fonction formulaires_<nomduformulaire>_traiter() reste toujours de votre ressort.

De même, par défaut, vous n’avez plus à vous occuper du squelette. Il doit toujours être présent, avec le même nom que votre fichier PHP dans le dossier formulaires/, mais vous devez le laisser totalement vide. Saisies s’occupera de générer le HTML complet, en suivant les recommandations de structuration de SPIP.

Enfin, dans le cas particulier où vous créez un formulaire de configuration, vous n’aurez même pas à déclarer les valeurs par défaut ni le traitement. Voir l’article « Formulaire de configuration avec le plugin Saisies ».

Mise en œuvre

Il vous faut donc créer un fichier formulaires/<nomduformulaire>.html vide, ainsi qu’un fichier formulaires/<nomduformulaire>.php contenant deux fonctions :
- formulaires_<nomduformulaire>_traiter(), qui indique ce que votre formulaire doit effectuer comme traitement ; cela n’est pas du ressort du plugin Saisies ;
- formulaires_<nomduformulaire>_saisies(), pour déclarer les saisies proprement dites.

Cette dernière fonction reçoit comme arguments les mêmes arguments que la fonction _charger() du formulaire CVT, et elle doit retourner un tableau PHP contenant la liste de toutes vos saisies suivant un formalisme attendu.

formulaires_<nomduformulaire>_saisies(…) {
    $saisies = […];
    return $saisies;
}

Déclaration de l’ensemble des saisies

Chaque ligne globale du tableau renvoyé décrit une saisie.
L’ordre des éléments sera l’ordre des saisies.

$saisies = [
    […], // une saisie
    […], // une saisie
    […], // une saisie
];

Déclaration d’une saisie individuelle

Chaque saisie est elle-même décrite dans un tableau, qui prend par exemple la forme suivante :

[
    'saisie' => 'input',
    'options' => [
        'nom' => 'nom',
        'label' => 'Votre nom',
        'defaut' => 'Valeur par défaut'
    ],
];

On consultera « Référence des saisies » pour avoir l’ensemble des saisies et des options disponibles en standard.

D’autres plugins ajoutent leurs propres saisies, et vous pouvez aussi créer vos propres saisies.

Déclaration des saisies enfants

Les saisies qui acceptent des enfants (comme les fieldsets) les placent dans une clé saisies dont la valeur est un tableau ayant la même structure que le tableau global :

$un_fieldset = [
    'saisie' => 'fieldset',
    'options' => [
        'nom' => 'mon_groupe',
        'label' => 'Mon groupe de champ'
    ],
    'saisies' => [
        […], // une autre saisie
        […], // une autre saisie
        […], // etc
    ]
];

Appliquer des vérifications

Pour des vérifications simples et uniques vous pouvez en déclarer des vérifications à appliquer sur chacune de vos saisies, avec le plugin API de Vérification (qui n’est pas activé automatiquement avec le plugin saisies).

Il faut alors ajouter une clé verifier selon ce formalisme :

[
	'saisie' => 'input',
	'options' => [
		'nom' => 'slug',
		'label' => 'slug',
		'obligatoire' => 'oui',
	],
	'verifier' => [
		[
			'type' => 'taille',
			'options' => ['min' => 10]
		],
		[
			'type' => 'slug',
		],
	],
];

Permet de vérifier que nous avons affaire à un slug d’une taille minimum de 10 caractères.

Consulter « Références des vérifications » pour la liste des types de vérification livrés avec le plugin et de leurs options.

Pour les versions du plugin < 4.3.0, il n’est possible de déclarer qu’une seule vérification par saisie, sous la forme :

[
    'saisie' => 'input',
    'options' => [
        'nom' => 'nom',
        'label' => 'nom',
        'obligatoire' => 'oui',
    ],
    'verifier' => [
            
        'type' => 'entier',
        'options' => [
            'min' => 100,
            'max' => 500
        ],
    ],
];

Support du multilinguisme

Saisies supporte le multilinguisme. Ainsi, dans l’exemple ci-dessous, la chaine de langue <:cle:valeur:> sera automatiquement interprétée.

[
    'saisie' => 'input',
    'options' => [
        'nom' => 'nom',
        'label' => '<:cle:valeur:>',
        'size' => 50
    ],
];

Options globales

Il est possible de déclarer des options d’affichage globales à l’ensemble du formulaire. Elles sont alors placées dans une clé options à la racine du tableau des saisies.

$saisies = [
    'options' => [
        // Changer l'intitulé du bouton final de validation
        'texte_submit' => 'Valider c’est gagné',
        …
        '<option>' => '<valeur>' //Une autre option
    ],
    […], // une saisie
    […], // une saisie
    […], // une saisie
);

Option	Usage	Valeur possible	Valeur par défaut
Options pour le bouton de validation
`texte_submit`	Texte du bouton de validation	Texte, passe par `_T_ou_typo()`	`<:bouton_enregistrer:>`
`afficher_si_submit`	Condition pour afficher le bouton de validation	Voir « Affichage conditionnel des saisies : syntaxe des tests »	`null`
Options pour la gestion des étapes multiples
`etapes_activer`	Activer la gestion multi-étapes, chaque `fieldset` de premier niveau devient une étape	`True\|False`	`False`
`etapes_presentation`	Mode de présentation des étapes en haut du formulaire	`'defaut'\|'courante'`, il est possible de créer son propre mode en créant un squelette `formulaires/inc-saisies-cvt-etapes-<presentation>.html`	`defaut`
`etapes_suivant`	Texte du bouton pour aller à l’étape suivante	Texte, passe par `_T_ou_typo()`	`<:bouton_suivant:>`
`etapes_precedent`	Texte du bouton pour revenir à l’étape précédente	Texte, passe par `_T_ou_typo()`	`<:precedent\|ucfirst:>`
`etapes_precedent_suivant_titrer`	Permet d’ajouter le titre des étapes dans les boutons « précédent » et « suivant »	`True\|False`	`False`
`etapes_ignorer_recapitulatif`	Permet de ne pas insérer de récapitulatif avant la validation finale	`True\|False`	`False`
Options techniques
`verifier_valeurs_acceptables`	Permet de s’assurer que les valeurs reçues figurent bien parmi les valeurs proposées lors de la saisie du formulaire	`True\|False`	`False`
`afficher_si_avec_post`	Permet que les saisies masquées par affichage conditionnel soient tout de même postées	`True\|False`	`False`
`inserer_debut`	Contenu arbitraire à insérer au début du formulaire, par exemple pour appeler un script Javascript	Chaîne de caractères	`null`
`inserer_fin`	Contenu arbitraire à insérer à la fin du formulaire, par exemple pour appeler un script Javascript	Chaîne de caractère	`null`

Si un texte passe par _T_ou_typo(), cela peut être :

un texte directement écrit dans la langue du site ;
un appel à une chaîne de langue sous la forme <:fichier_de_langue:chaine:> ;
un texte utilisant la balise <multi> pour gérer l’internationalisation.

Pipeline

Lors du chargement des saisies déclarées via une fonction formulaires_<nom_du_formulaire>_saisies(), les saisies sont passés à un pipeline formulaire_saisies. Le tableau $flux passé à ce pipeline à la structure suivante :

- $flux['args']['form'] : le nom du formulaire ;
- $flux['args']['args'] : les différents arguments passés ;
- $flux['data'] : les saisies.

Il est donc possible à un plugin de modifier dynamiquement les saisies d’un formulaire en utilisant les différentes fonctions de l’API de saisies.

Méthode 1a : déclarer un formulaire CVT en PHP, mais effectuer soi-même des vérifications

Parfois il est nécessaire d’avoir des vérifications supplémentaires sur les saisies. Pour ce faire, vous devez déclarer votre propre fonction formulaires_<nomduformulaire>_verifier().

Dans ce cas, vous ne perdrez pas le bénéfice d’une déclaration des vérifications de base dans votre tableau de saisies : celles-ci sont alors automatiquement effectuées après vos propres vérifications.

Toutefois, il est parfois nécessaire de faire en sorte que les vérifications « par déclaration » se fassent avant vos propres vérifications. Dans ce cas, la méthode la plus propre est de déclarer ses vérifications non pas sous forme d’une fonction formulaires_<nomduformulaire>_verifier(), mais par la création d’une fonction formulaires_<nomduformulaire>_verifier_post_saisie(), ou sa variante verifier_etapes_post_saisies() dans le cadre du multiétape.

À noter qu’il existe deux pipelines pour ajouter des vérifications à un formulaire existant : formulaire_verifier_post_saisies et formulaire_verifier_etapes_post_saisies.

Méthode 1b avec `#GENERER_SAISIES` : contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies

Dans quelques cas rares, la structure globale du formulaire livrée avec Saisies ne convient pas. Pour autant, vous souhaitez.

profiter du formalisme de déclaration des saisies
profiter de la vérification automatique de ces saisies (sauf si vous utilisez la méthode 1a).

Dans ce cas :

vous mettez dans votre fichier formulaires/<nomduformulaire>.html la structure globale du formulaire correspondant à votre besoin ;
là où vous souhaitez insérer vos saisies, vous utilisez la balise #GENERER_SAISIES.

Cette balise permet de générer toutes les saisies d’un formulaire, en une seule fois. Pour cela on lui passe en paramètre le tableau de description.

Exemple d’utilisation :

<div class="formulaire_spip formulaire_#ENV{form}"[(#ENV{_etape}|oui)formulaire_multietapes]">
<form .... [ data-resume_etapes_futures="(#ENV{_resume_etapes_futures}|json_encode|attribut_html)"]>
....
<div >
    #GENERER_SAISIES{#ENV{_saisies}}
</div>
....
</form>
</div>

On notera l’emploi d’un _ en préfixe de la variable d’environnement. Cela permet que les guillemets présents dans les options ne soient pas transformés en entités HTML [1].

#ENV{_saisies} est rempli automatiquement avec la valeur de retour de la fonction formulaires_<nomduformulaire>_saisies() [2].

On n’oubliera pas les attributs suivants :
- les différentes classes sur le <div> englobant
- l’attribut [ data-resume_etapes_futures="(#ENV{_resume_etapes_futures}|json_encode|attribut_html)"] sur le <form>, qui permet de gérer correctement les affichages conditionnels des étapes dans un formulaire multi-étape.

Par ailleurs, on utilisera

		[(#ENV{_etape}|oui)
			<INCLURE{fond=formulaires/inc-saisies-cvt-etapes-#ENV{_saisies/options/etapes_presentation,defaut}, etapes=#ENV{_saisies_par_etapes}, env} />
		]
</div>
pour insérer le chemin d'étapes, et 

<cadre class="spip">
<INCLURE{fond=formulaires/inc-saisies-cvt-boutons,env} />

pour les boutons de validation.

Méthode 2 : la balise `#SAISIE`

Parfois on veut pouvoir contrôler encore plus finement la présentation des saisies. Pour ce faire, on peut insérer dans formulaires/<nomduformulaire>.html des appels à la balise #SAISIE.

Cette méthode n’est pas toujours adaptée, car elle présente des limitations :

elle ne permet pas de profiter des vérifications automatiques ;
elle ne permet pas de profiter du mécanisme d’affichage conditionnel.

#SAISIE permet de générer une seule saisie en lui donnant directement les paramètres désirés. Chaque saisie va générer une ligne dans un formulaire, c’est-à-dire un élément <div>.

La balise #SAISIE a deux arguments obligatoires : le type de saisie, et son nom HTML (attribut « name »). Toutes les autres options sont facultatives et servent à configurer le champ ; de ce fait, elles sont de la forme option=valeur.

La forme complète est donc la suivante :
#SAISIE{type, name, option=valeur, option2=valeur2, etc=etc}

Voici quelques exemples d’utilisation.

Génère un simple champ texte, indiqué comme étant obligatoire :
#SAISIE{input, email, label=Votre courriel, obligatoire=oui}

Génère un choix multiple parmi les utilisateurs du SPIP :
#SAISIE{auteurs, destinataires,
    label=Destinataires du message,
    explication=Choisissez une ou plusieurs personnes à qui sera envoyé le message.,
    multiple=oui}

Comme vous le voyez, des champs qui peuvent être complexes, et fastidieux à écrire de manière complète, s’écrivent ici en quelques lignes.

#SAISIE supporte le multilinguisme. Dans ce cas, attention de bien utiliser la syntaxe complète avec les crochets :

#SAISIE{input, annee, label=<:monplugin:annee:>,obligatoire=oui} ne fonctionne pas ;
[(#SAISIE{input, annee, label=<:monplugin:annee:>,obligatoire=oui})] fonctionne.

Appendice 1 : chargement des CSS et scripts Javascript sur le site public

Si votre formulaire est destiné à être public, le plugin se charge d’ajouter automatiquement les appels aux fichiers CSS et scripts Javascript associés aux saisies utilisées sur le site public, lorsque le formulaire est effectivement utilisé.forme

Toutefois, si vous avez beaucoup de formulaires utilisant Saisies sur le site public, il peut être judicieux de charger systématiquement les fichiers sur toutes les pages, afin de profiter de la compréhension et du cache navigateur. Dans la configuration du plugin (« Squelettes »->« Configuration du plugin Saisies »), une option permet d’activer cela.

Appendice 2 : enregistrer des tableaux

La norme HTML permet de gérer des réponses de formulaire sous la forme de tableau.

Dans la déclaration de la saisie, on peut utiliser la syntaxe HTML classique avec crochets :

[
    'saisie' => 'input',
    'options' => [
        'nom' => 'annee[debut]',
        'label' => 'Votre nom',
        'size' => 50
    ],
];

Mais il est recommandé d’utiliser le formalisme SPIP suivant : <tableau>/<clé>.

[
    'saisie' => 'input',
    'options' => [
        'nom' => 'annee/debut',
        'label' => 'Label',
        'size' => 50
    ],
];

Le code suivant permettra de récupérer la valeur en PHP :

$annee = _request('annee');
$debut = $annee['debut'];

Appendice 3 : la balise `#VOIR_SAISIES`

Cette balise permet d’afficher toutes les valeurs saisies après validation d’un formulaire. On lui passe en paramètre deux arguments :

le tableau de description des saisies (au même format que pour #GENERER_SAISIES)
un tableau des valeurs saisies

Exemple d’utilisation, dans le squelette d’un formulaire :

[(#EDITABLE|non)
    #VOIR_SAISIES{#ENV{mes_saisies}, #ENV}
]

Appendice 4 : problème avec Xdebug

Si vous développez en utilisant le logiciel Xdebug, il existe un problème connu : par défaut celui-ci affiche une erreur à partir d’un certain niveau d’imbrication de fonctions PHP (« nesting level » dirait Shakespeare).

Le niveau d’imbrication autorisé par défaut est relativement bas, mais on peut le paramétrer. Vous devez donc ajouter cela dans votre configuration PHP/Xdebug :

[xdebug]
xdebug.max_nesting_level = 200 ou 500 ou plus…

Et hop, ça remarche.

Notes

[1] Voir la documentation de la fonction _charger des formulaires CVT.

[2] Historiquement, elle pouvait aussi être remplie manuellement en ajoutant une clé _saisies dans le tableau de retour de la fonction formulaires_<nomduformulaire_charger(), toutefois ceci ne permet pas de bénéficier de tous les mécanismes d’automatisme du plugin saisies, et les bugs risquent d’être présents. Ce n’est donc pas une fonctionnalité officiellement supportée et validée.

Voir aussi la doc complémentaire et participative sur le wiki :
Saisies : Doc complémentaire

Discussion

5 ans 1 an 3 mois Sans limite

par date

179 discussions

5

jfg35

Juillet 2019

Bonjour,
En faisant une mise à jour du plugin vers la version 3.22.0, le site a été bloqué.
En revenant à la version antérieure 3.21.2, ce problème a été réglé.
SPIP 3.2.4
Cordialement
- RastaPopoulos
  
  Juillet 2019
  
  Que signifie « le site a été bloqué » ? Si tu as une page blanche tu dois configurer PHP pour afficher les erreurs, afin de savoir vraiment ce qui se passe.
  https://www.spip.net/fr_article4453.html#erreurs
- David
  
  Juillet 2019
  
  Bonjour,
  
  Après la mise à jour du plugin, j’ai bien une page d’erreurs PHP. Je n’ai pas fait de capture d’écran.
  Je l’ai désactivé et réinstallé. Le plugin reste obsolète.
  
  Cordialement
- Maïeul
  
  Juillet 2019
  
  bah en l’absence de message d’erreur, ca va être dur d’aider...
- David
  
  Juillet 2019
  
  Merci, avec la version 3.22.1 j’ai pu mettre à jour et cela fonctionne.
- Maïeul
  
  Juillet 2019
  
  la version 3.22.1 ne portait pas sur ce problème, puisque je le connaissais pas ....
Répondre à ce message
3

JuL BLoBuL

Juin 2019

Bonsoir,

Je n’arrive plus à configurer mes groupes de champs et mes champs ’explication’ dans champs extras, je pense qu’une mise à jour récente en est la cause. Est-ce que SAISIES en est la cause ?

Bien à vous,
Jul
- Maïeul
  
  Juin 2019
  
  oui, mea culpa. J’ai voulu exclure les saisies fichiers mais j’ai été un peu trop radical. Je vais regarder comme faire.
- Maïeul
  
  Juin 2019
  
  la prochaine version de saisies et de champ extra interface corrige ce bug.
- JuL BLoBuL
  
  Juin 2019
  
  Youpi. Merci !!!
Répondre à ce message
5

Voillemont

Avril 2019

Bonjour, j’ai mis un sondage réalisé avec formidable.
Depuis peu, j’ai ses messages d’erreur qui s’affichent dans les résultats du sondage. J’ai cherché pour voir de quoi ça vient sans trouver.
Une idée ?

Merci d’avance pour votre aide.

Warning : array_keys() expects parameter 1 to be array, null given in /home/chipfm/public_html/plugins/auto/saisies/v3.18.5/inc/saisies_lister.php on line 135

Warning : array_shift() expects parameter 1 to be array, null given in /home/chipfm/public_html/plugins/auto/saisies/v3.18.5/inc/saisies_lister.php on line 136

Warning : Invalid argument supplied for foreach() in /home/chipfm/public_html/plugins/auto/saisies/v3.18.5/inc/saisies_lister.php on line 141
- Maïeul
  
  Avril 2019
  
  Pouvez vous envoyer un export yaml du formulaire ? cela me permettrait de remonter la piste.
  
  A priori, ce n’est pas très grave. Cela étant, il faudrait demander à votre hébergeur, ou régler vous même, pour que les messages d’erreurs ne s’affichent pas publiquement.
- Christian Voillemont
  
  Avril 2019
  
  merci pour votre aide.
  
  J’ai fait l’export., comment vous l’envoyer ?
  
  Comment puis je régler pour que les messages d’erreur ne s’affichent pas ?
- Maïeul
  
  Avril 2019
  vous pouvez m’écrire à monprenom@monprenom.net
  
  pour le réglage de l’affichage des erreurs, ca depnd des hebergeurs. Mais dans tous les cas
  
  ini_set('display_errors', 0);
  
  dans votre fichier mes_options.php pourrait masquer cela. Cela étant, ce serait bien de voir avec votre hebergeur pour que ce soit masqué par défaut.
- christian voillemont
  
  Avril 2019
  
  Merci, je regarde ça tout de suite.
  Je suis long a répondre car j’ai des coupures internet fréquentes.
- Maïeul
  
  Avril 2019
  
  la version 3.36.6 du plugin Formidable devrait corriger le problème.
Répondre à ce message
4

Rainer Müller

Janvier 2019

Bonjour,

avec la version 3.12.6, je n’arrive plus à définir de valeurs personnalisées pour la saisie oui_non.

J’obtiens une erreur « Valeur postée non acceptable. »

la fonction oui_non_valeurs_acceptables($valeur, $description) semble exclure en effet la possibilité d’utiliser de valeurs personnalisées.
- Maïeul
  
  Janvier 2019
  
  arf, j’ai du oublier de mettre cela, parce que je savais pas que c’était possible (pas déclaré dans le yaml)
  
  j’essaie de m’occuper de cela présentement.
- Maïeul
  
  Janvier 2019
  
  voilà, la version 3.12.7 devrait résoudre le problème.
- Rainer Müller
  
  Janvier 2019
  
  Parfait, merci
- Rainer Müller
  
  Janvier 2019
  Encore un bug ou je comprends mal le fonctionnement
  
  La valeur par défaut dans« oui_non » et « selection » n’est pas pris en compte.
  
  Actuellement, dans les saisies correspondantes, la valeur est définie
  
  #SET{valeur,#ENV{valeur_forcee,#ENV{valeur}}|is_null|?{#ENV{defaut},#ENV{valeur_forcee,#ENV{valeur}}}}
  
  et ma valeur défaut est ignoré.
  
  Si je remplace par
  
  #SET{valeur,#ENV{valeur_forcee,#ENV{valeur,#ENV{defaut}}}}
  
  ma valeur défaut est bien prise en compte.
  
  Spip 3.2.3 avec php 7.2
Répondre à ce message
16

Bilal

Janvier 2019

Bonjour,
depuis la mise à jour du plugin vers sa dernière version disponible (v3.12.5) sous SPIP 3.2.1, j’obtiens à la validation d’un formulaire :

ERREUR : fonction execute_pipeline_saisies_verifier absente : pipeline desactive

Une idée de la raison ?
- Maïeul
  
  Janvier 2019
  
  Quelle était la précédente version de saisies ? on n’a pas touché recemment aux pipelines.
  
  Est-ce que tu as essayé en supprimant le fichier tmp/cache/charger_pipelines.php ?
- Bilal
  
  Janvier 2019
  
  Merci de ta réponse rapide et de ton aide. Oui j’ai vidé tous les caches. Je ne me souviens plus la version précédentes de saisies installée, mais ma dernière mise à jour des plugins ne remonte pas plus loin que novembre dernier. J’ai fait des tests avec différents formulaires, et j’obtiens toujours le même message.
- Maïeul
  
  Janvier 2019
  
  Ce sont des formulaires de SPIP ? ou des formulaires formidable ?
  
  tu as mis à jour tous les plugins ? ou seulement saisies ?
- Maïeul
  
  Janvier 2019
  
  Je pense que la version 3.12.6 binetôt disponible devrait résoudre ce problème, mais à confirmer car je n’arrive pas à le reproduire.
- Bilal
  
  Janvier 2019
  
  Cela se produit avec les formulaires Formidable et oui j’ai mis à jour tous les plugins. J’espère que cela n’est pas trop grave. Ok je verrais avec la MAJ du plugin. Merci de ton attention.
- Aurelien
  
  Janvier 2019
  
  J’ai le même log étrange :
  fonction execute_pipeline_saisies_verifier absente : pipeline desactive
  
  Et je ne parviens pas a en trouver l’origine, d’autant plus que les vérifications fonctionnent très bien, et que rien ne semble désactivé (SPIP 3.2.3 [24211] & API Verifier 1.8.2).
  
  Bonne soirée,
- thrax
  
  Janvier 2019
  
  Effectivement il y a un problème. Même message.
  Celui-ci n’apparait pas lorsque le formulaire n’utilise pas afficher_si
  C’est cette utilisation qui génère ce problème.
  Soit notre appel n’est pas convenablement fait, ce qui est probable, soit il y a un autre souci.
  Je travaille sur la question...
- thrax
  
  Janvier 2019
  
  Non, après un vider le cache, l’erreur se maintien et cela ne semble pas lié à « afficher_si »
  Le test se base sur :
  https://contrib.spip.net/Un-formulaire-C-V-T-avec-Saisies-par-l-exemple
  et le log
  2019-01-31 09:00:43 ::1 (pid 60629) :Pri:ERREUR : fonction execute_pipeline_saisies_verifier absente : pipeline desactive
- thrax
  
  Janvier 2019
  
  Trouvé. C’était yaml. Le plugin en version test (2.0.10 - en test) n’est pas très sympathique avec SAISIES.
- RastaPopoulos
  
  Janvier 2019
  
  Mais de quoi c’est yaml ? Quel rapport avec le pipeline « saisies_verifier » ? Vous avez bien la dernière version de Saisies avec la modif de Maieul qui déclare le pipeline manquant, qui n’était pas déclaré depuis le début ?
  https://zone.spip.net/trac/spip-zone/changeset/113611/spip-zone
- Maïeul
  
  Janvier 2019
  
  J’avoue non plus ne pas voir en quoi il y pourrait y avoir un lien avec yaml.
  
  En attendant, la question reste : quelle version du plugin saisies utilisez vous ?
- thrax
  
  Janvier 2019
  
  J’étais sous SAISIES 3.12.4, j’ai tout resintallé (dont SAISIES 3.12.6 ) et j’ai eu ce message :
  Erreur dans les plugins :
  /Applications/MAMP/htdocs/plugins/yaml_v2/yaml_fonctions.php,
  /Applications/MAMP/htdocs/plugins/verifier/verifier_fonctions.php
  Après le retrait de Yaml, tout se passe bien.
  D’ou ma conclusion, certainement hâtive...
- Maïeul
  
  Janvier 2019
  
  est tu repassé par la page d’admin des plugins après reinstall ?
- thrax
  
  Janvier 2019
  
  Oui, car j’avais même réinstallé SPIP. J’avais fait table rase en local pour tout reprendre à zéro et comprendre ce qui se passait.
- Maïeul
  
  Janvier 2019
  
  bah c’est peut être une coincidence alors.
  
  le mieux reste encore d’installer le plugin eu mode automatique, pour être sur d’avoir la dernière version à chaque fois.
- thrax
  
  Janvier 2019
  
  En tout cas plus de problème et merci pour votre aide (ainsi que pour cette API Verfier et ce plugin SAISIES super).
Répondre à ce message
3
Chourak

Janvier 2019
Je regardais pour rendre obligatoire une saisie « radio » (pour une vérif html5) et en testant je me rends compte que ca ne fonctionne pas tip top.
Et le fichier radio.html ne fait aucune mention d’un test sur obligatoire.
[(#HTML5|oui)[(#ENV{obligatoire}|et{#ENV{obligatoire}|!={non}}|oui) required="required"]]
C’est voulu ?

Du coup je surcharge ma saisie avec le code ci-dessus.
- Chourak
  
  Janvier 2019
  Et d’ailleurs ma solution n’en est peut-être pas vraiment une car elle entraine des effets de bords indésirables sur les saisies radio obligatoires avec afficher_si, qui du coup me sort des jolis
  
  An invalid form control with name='truc' is not focusable.
- Maïeul
  
  Janvier 2019
  
  Merci du signalement.
  
  Il fallait aussi modifier le code du js pour afficher_si
  
  https://zone.spip.net/trac/spip-zone/changeset/113558/spip-zone
  fait cela
- Chourak
  
  Janvier 2019
  
  Ah nickeul Maïeul !
  
  Merci, ca marche bien du coup :)
Répondre à ce message
6
JuL BLoBuL

Janvier 2019
Bonjour à tous,
Je rencontre un soucis avec l’utilisation du paramètre « afficher_si » dans un formulaire dont les champs sont généré via PHP, puis en exploitant la balise #GENERER_SAISIE.

Voici un morceau de mon formulaire CVT en php :
$saisies[]= array( 'saisie' => 'selection', 'options' => array( 'nom' => 'select_type_inscrit', 'label' => 'Type d\'inscrit', 'obligatoire' => 'oui', 'datas' => array( 'membre' => 'Membre à jour', 'non_membre' => 'Non-membre', 'public' => 'Personne sans compte' ), 'defaut' => 'membre' ) ); $saisies[]= array( 'saisie' => 'input', 'options' => array( 'nom' => 'prenom_inscrit', 'label' => 'Prénom', 'afficher_si' => '@select_type_inscrit@=="public"' ), );
Je souhaiterais n’afficher dans mon formulaire le champ prenom_inscrit que si le champ précédent est égal à ’public’.

Malheureusement, je me retrouve avec une erreur Javascript :
Uncaught SyntaxError : Unexpected token &

On peut effectivement constater que dans le javascript généré on voit cela :
:val()="public")
Les guillemets sont remplacés par leur code html, je ne pense que cela soit normal, et provoque ensuite une erreur ...

Voici le début du code javascript généré
$(function(){chargement=true;verifier_saisies_1944237048 = function(form){if ($(form).find("[name='select_type_inscrit']").val()="public") {$(form).find(".editer_prenom_inscrit").show(400);
Coté html, je vois que mon champ est bien généré :
<div class="editer editer_prenom_inscrit saisie_input" data-afficher_si="@select_type_inscrit@="public""> <label for="champ_prenom_inscrit">Prénom</label> <input type="text" name="prenom_inscrit" class="text" id="champ_prenom_inscrit"> </div>
J’ai essayé de nombreuses syntaxes différentes pour définir la condition mais rien n’y fait...

Merci de vos lumières !
Jul
- Maïeul
  
  Janvier 2019
  SPIP protège automatiquement les guillemets pour les variables passé au chargement du formulaire. D’où le « " ».
  
  Mais tu peux désactiver cela en mettant un _ devant le nom de la variable dans le tableau de retour.
  
  function formulaires_test_charger() { $saisies[]= array( 'saisie' => 'selection', 'options' => array( 'nom' => 'select_type_inscrit', 'label' => 'Type d\'inscrit', 'obligatoire' => 'oui', 'datas' => array( 'membre' => 'Membre à jour', 'non_membre' => 'Non-membre', 'public' => 'Personne sans compte' ), 'defaut' => 'membre' ) ); $saisies[]= array( 'saisie' => 'input', 'options' => array( 'nom' => 'prenom_inscrit', 'label' => 'Prénom', 'afficher_si' => '@select_type_inscrit@==\'public\'' ), ); return array('_saisies' => $saisies); }
  
  et
  
  #GENERER_SAISIES{#ENV{_saisies}}
- JuL BLoBuL
  
  Janvier 2019
  
  Merci Maïeul !
  Une réponse simple et efficace ! Je viens de tester, et cela fonctionne fort bien !
  
  J’avoue que je n’aurais jamais trouvé !
  
  Malgré tout est-ce normal comme comportement vu que c’est obligé d’utilisé les ’ ou ’’ dans la condition de afficher_si ?
  Il n’y a pas mention de cette subtilité dans la doc, est-ce un oubli d’après toi ou c’est moi qui utilise cet outil de manière non-conventionnelle ?
  
  un grand Merci !
- Maïeul
  
  Janvier 2019
  
  En fait :
  - le comportement de protection des attributs relève du comportement de CVT. Et c’est donc documenté dans la doc de CVT : https://www.spip.net/fr_article4151.html
  - la présente doc a été écrite avant que _afficher_si soit implémenté.
  
  Je viens de corriger ici ainsi que dans la doc spécifique à _afficher_si.
- Chourak
  
  Janvier 2019
  J’ai eu le même problème avant cette discussion et je l’avais résolu par :
  
  [(#GENERER_SAISIES{#ENV{saisies}}|html_entity_decode)]
  
  Mais bon je ne sais pas si c’est le mieux :)
- Maïeul
  
  Janvier 2019
  
  bof, c’est pas terrible, car tu pourrais avoir besoin d’entité encodées pour x raison.
- Chourak
  
  Janvier 2019
  
  Bon et bien je vais adopter l’astuce du underscore :)
Répondre à ce message
5

baloo

Janvier 2019

bonjour,
je télécharge saisie depuis cette page
Version 3.8.3
(ZIP – 193.5 ko) SPIP 3.0, SPIP 3.1, SPIP 3.2
quand j’active le plugin il me met dans la page des plugins actif :
Saisies pour formulaires 2.28.0 - stable
Écrire facilement des champs de formulaires
Est ce normal ? quelle est vraiment la version
merci
- Maïeul
  
  Janvier 2019
  
  je suis étonné. La version marqué « saisies_v3 » contient bien la version 3.x de saisies
- baloo
  
  Janvier 2019
  
  Bonjour,
  merci de me répondre., entre temps, pressé par une démo à faire, j’ai posé la question sur la liste et j’ai eu cette réponse de Frank
  « ce qui c’est passé, c’est que au moment de la création de la 3^e branche, il y a eu oubli de faire l’ajout du zip dans l’article puisque ce n’est pas automatique (contrairement à plugin.spip). Je viens de mettre à jour les zips dans l’article de contrib😊 »
  
  Si j’ai bien compris les différentes réponses, il est préférable :
  - En manuel de prendre en priorité sur plugin.spip
  - En automatique suivre la procédure expliqué sur https://www.spip.net/fr_article3396.html
- Maïeul
  
  Janvier 2019
  
  A oui, c’est bien possible (même si normalement c’est censé être automatique, ca bug)
- RastaPopoulos
  
  Janvier 2019
  
  Oui normalement c’est bien automatique (mais pas immédiat) : d’abord ça génère les ZIP, ça se met à jour sur plugins.spip (après déjà un délai) et ensuite un autre robot reporte ces ZIP sur Contrib (deuxième délai).
  
  Je sais pas si des trucs ont pu sauter avec la mise à jour des squelettes de Contrib…
- Maïeul
  
  Janvier 2019
  
  Rasta : c’est surtout que le robot qui met à jour sur contrib le fait de la mnière aléatoire (il prend x plugin au hasard) et pas de manière linéaire...
  
  LA sortie de la version 3 de saisies date de bien avant la nouvelle version de contrib
Répondre à ce message
2
Pierrox

Septembre 2018
Bonjour,
Dans la descriptions des saisies, au niveau des styles de l’espace privé des formulaires, l’option d’avertissement (attention) n’est pas stylisée :

code généré entre « explication » et « la saisie »
<em class="attention">ça pique</em>
Est ce possible d’ajouter les styles de saisie qui vont bien ? (attention = notice ?)
J’oublie peut être quelque chose ?
- Maïeul
  
  Septembre 2018
  
  cela correspond à la norme prévue par SPIP.
  
  https://www.spip.net/fr_article3791.html
  
  si modification il doit y avoir, ce serait au niveau des css de l’espace privé de SPIP pourqu’il prenne en compte cela.
- Pierrox
  
  Octobre 2018
  
  résolu. Merci !
  
  https://core.spip.net/projects/spip/repository/revisions/24102/diff/spip/prive/themes/spip/forms.css.html
Répondre à ce message
2

baloo

Septembre 2018

Bonjour,
j’utilise saisie avec un formulaire yaml.
est-il possible d’avoir un champ <input type=’color’ avec la derniere version de saisie ? si oui comment ?
merci
- RastaPopoulos
  
  Septembre 2018
  
  Ya une saisie « couleur ». Sinon un input avec type=color.
  https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/saisies/trunk/saisies/couleur.html
- baloo
  
  Septembre 2018
  
  merci j’ai activé palette et utilisé la saisie couleurs
  je n’arrive pas à utiliser la saisie mot avec id_groupe j’ai toujours Unable to parse line 197 (id_groupe :’20’) idem avec "2 ou 20
  
  options :
  nom : ’style’
  id_groupe :’20’
  sans le id_groupe cela marche
Répondre à ce message

« Précédent 1 ... 3 4 5 6 7 ... 18 Suivant »

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
- version de SPIP, en bas de la partie privée
- version du plugin testé et des éventuels plugins nécessités
- version de PHP (exec=info en partie privée)
- version de MySQL / SQLite
Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?

Nom [Se connecter]

Courriel (non publié)

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Texte de votre message

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Prévenez-moi de tous les nouveaux commentaires de cette discussion par email

Ajouter un document

Extensions autorisées : gif, jpg, png

Suivre les commentaires : |

Saisies

Introduction

Sommaire

Méthode 1 : déclarer un formulaire CVT complet en PHP

Principe

Mise en œuvre

Déclaration de l’ensemble des saisies

Déclaration d’une saisie individuelle

Déclaration des saisies enfants

Appliquer des vérifications

Support du multilinguisme

Options globales

Options pour le bouton de validation

Options pour la gestion des étapes multiples

Options techniques

Pipeline

Méthode 1a : déclarer un formulaire CVT en PHP, mais effectuer soi-même des vérifications

Méthode 1b avec `#GENERER_SAISIES` : contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies

Méthode 2 : la balise `#SAISIE`

Appendice 1 : chargement des CSS et scripts Javascript sur le site public

Appendice 2 : enregistrer des tableaux

Appendice 3 : la balise `#VOIR_SAISIES`

Appendice 4 : problème avec Xdebug

Discussion

Discussions par date d’activité

Ajouter un commentaire

Saisies

Introduction

Sommaire

Méthode 1 : déclarer un formulaire CVT complet en PHP

Principe

Mise en œuvre

Déclaration de l’ensemble des saisies

Déclaration d’une saisie individuelle

Déclaration des saisies enfants

Appliquer des vérifications

Support du multilinguisme

Options globales

Options pour le bouton de validation

Options pour la gestion des étapes multiples

Options techniques

Pipeline

Méthode 1a : déclarer un formulaire CVT en PHP, mais effectuer soi-même des vérifications

Méthode 1b avec #GENERER_SAISIES : contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies

Méthode 2 : la balise #SAISIE

Appendice 1 : chargement des CSS et scripts Javascript sur le site public

Appendice 2 : enregistrer des tableaux

Appendice 3 : la balise #VOIR_SAISIES

Appendice 4 : problème avec Xdebug

Discussion

Discussions par date d’activité

Ajouter un commentaire

Méthode 1b avec `#GENERER_SAISIES` : contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies

Méthode 2 : la balise `#SAISIE`

Appendice 3 : la balise `#VOIR_SAISIES`