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.
[
'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.
Discussions par date d’activité
179 discussions
Bonjour,
en utilisant les saisies date
avec html 5 activé, sous opéra les dates soumis ou par défaut ne sont pas reconnu car saisie date transforme la date en « d/m/Y », si j’a bien compris, pourque la date soir bien prise en compte sous html5 il faudrait la mettre en « Y-m-d » du coup ne faudrait-il pas changer
à la ligne 44 de saisies/date.html ?
Répondre à ce message
Pour info, j’ai remarqué que lorsque l’on écrivait :
La valeur n’était pas prise en compte...
Par contre, oui avec
La différence, c’est la virgule après la valeur de valeur...
Je ne sais pas si c’est normal...
C’est pareil pour toutes les balises de type INCLURE en fait. Une difficulté du compilateur.
Merci de l’info RastaPopoulos !
Toujours aussi réactif !
Répondre à ce message
Merci de l’info RastaPopoulos !
Toujours aussi réactif !
Répondre à ce message
Bonjour,
J’ai une erreur squelette. critère inconnu SI ligne 44 (en fait c’est ligne 46)
Je suis sous Spip 2.1.19 [19922] et Sarkaspip 3.1.3 [67461]
J’utilise Fancybox qui fonctionne et qui a besoin de Saisies.
Liste des plugins utilisés sur l’image de l’erreur jointe.
BOUCLE_selection(POUR)tableau #GETdatas>
B_optgroup>
optgroup label=« #CLE »>
BOUCLE_optgroup(POUR)tableau #VALEURsi #VALEUR|is_array>
option value=« #CLE »[(#CLE|==#GETvaleur|oui)selected=« selected »]>#VALEUR
/BOUCLE_optgroup>
/optgroup>
/B_optgroup>
option value=« #CLE »[(#CLE|==#GETvaleur|oui)selected=« selected »]>#VALEUR
//B_optgroup>
/BOUCLE_selection>
j’ai supprimé si #VALEUR|is_array> et je n’ai plus ce problème, mais est-ce la solution ?
BOUCLE_optgroup(POUR)tableau #VALEUR|is_array>
La svn n’est plus bonne en mise à jour automatique.
svn_revision>
text_version>
Dernier commit : 2013-02-14 19:00:06 +0100
/text_version>
commit>2013-02-14 19:00:06 +0100
/svn_revision>
Merci de m’éclairer
Fancybox devrait nécessiter le plugin Itérateurs en SPIP 2.
Saisies fournit un grand nombre de type de champs, dont certains sont très simples et d’autres plus complets et qui nécessitent des dépendances pour pouvoir les utiliser. Comme c’est un outil pour développeur, et qu’on ne peut pas prévoir qui a besoin de quoi : c’est aux plugins qui utilisent Saisies de nécessiter les plugins supplémentaires dont ils auraient besoin. Il faut donc parfois nécessiter YAML, Itérateurs, etc, cela dépend de l’utilisation.
Là pour avoir le critère
{si}
il faut le plugin Itérateurs en SPIP 2. En SPIP 3 tout cela a été intégré au noyau.Merci Rastapopoulos pour cette indication.
Je vais voir pour passer en Spip 3 prudemment et en local avant les grandes manœuvres.
Répondre à ce message
Bonjour,
puis je me permettre 2 suggestions dont j’aimerais avoir votre avis (pertinence et faisabilité) :
- pour les saisies de type sélection : la possibilité que les entrées d’une liste soit les mots d’un groupe de mots clés (ce serait des groupes de mots dédiés à cet usage ... je pense particulièrement à utiliser ça sur le typage des liaisons entre objets, en spip 3, avec l’api éditer liens)
- ce serait intéressant si les champs natifs des objets pouvaient également être configurés par ce plugin (en complément notamment de la formidable « feature » de restriction à des rubriques).
Merci pour ce plugin,
RB
Répondre à ce message
Bonjour,
Je me permets d’attirer votre attention sur un petit défaut de codage : en effet, il est conseillé de grouper les checkboxes et boutons radio dans un fieldset pour que les labels de ceux-ci aient un sens lors d’une lecture avec un lecteur d’écran, et utiliser < legend > pour indiquer à quel sujet ils se rapportent. Voici donc une petite proposition de correctif à apporter au fichier _base.html :
Un tout grand merci !
Répondre à ce message
Bonjour
j’essaie de créeer des formulairse à l’aide du plugin Formidable (je suis sur spipo 3). Lorsque je veux créer mes champs, un message d’anomalie apparait :
Erreur dans les plugins : ecrire/C :\Program Files\EasyPHP-5.3.8.0\www\cite_du_roman/plugins/saisies/saisies_pipelines.php
La première fois j’avais pu accéder à l’écran pour créer des champs et j’avais eu un premier écran d’anomalie m’indiquant qu’il n’y avait pas de squelette pour ce tpe de champ dans /plugins/saisies/saisies/_base.html.
Pourtant le plugin saisies est d"crit comme compatible spip 3
Quelqu’un sait-il où est le problème ?
Merci à vous
rebonjour, voici la copie écran du premier message d’erreur
Il me semble que quelqu’un a déjà rapporté la même erreur, mais je ne vois absolument pas comment ça peut se produire. Version de Saisies ? Version de PHP ? sous Windows ?
En tout cas je n’ai jamais réussi à reproduire.
bonsoir
version de saisies : 1.27.4 (donnée pour compatible spip 3)
version de PHP : PHP 5.3.8 VC9
et je suis sous windows vista
bonsoir
j’ai installé easyphp 12
j’ai désactivé les plugins non liés à formidable mais rien n’y fait
help !
Non mais je comprends même pas comment le nom humain de la saisie peut se retrouver en lieu et place du nom de fichier !
Bonsoir
Ca y est, j’ai trouvé !
J’avais placé mes plugins dans le répertoire /plugins au lieu de /plugins/auto
Maintenant ça va mieux
amitiés
Répondre à ce message
Bonjour,
Je cherche à installer, malheureusement sans succès, le plugin Saisies (V 1.27.2) .
Je suis plutôt débutante.
Pouvez-vous m’aider ?
SPIP 2.1.9
PHP 4.4.7
Le plugin Yaml est installé V 1.5.0
Plugin squelettes : Sarka-SPIP 3.1.3 (mais cela n’a rien à voir il me semble, car s’il est désactivé, mon échec avec Saisies est le même)
A l’activation du plugin saisies, j’obtiens une page blanche, et l’accès à l’administration de spip est fermé. La suppression (ou le simple fait de renommer le répertoire) de Saisies permet la désactivation du plugin et l’accès à l’administration.
Le cache a été plusieurs fois soigneusement vidé (Y compris suppression par FTP du répertoire TMP)
Après avoir renommé le répertoire saisie, et au retour à l’administration de Spip, un certain nombre de fichiers de « saisies » étaient listés comme posant problème. Je n’ai pas pu copier cette liste, malheureusement.
Ce plugin étant nécessaire à l’installation d’autres plugins, je suis bloquée.
Merci pour votre aide et des conseils qui me seront précieux.
Désolée, je n’avais pas lu tous les commentaires plus bas :
S’agirait-il d’un problème lié à php 4 ? (citation : « PHP 4 n’est plus supporté, il te faut PHP 5 (voir la doc de ton hébergement, souvent une ligne dans un .htaccess) »
Y a-t-il un moyen de contourner le problème ?
L’activation de Saisies « en soi » n’est rien censé faire puisque ce n’est qu’un outil, utilisé ensuite par d’autres plugins. Du coup tant qu’on est encore sur l’admin des plugins, rien n’est censé utiliser Saisies normalement.
Cela dit, page blanche n’est pas une erreur, c’est juste la conséquence d’une erreur fatale de PHP, il te faut donc modifier tes paramètres pour l’afficher, sinon on ne peut pas savoir quelle erreur.
Voir cette explication : http://www.spip.net/fr_article4453.html?var_recherche=debuggage#infos_plus pour activer l’affichage des erreurs PHP.
Merci pour votre réponse rapide,
Je vais suivre ce lien, et j’essaierai de vous communiquer ce que j’obtiens, si cela peut être utile à d’autres.
Néanmoins, l’avenir étant à Php5, j’ai fait la demande à notre hébergeur pour cette évolution, ce qui nous permettra aussi de passer à la dernière version de Spip, ce que nous n’avions pas pu faire jusqu’à présent.
Répondre à ce message
Bonjour.
Ce message pour signaler une erreur manifeste dans le
plugin.xml
pour SPIP 2.1 (je n’ai pas vérifié pour les autres) : Saisies fait apple à « Bonus » mais il manque le nécessite... Du coup les listes de sélection et les cases à cocher ne s’affichent pas (des saisies qui appelent la balise(POUR)
...)Merci.
Non c’est normal. Parce qu’il y a plein de saisies qui n’en n’ont absolument pas besoin et donc on a pas à obliger à avoir ce plugin. C’est aux plugins qui utilisent les saisies avec POUR de nécessiter Bonux en même temps. Tout comme c’est aux plugins qui utilisent l’API en tableau de nécessiter YAML en même temps.
Hello. :)
Voici la seule saisie du formulaire :
(le filtre
liste_objets_coordonnees
renvoie un tableau qu’il fabrique en PHP sans utiliser(POUR)
ou quelque fonctionnalité de Bonux...) C’est ce qui (avec le message d’erreur —je joins une capture plus correcte) m’a fait penser que le problème venait de Saisies ; d’autant que (dans une autre page) les sélections (listes déroulantes) ne fonctionnent pas non plus et que la documentation n’explique pas qu’il faut installer Bonux pour les utiliser...Question (surement bête) : comment puis-je ré-écrire la saisie pour ne pas dépendre de Bonux ?
Répondre à ce message
Bonjour,
Tout d’abord un grand merci pour ce plugin. J’ai un petit souci avec le plugin jquerysuperfish (qui a saisies en dépendance) : le formulaire dans la partie admin. ne se valide pas. Sous FF il apparaît une fenêtre js « Veuillez remplir ce champ » qui pointe à l’extérieur du navigateur (!). Peut être un champ hidden qui est considéré comme obligatoire ?
Est-ce que le problème vient du plugin saisies ?
Versions :
spip 3.0.5
jquerysuperfish 0.5.3
Saisies pour formulaires 1.27.0
YAML1.5.0
Re-
Pour compléter, il semblerait que un(des) champ(s) conditionné(s) par afficher_si sont vérifiés alors qu’ils ne devraient pas.
Je suppute le HTML5 d’activé et un champ HTML5 required qui est donc vérifier par le navigateur, pas par SPIP, mais un champ caché en JS car qui ne doit apparaitre que par afficher_si. Enfin je dis ça au hasard vu que je ne connais pas le plugin.
Salut, le code du form de config de jquery superfish est visible ici sur la zone :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/jquery_menu_superfish/formulaires/configurer_jquerysuperfish.php
rat_fou m’a filé un accès à son site pour que j’observe le problème, et l’option Permettre le HTML5 était bien activée dans la conf du site. Je viens de la désactiver, et du coup je peux valider le form de config de superfish sans problème. Il y a donc bien un bug dans saisies si on utilise des saisies conditionnées par afficher_si avec la norme HTML5 activée.
Bravo et merci !
Oui, bravo et merci !
Super boulot b_b !
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 :
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.
Suivre les commentaires : |