Saisies

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

1
2
3
4
5
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 :

  1. ce sont les méthodes les plus anciennes. On trouve encore beaucoup de code les utilisant ;
  2. 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
);
OptionUsageValeur possibleValeur 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 :

  1. elle ne permet pas de profiter des vérifications automatiques ;
  2. 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 :

  1. le tableau de description des saisies (au même format que pour #GENERER_SAISIES)
  2. 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

[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
Filtrer

179 discussions

  • 3
    dudule

    Merci pour ce plugin que j’essaye maladroitement de m’approprier. Pour continuer à avancer, j’ai deux questions :

    1. Dans la partie « Traiter » du CVT il faut indiquer comment alimenter soit une adresse email soit une base de données avec les résultats du formulaire. Ceci est décrit dans l’article « Un formulaire C.V.T avec Saisies par l’exemple » de manière succincte par « . . . » et là ... je coince ! Comment faire donc pour ajouter les résultats du formulaire à la base de donnée ?

    2. De plus, je souhaite enrichir le formulaire d’inscription avec des informations complémentaires. Est-il préférable de refaire un formulaire d’inscription « from scratch » entièrement avec saisie ou alors d’ajouter des #SAISIES dans le formulaire d’origine et dans ce dernier cas comment procéder ?

    Merci pour vos réponses

    • RastaPopoulos

      Ces deux points n’ont rien à voir avec ce plugin en fait. Ce dernier n’est là que pour aider à générer les champs (et éventuellement la validation avec le plugin Vérifier). Pour le traitement il faut apprendre l’API CVT, l’API de la base SQL ou l’API d’édition des objets éditoriaux. Pour l’inscription pareil, il faut apprendre ces mêmes points + savoir s’insérer dans les points d’entrées de SPIP pour s’insérer aux bons endroits du formulaire en question afin de le modifier. Bref, ya du boulot ! :D

    • dudule

      Merci RastaPopoulos, et bien maintenant je sais quoi faire comme devoirs de vacances ;)

    • RastaPopoulos

      Pour l’inscription tu as un exemple dans le plugin « clients » (sur la zone en svn uniquement) qui utilise des champs de « Contacts et Organisations » et « Coordonnées » pour ajouter des infos à l’utilisateur inscrit. Mais après suivant le besoin ça peut être dans des champs extras ou n’importe où ailleurs.

      http://zone.spip.org/trac/spip-zone/browser/_plugins_/clients

    Répondre à ce message

  • 1
    robomatix

    Bonjour,

    J’aimerais me servir du champ Date pour saisir une date de naissance sur les auteurs. Hors les années proposées commencent en 2003... J’aimerais les faire commencer en 1970, c’est un site pour jeunes...
    Ma question est simple : Comment faire !

    Merci d’avance de votre aide.

    • robomatix

      Voici ce que j’ai fait :
      -  mis une copie du fichier prive/formulaires/dateur/inc-dateur.html dans squelettes/formulaires/dateur/inc-dateur.html
      -  Ajouté à la suite de la ligne changeYear : true, ( Ligne 31 ) àla ligne 32 donc : yearRange : ’c-30:c+10’,
      -  Mis en ligne
      -  Vider le cache
      Et hop, sur mon formulaire, les années vont de 1983 à 2023 ! C’est donc ok !
      J’affinerais l’année de départ après en avoir parlé aux autres...

      Merci à denisb sur spip-liste pour l’aide !

    Répondre à ce message

  • 9
    bruno31

    Un bug dans la valeur par défaut

    Ceci concerne la saisie de type « selection ». La valeur par défaut est bien prise en compte dans l’édition du champs extra (exec=champs_extras_edit) mais pas dans l’objet édité.

    Exemple : j’ai ajouté une sélection « Modification du logo »
    dont la liste des choix possible est :
    |Afficher le LOGO tel que (sans cercle)
    1|Le LOGO est affiché dans un CERCLE

    et la valeur par défaut : 1

    Dans la fenêtre d’édition des champs extra, me montrant le résultat, j’ai bien le choix « Le LOGO est affiché dans un CERCLE » qui est sélectionné

    Mais quand je créé un nouvel article, c’est l’autre choix « Afficher le LOGO tel que (sans cercle) » qui est sélectionné par défaut.

    En regardant de plus près le code de selection.html, je vois que problème tourne autour de l’initialisation de « valeur » :

    #SET{valeur,#ENV{valeur_forcee}|is_null|?{#ENV{valeur}|is_null|?{#ENV{defaut},#ENV{valeur}},#ENV{valeur_forcee}}}

    et j’ai mis en évidence que le test #ENVvaleur|is_null ne donne pas le même résultat selon que l’on est dans la page de définition du champs extra ou dans la page d’édition de l’article.

    C’est bien gênant car on ne peut pas mettre de valeur par défaut dans la liste déroulante.

    • RastaPopoulos

      Ça vient de là :
      http://zone.spip.org/trac/spip-zone/changeset/55439/_plugins_/saisies/saisies/selection.html

      Le problème c’est que dans un CVT, la valeur « null » n’existe jamais en fait...

      Cela dit, dans ton exemple précis, ton tableau de clé|valeur ne veut rien dire puisqu’un tableau avec un clé vide ça n’existe pas (si c’est vide PHP met au moins un numéro comme clé, à priori « 0 » là, je sais pas...). Donc de toute façon ya aussi un truc qui cloche.

      Quand on veut la première valeur vide mais avec un label, c’est l’option « option_intro » qu’il faut remplir (et quand on veut pas de première option vide, on doit utiliser « cacher_option_intro ».

    • bruno31

      Merci Rastapopoulos

      Alors dans la liste des choix possibles, j’ai mis :
      0|Afficher le LOGO tel que (sans cercle)
      1|Le LOGO est affiché dans un CERCLE

      Cela ne change rien. La valeur par défaut reste « Afficher le LOGO tel que (sans cercle) ».

      C’est bizarre que cela ne fonctionne pas pareil dans la prévisu du champs extra et dans la boite d’édition de l’article ?

    • RastaPopoulos

      Joseph dit que ça corrige le commit http://zone.spip.org/trac/spip-zone/changeset/54867/_plugins_/saisies
      qui justement avait été fait pour enlever le is_null afin que la valeur par défaut fonctionne.

      À mon avis faut enlever tous ces is_null car pour l’instant ça n’existe pas dans CVT (ce qui provoque les mêmes bugs pour « oui_non » et « case » d’ailleurs, insoluble pour l’instant).

    • bruno31

      La modif a été commitée en 2011 mais pourquoi elle n’est toujours pas intégrée dans la dernière version de SAISIES ?

      C’est juste une question pour comprendre, c’est pas de l’ironie.

    • RastaPopoulos

      Quelle modif ? Tout a été commité. D’abord l’enlevage de is_null par Sylvain puis la remise par Joseph. is_null / pas is_null / is_null.

    • bruno31

      Donc pour résumer :

      -  le bug a été corrigé une 1re fois par Sylvain, pour que cela fonctionne avec les CVT
      -  puis le bug a été ré-introduit suite à une modif de Joseph pour que le défaut fonctionne avec les autres types de formulaire.
      -  Aujourd’hui, la valeur par défaut n’est pas prise en compte dans les formulaires CVT pour les saisies de type : selection oui_non, case

      Peux-tu me confirmer Rastapopoulos ?

    • RastaPopoulos

      À priori oui, dès qu’il y a « is_null » je ne vois pas comment ça pourrait marcher avec CVT car cette API renvoie au maximum une chaîne vide mais jamais null.

    • bruno31

      Mais si on enlève le is_null, qui/quoi pénalise t’on ?

      Comment peut-on faire pour corriger le bug pour toutes les situations ?

    • RastaPopoulos

      Ben on pénalise dans le sens où on modifie l’existant, donc faut vérifier que ça casse rien potentiellement chez les gens. Ça peut au moins être modifié pour selection mais peut-être faut il en parler sur SPIP Zone avec Joseph puisque c’est lui qui a remis le is_null plus tard. Donc faudrait lui dire que ça ne peut marcher avec CVT, et lui demander pour quelle utilisation lui l’avait remis, à quoi ça lui sert à lui.

      Pour les oui_non et case, là on peut rien faire pour l’instant, car tout le monde utilise la valeur « chaîne vide » (« ») pour signifier « non », or CVT remplace le _null_ par «  » dans le charger(), et du coup dans tous les cas ça sera jamais is_null donc ça prendra jamais ce qu’on met dans « defaut ».

    Répondre à ce message

  • manu0101

    Le plugin saisies 1.30.4 me fait une erreur Javascript : « $ is not a function ».
    Ce se corrige en emplçant $ par jQuery dans saisies_fieldset_pliable() :

    --- javascript/saisies.js.orig
+++ javascript/saisies.js
@@ -6,5 +6,5 @@
 function saisies_fieldset_pliable(){
        // On cherche les groupes de champs pliables
-       $('li.fieldset.pliable')
+       jQuery('li.fieldset.pliable')
                .each(function(){
                        var li = $(this);

    Répondre à ce message

  • 1
    LoGo

    Bonjour à tous !

    Jusqu’à présent tout marchait bien avec ce plugin, mais depuis 2 jours, 2/3 fois, quand un visiteur accede à la page d’insription de mon site, ce message d’erreur apparait.

    Fatal error : Call to undefined function propre() in /home/producso/public_html/plugins/auto/inscription3/v3.2.8/inscription3_pipelines.php on line 758

    Et aucune idée de comment je peux rétablir la chose.

    Environnement :

    Sarka-SPIP 3.2.28 [71314]
    SPIP 3.0.7 [20352]
    PHP 5.3.23

    Entre autres :
    Inscription 3 (3.2.8)
    OpenID 1.1.14
    Saisies pour formulaire 1.31.0
    Champs Extras 3.2.4

    Merci d’avance !

    • RastaPopoulos

      Très bien, mais quel rapport avec Saisies alors que tu parles d’un message d’erreur dans Inscription3 dans ton message ?

    Répondre à ce message

  • 1
    mbourlier

    Bonjour,
    Mon site est motorisé par SPIP 2.1.20, habillage Sarka-Spip 3.1.0 Dev avec entre autres plugins « Le couteau Suisse ».
    Depuis quelques jours, il est question dans la lame « Mises à jour automatiques » d"une révision N°72107 pour le plugin « Saisies pour formulaires ». Mais à chaque tentative de mise à jour, c’est la N°72098 qui est téléchargée. Or, j’ai vu que cette révision n’est pas fantôme puisqu’elle apparaît sur spip-zone ! D’autres rencontrent-ils ce souci ?

    Cordialement
    M. BOURLIER

    Découvrir l’autre, l’ailleurs, soi

    • mbourlier

      Bonjour,
      Le message d’Eric ci-dessus vient répondre à mon souci et la toute dernière mise à jour du 22/04/13 rev N° 72234 l’a résolu. C’était donc le SVN qui n’était pas bon.
      Merci Eric
      Cordialement
      M. BOURLIER

    Répondre à ce message

  • Kingrise

    Attention, le SVN n’est pas correct pour la dernière mise-à-jour : rev 72107 à écrire au lieu de 72098... Merci

    Répondre à ce message

  • 1
    Rainer Müller

    Bonjour,

    une petite question au sujet de la génération auto d’un cvt avec formulaires_truc_saisies_dist

    J’aimerai surcharger cette fonction via un plugin afin d’intervenir sur la composition du formulaire généré.

    J’ai donc formulaires_inscription_client_saisies_dist dans le fichier formulaires/inscription_client.php

    Normalement je surchargerai la fonction dans le fichier fonctions de mon plugin en la nommant formulaires_inscription_client_saisies
    mais ça ne fonctionne pas.

    J’ai également essayé de mettre la fonction dans formulaires/inscription_client/saisies.php, aucune surcharge.

    Comment je peux surcharger cette fonction ?

    Merci

    Rainer

    Répondre à ce message

  • 9
    Someoneinthe

    une petite suggestion pour que le plugin soit VRAIMENT parfait :
    -  ajouter la possibilité de mettre des placeholder sur tous les champs
    -  Laisser la possibilité de choisir de mettre les messages d’erreurs avant ou après le champ

    a part ca, le plugin est genial !

    • RastaPopoulos

      Oui pour les placeholder, bonne idée. Pour les erreurs, en fait en accessibilité le chantier (y compris dans les forms du noyau de SPIP) ça sera sûrement de les placer (au niveau HTML) dans le label, car à priori c’est là qu’ils sont le mieux d’après les discussions à ce sujet (cf la liste spip-dev). Ensuite il faut voir en CSS comme ce sera facile ou pas de les placer visuellement où on veut.

    • someoneinthe

      pour le perfectionnement, on pourrait rajouter aussi une verif JS avec des regex sur des pattern.
      mais bon, la, c’est vraiment TRÈS poussé (et pas beaucoup utilisé, mais très pratique pour orientation html5).

      merci pour tout ce travail ;-)

    • RastaPopoulos

      Le plugin Vérifier permet déjà cela.

    • someoneinthe

      oui, mais pas en live au blur du champ !

    • gilcot

      Je pense qu’il faudrait garder les choses simples (comme elles le sont déjà) et juste permettre à ceux qui veulent d’ajouter des attributs supplémentaires (si ça se trouve c’est déjà le cas mais pas documenté). Parce-que n’oublions pas qu’il y en a qui veulent que leur page valide et il y a ceux qui font HTML5 et ceux qui font HTML4... et encore ceux qui font XHTML...

    • someoneinthe

      absolument !
      je pensais a toutes ces potentielles améliorations comme des arguments facultatifs, et non comme des éléments obligatoires !
      j’imaginais l’intégrer de la manière suivante :
      [(#SAISIEinput,nom,obligatoire=oui,info_obligatoire=*,label=xxx,type=text,PATTERN=XXX,PLACEHOLDER=XXX)]

      comme ça, si pas renseigné, pas implémenté, et tout le monde est content ;-)

    • gilcot

      Je viens de regarder le fichier saisies/input.html du plugin, et c’est ce que je soupçonnais déjà

      (si ça se trouve c’est déjà le cas mais pas documenté).

      En effet, si dans la #SAISIE on ajoute placeholder=... c’est pris en compte  ;-) Et pour le reste je vois qu’il est prévu de pouvoir mettre attributs=la liste qu’on veut (mais j’ai pas essayé et je pense que ça doit être —à vu d’oeil— un peu casse-couilles si ce n’est pas un tableau de paires « nom_d_attribut,valeur_d_attribut »...) Faut tester donc patern=motif et nous faire des retours qu’on complète le wiki-like... :-)

    • someoneinthe

      c’est ce que j’avais essayé spontanément, mais ca marchait pas.!

      ceci dit j’ai pas verifié sur quelle version je tournais...

    • gilcot

      J’ai vérifié sur les fichiers de la 1.27.1 que j’ai encore en local. Mais j’ai pas essayé : si ça marche pas, c’est qu’il y a un bug à corriger quelque part ou qu’il faudrait que ce soit retiré (après tout si c’est pas documenté c’est parce-que la fonctionnalité n’est pas officiellement supportée... si ça marchait ce serait un cadeau genre oeuf de pâque...)

    Répondre à ce message

  • 1
    ericm

    bonjour,
    je suis sous spip 2.1.20, chez FREE. Pour installer la gestion multilangues, il faut le plugin TRADRUB et pour celui-ci il faut le plugin SAISIES en version 1.6.6 ou supérieure.
    Lorsque j’installe le plugin SAISIES dans sa version 1.30.0, j’ai l’erreur suivante :
    « Parse error : syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ’}’ in /mnt/113/sdb/d/e/rainerschluter/sculptor/plugins/saisies/balise/saisie.php on line 13 »
    Merci de m’indiquer où trouver une version plus ancienne.

    • RastaPopoulos

      Il faut activer PHP 5 (voir la doc de l’hébergeur). De toute façon, il faut absolument activer PHP 5 (la version 4 n’est plus supportée depuis plusieurs années déjà, pas même pour les trous de sécurité).

    Répondre à ce message

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 ?
[Se connecter]

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

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.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom