Saisies

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

[2Historiquement, 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

179 discussions

  • 6

    Je cherche l’adresse des archives du plugin... il y a un problème avec la dernière version (1.25.9)

    • Les archives, c’est-à-dire ? Et quel problème ?

    • il y a un bug quand j’active la version 1.25.9 de Saisies (Spip version 2.1.14) avec apparition de cette ligne dans l’espace privé (sur fond blanc) donc sans possibilité d’accès aux autres fonctions :

      Parse error : syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ’}’ in /mnt/149/sdb/f/9/mmhom/theorie/plugins/saisies/balise/saisie.php on line 13

      (je précise que je n’ai que de très peu de connaissances en langage)

    • Ah, ben excuse-moi ! je viens juste de m’apercevoir du post de rcaron du 3 juin qui a le même problème et de ta réponse !!! :(
      une version ancienne de Saisies peut-être conviendrait ????

    • J’ai bien vu vos messages mais je reviens sur la question : quelqu’un possède-t’il une version antérieure à la version fourni plus haut ?

      Mon soucis c’est le fameux syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ’}’ et le vrai problème c’est que l’administrateur du serveur m’a indiqué qu’il ne pouvait pas mettre PHP5 (ils utilisent actuellement PHP4).

      Donc voila, est-ce que quelqu’un aurait une version du plugin compatible avec PHP4 svp ?

    • PHP 4 n’est plus supporté, plus rien n’est corrigé dessus, y compris même pour la sécurité. C’est dangereux de l’utiliser (et ça fait déjà un certain temps). SPIP 3 non plus ne supporte plus PHP 4. On peut essayer de supporter les choses un maximum de temps, mais au bout de plusieurs années, faut souvent passer à autre chose quand même... :)

    • Je suis tout a fait d’accord. Si ça tenait qu’à moi, j’aurai installé PHP5 et hop !
      Mais le fait est que je suis pas le grand manitou du serveur :-/

    Répondre à ce message

  • 2

    Bonjour,

    Erreur à l’installation du plugin Saisie :

    Parse error : syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ’}’ in /.../plugins/auto/saisies/balise/saisie.php on line 13

    Je suis sous SPIP 2.1.10 [17657]

    Merci à vous.

    Robert

    Répondre à ce message

  • 2

    Petit bug
    Je viens de mettre en route le plug via SVP de SPIP 3.0.1 [19436]
    Quand j’ai cliquer sur l’icône de configuration du plug, j’ai eu comme message :

    Page de test des Saisies

    Fatal error : Call to undefined function yaml_decode_file() in C :\Program Files (x86)\EasyPHP-5.3.8.0\www\spip3\plugins\auto\saisies\v1.25.9\inc\saisies_lister.php on line 289

    • C’est pas un bug, en fait c’est pas du tout une page de configuration (d’ailleurs la doc n’en parle absolument pas) mais une page de test du constructeur de formulaire que fournit le plugin (utilisé dans Formidable et Champs Extras 3) et pour celui-ci il faut le plugin YAML et le plugin Vérifier.

    • Ok, donc, c’est normal, sachant que je n’ai pas encore eu besoin d’installer n’y Yaml, n’y Vérifier, n’y Champs Extra n’y même Formidable.

      J’ai vu un bouton, j’ai cliquer dessus pour voir :-D
      Quand j’ai vu que cela sortait un message d’erreur, je me suis dit qu’il fallait faire remonter l’info :-)

      Merci de ta réponse RastaPoloulos

    Répondre à ce message

  • 4

    Bonjour,

    J’utilise le plugin « Formidable » donc « Saisies », et en vérifiant l’accessibilité de mon formulaire, je me suis aperçu de 2 problèmes :

    1) Pour les éléments fieldset, il n’y a pas d’élément legend (voir http://www.rgaa.net/Absence-d-element-fieldset-sans.html)

    Je ne sais pas pourquoi un <h3 class="legend"> est utilisé en lieu et place d’un <legend>, sémantiquement parlant c’est pas top.

    Si c’est une histoire de mise en forme, alors il faudrait déclarer une règle CSS pour l’élément <legend> dans formulaires_constructeur.css pour que ça ressemble à du <h3>.

    J’ai modifié localement les fichiers saisies/saisies/fieldset.html et saisies/saisies-vues/fieldset.html en remplaçant <h3 class="legend"></h3> par <legend></legend> et maintenant je n’ai plus l’erreur d’accessibilité constatée précédemment.

    2) Pour les destinataires du formulaire, il manque un attribut id sur 2 <input> dans saisies/saisies/fieldset.html lignes 14 et 27, ce qui fait que dans le code HTML, la balise <label> pour ces champs n’est pas reliée à la balise <input> correspondante (malgré un attribut for précisé)

    J’ai ajouté id="champ_#ENV{nom}" à côté de l’attribut name et je n’ai plus le problème.

    Y-a-t-il possibilité de committer selon ces remarques afin que tout le monde en profite ?

    • Saisies suit les recommandations de balisage de SPIP 2, décrit notamment ici : http://programmer.spip.org/Separations-par-fieldset

      Il n’est justement pas possible de styler en CSS un fieldset comme une autre balise de type block, ça ne marche sur aucun navigateur. Le sous-titre h3 permet quant à lui de faire vraiment ce qu’on veut. Ça pourra peut-être changer plus tard pour SPIP 3 (les h3 ont été enlevé il me semble), mais pour l’instant ça suit la même manière de faire que SPIP 2.

      Pour le deuxième point, tu as dû te tromper dans le fichier indiqué, parce qu’il n’y a pas d’input dans les fieldsets évidemment. Donc tu parles de quel type de champ ?

    • Ok, pour les recommandations SPIP2, mais il s’agit apparemment d’une suggestion concernant <h3 class="legend"> plus qu’une recommandation... mais la sémantique et l’accessibilité en prennent un coup !

      Les recommandations pour SPIP3 semblent en tenir compte car les <h3 class="legend"> ont bien été enlevées, on a une sémantique et une accessibilité mieux respectée. Cela ne veut pas dire pour autant que si le core de spip n’en tient pas compte, les plugins aussi... On peut tout à fait ne pas suivre la recommandation si l’on sait qu’on peut améliorer les choses, et d’ailleurs « saisies » est compatible SPIP3 il me semble.

      Par contre, on peut styler un fieldset ou legend par CSS, puisque je le fais (firefox 12, Opera 11, chromium 18) : c’est vrai que je n’ai pas testé sur tous les navigateurs, il peut y avoir des problèmes d’affichage/décalages. Je vais voir cela avec IE, google chrome, safari...

      Peut-être que <h3 class="legend"> peut-être doublé d’un <legend> (en affichant ce dernier hors écran par CSS si c’est possible), faut voir ce que ça donne avec un lecteur d’écran et les différents navigateurs, je vais regarder.

       
      En ce qui concerne le point n°2, c’est une erreur d’un copier-coller de ma part, je voulais parler de saisies/saisies/destinataires.html et non de saisies/saisies/fieldset.html

    • Vérification faite sur de nombreux navigateurs (IE version 6 à 9, Firefox, Google chrome, chromium, safari, opera, epiphany...) on peut styler en CSS les éléments fieldset et legend, donc ce n’est pas un problème.

      Il y a juste à remplacer dans la CSS utilisée h3.legend par legend.

      La correction des points n°1(fichiers saisies/saisies/fieldset.html et saisies/saisies-vues/fieldset.html) et n°2 (dans saisies/saisies/destinataires.html) sémantiquement et du point de vue accessibilité, va dans le bon sens.

      Pour le point n°1 et être cohérent avec la modif dans les fichiers saisies/saisies/fieldset.html et saisies/saisies-vues/fieldset.html (en remplaçant <h3 class="legend"></h3> par <legend></legend> ), il faut aussi modifier saisies/css/formulaires_constructeur.html en remplaçant h3.legend par legend.

      A priori, si les utilisateurs du plugin ont une règle CSS personnalisée pour h3.legend, il suffit de renommer h3.legend en legend dans leur règle CSS, ça devrait le faire.

       
      Penses-tu qu’il est possible/utile de commiter les points n°1 et 2 ?

    • Je n’ai jamais dit qu’il n’était pas possible de styler un legend, j’ai dit qu’il était impossible de le styler comme un vrai élément de type « block » (càd tous ceux par défaut, ou tous ceux qui ont un display:block). Il y a un certain nombre de styles qui ne fonctionnent pas avec les légendes.

      Exemple de gens ayant des problèmes, mais il y en a des centaines d’autres en googlant : http://forum.alsacreations.com/topic-4-30259-1.html

    Répondre à ce message

  • 2
    Pneumofoirax

    Bonjour,

    Lors de l’ajout du plugin « Saisies » voici le message d’erreur que j’ai en retour :
    Parse error : syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ’}’ in /mnt/154/sdc/8/c/monsite/plugins/saisies/balise/saisie.php on line 13

    Mon site est hébergé chez free, j’utilise SPIP 2.1.13, j’ai ajouté les plugins Agenda 2.3.0, API de vérification, Champs Extras2 1.10.1, Facteur 1.8.9, Le Couteau Suisse 1.8.62, SPIP Bonux 2.3.0 et YAML 1.5.0

    Merci pour l’ensemble des contributions

    • Et la version de PHP ? 4 je suppose, qui est obsolète et plus supportée. Il faut donc activer le PHP 5 (voir la doc de Free, il doit y avoir un truc à ajouter dans le .htaccess).

    • Pneumofoirax

      C’est tout à fait cela ... j’ai activé php5 et cela fonctionne.
      Merci pour ton aide !

    Répondre à ce message

  • 4
    ceci n’est pas spip

    ATTENTION ca bug...................
    Mise a jour du 4/04/2012


    Longue vie à Spip et ses plugins

    • amateur

      j’ai également eu un petit soucis hier soir
      -  mise a jour du plugins saisies avec le couteau suisse
      -  résultats :
      Parse error : syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ’}’ in /homez.11/marathonh/www/plugins/auto/saisies/balise/saisie.php on line 13

      sur le site public et prive et donc impossible d’intervenir.

      Je m’en suis sorti en remplaçant en ftp le plugin saisies par une ancienne version trouvé sur mon disque dur

      Sarka-SPIP 3.0.4
      SPIP 2.1.12

    • Log de commit :

      Compatibilité PHP 5.4

      / !\ Attention, à partir de cette version 1.25 de saisies, ce plugin nécessite au minimum PHP 5.0 pour fonctionner.

    Répondre à ce message

  • 8

    Bonjour,

    sous Spip 3, en générant des saisies de type radio au moyen d’une boucle (pour simplifier le squelette), les champs générés ne disposent pas de l’attribut name, du coup ils ne sont pas reconnus comme appartenant au même groupe et ne fonctionnent pas.

    Exemple : la saisie oui_non suivante...

    <BOUCLE_saisies(DATA){liste camembert,mimolette}>
    		#SAISIE{oui_non, #VALEUR, label=#VALEUR}
    </BOUCLE_saisies>

    ...génère ce code html :

    <li class="editer editer_camembert saisie_oui_non">
    	<label>camembert</label>
    	<div class="choix">
    		<input type="radio" value="on" class="radio">
    		<label for="champ_camembert_oui">Oui</label>
    	</div>
    	<div class="choix">
    		<input type="radio" value="" checked="checked" class="radio">
    		<label for="champ_camembert_non">Non</label>
    	</div>
    </li>

    Il manque donc le name=camembert dans le <input>

    • Faut croire que la balise #VALEUR de la boucle DATA n’est pas reconnu dans la balise #SAISIE.

      Je ne connais ni la boucle DATA qui est très particulière, ni vraiment la balise #SAISIE que je n’utilise jamais. Je laisse donc marcimat répondre (hahaha le lâche que je fais).

    • marcimat.

      Data applique un traitement sur TOUTES les balises contenues dedans.

      Il faut utiliser #SAISIE*{...}

      Oui, c’est pas pratique !

    • Effectivement, ça marche avec #SAISIE*, merci.
      Je rajouterai ça dans la page ’doc complémentaire des saisies’, ça pourra servir.

      Ah, et cette boucle DATA, une fois qu’on a essayé, on ne peut plus s’en passer !

      Un dernier point tant que j’y suis : les champs de type radio sont contenus chacun dans un <div class='choix'>. C’est dommage, ça empêche d’utiliser Jquery UI (pour transformer les radio en boutons par ex.).

    • Ah mais ça c’est pas Saisies spécialement, ça fait partie de la « norme » HTML/CSS définie pour les formulaires de SPIP à partir de la 2.0. Et Saisies ne fait que suivre ces recommandations. Ça permet d’englober l’input et le label pour les manipuler ensemble (et donc pouvoir faire un choix par ligne notamment). Cf la doc sur http://www.spip.net/fr_article3791.html ou sur Programmer.

    • marcimat.

      Je suis curieux de savoir de quel script UI tu parles @drBouvierLeduc ?
      Il suffirait de mettre une option dans la saisie pour ne pas encadrer de cette div peut être.
      Tu peux aussi l’enlever en jquery par ailleurs :)

      Cependant, comme dit rasta, c’est un choix de SPIP d’encadrer par cette div.

    • Il s’agit du module Jquery UI qui permet de transformer un groupe de champs radios en boutons. Dans certains cas c’est plus ergonomique que des champs radios ’normaux’.
      ex. : $( "#conteneur_radios" ).buttonset();

      S’il est possible d’enlever ces div en jquery avant d’appliquer le .buttonset, ça ma va.

    • Je viens de tester :

      $('li.saisie_checkbox input').unwrap().button(); 

      et ça fonctionne.

      Ça doit être pareil pour radio, mais j’en avais pas dans mon form pour tester.

    • Merci pour l’astuce, ça va bien m’être utile.

    Répondre à ce message

  • 5

    Bonjour à tous,

    J’ai une erreur qui semble être reliée au plugin saisies :

    Erreur : $ is not a function
    Fichier Source : http://monspip.ca/plugins/auto/saisies/javascript/saisies.js
    Ligne : 8

    Il semblerait que c’est quelque chose relié à jQuery. Quelqu’un a une idée qui pourrait m’aider ?

    Merci à l’avance !

    • $() est le raccourci de la fonction jQuery() de base de cette librairie. Donc ça veut à priori dire que jQuery n’est pas chargé au moment où arrive le JS de Saisies. Ce qui n’est absolument pas normal. :)

      Tu as bien jQuery d’inséré par SPIP dans le head des pages ? Il faut toujours avoir #INSERT_HEAD dans les squelettes d’un site, c’est à peu près une obligation.

      Cf. : http://www.spip.net/fr_article4629.html

    • Bonjour RastaPopoulos,

      Après quelques heures de débugging, j’ai trouvé la raison de mon problème.

      J’ai un bout de code javascript qui exécute la ligne suivante dans mon squelette :

      $j = jQuery.noConflict() ;

      Je ne comprends pas exactement pourquoi, mais cela entre en conflit avec ton plugin. Ironiquement, cette fonction sert à éviter les conflits ! Si je comprends bien, il faudrait que chaque bout de code jQuery exécute cette commande au début de leur exécution.

      J’ai donc apporté la modification suivante à saisies.js :

      $s = jQuery.noConflict() ;
      $s(function()
      saisies_fieldset_pliable() ;
      onAjaxLoad(saisies_fieldset_pliable) ;
      ) ;

      function saisies_fieldset_pliable()
      // On cherche les groupes de champs pliables
      $s(’li.fieldset.pliable’)
      .each(function()
      ...

      Maintenant, je n’ai plus de conflit.

      Est-ce quelque chose qui pourrait être inclus dans la version officiel ? Ou y a-t-il un problème avec ce changement ?

      Merci !

    • Ben non ya pas de raison, c’est plutôt une spécificité propre à ton squelette et qui est très rare.

      La fonction noConflict n’a de sens que dans un site où plusieurs librairies différentes utilisent le signe « $ » pour leurs besoins. Ça permet alors de dire à jQuery de ne plus l’utiliser pour laisser la place. Mais c’est donc un cas qui n’arrive quasiment jamais (très peu de sites ont plusieurs grosses librairies en même temps, vu qu’une seule sait déjà à peu près tout faire).

    • Bonjour RastaPopoulos,

      Merci beaucoup pour ta réponse. Je suis finalement allé enlever le « $j = jQuery.noConflict() ; » de mon autre script et remplacer les « $j » par « $ », et maintenant tout fonctionne ! Merci !

      Mon problème maintenant c’est que les CSS de mon squelette entre en conflit avec le CSS du champs de type « date », et le petit calendrier n’est pas tellement beau. Aurais-tu un conseil qui pourrait m’aider ?

      Bonne journée !

    • Que tu utilises des sélecteurs CSS plus restrictifs, sûrement.

    Répondre à ce message

  • 3

    Bonjour,
    J’ai un problème sur un champ date.
    Je voudrais un format de date yyyy-mm-dd mais le date picker me fais du dd/mm/yyyy ???
    Comment je peux faire pour changer le format de date du picker ?
    J’ai essayé cette fonction :

    <?php
    
    function date_picker_to_date($datePicker, $heurePicker = '00:00'){
    
        // $datePicker : jj/mm/yyyy
        if (!$date = recup_date($datePicker . ' ' . $heurePicker . ':00')
        OR !($date = mktime($date[3],$date[4],0,$date[1],$date[2],$date[0]))) {
          // mauvais format de date
          return false;
        }
    
        return date("Y-m-d H:i:s",$date);
    }
    
    ?>

    Mais j’ai un message d’erreur :
    Warning : mktime() expects parameter 4 to be long, string given in I :\wamp\www\pizzinc\squelettes\mes_fonctions.php on line 7

    Cordialement

    • Bon, selon comment tu l’utilises et si tu as les plugins saisies et vérifier à jour, tu peux t’inspirer de ça (c’est pour champs extras, mais c’est pareil) :

      	$champs['spip_articles']['date_creation'] = array(
      		'saisie' => 'date', // Type du champs (voir plugin Saisies)
      		'options' => array(
      			'nom' => 'date_creation', 
      			'label' => _T('grainepc:info_date_creation'), 
      			'sql' => "datetime DEFAULT '0000-00-00 00:00:00' NOT NULL",
      			'defaut' => '',// Valeur par défaut
      		),
      		'verifier' => array(
      			'type' => 'date',
      			'options' => array(
      				'normaliser' => 'datetime',
      			)
      		));

      Ce qui peut donc devenir peut être pour toi :

      D’un côté la saisie :

       array(
      	'saisie' => 'date', // Type du champs (voir plugin Saisies)
      	'options' => array(
      		'nom' => 'date_creation', 
      		'label' => _T('grainepc:info_date_creation'), 
      		'defaut' => '',// Valeur par défaut
      	)

      Et dans la vérification (verifier de ton formulaire) (cf. http://zone.spip.org/trac/spip-zone/browser/_plugins_/champs_extras/core/trunk/cextras_pipelines.php#L201) :

      $verifier = charger_fonction('verifier', 'inc');
      $new_date = null;
      if ($err = $verifier(_request('date_creation'), 'date', array('normaliser' => 'datetime'), $new_date)) {
         // traiter l'erreur $err
      } elseif (!is_null($new_date)) {
         // la date est normalisee en datetime 'yyyy-mm-dd hh:mm:ss'
         // on remplace le request avec notre date.
         set_request('date_creation', $new_date);
      }

      C’est qu’un exemple bien sûr, mais cela peut t’aider.

    • Si tu utilises la fonction formulaires_truc_saisies() pour déclarer tes saisies, alors tu peux n’utiliser que la première partie de ce que te décris Matthieu. Donc déclarer la vérification directement dans la description de la saisie. C’est donc assez simple.

    • Bon en fait Matthieu me dit que non. :) Il manque encore un petit bout pour que la normalisation soit pris en compte automatiquement. Donc pour l’instant faut bien faire la deuxième méthode.

    Répondre à ce message

  • 1

    Bonsoir, Après test du plugin sur mon site mon formulaire contact ne fonctionne plus. Existe-t-il une incompatibilité ? Un utilisateur a-t-il rencontré la même difficulté (Version 2.1.10) ?

    • Mais encore ? Quel rapport entre Saisies et le formulaire de contact ? Précision ? Tant de questions sans réponses...

    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