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>.htmlla 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,
J’ai une erreur avec ce plugin en version 4.8.0 sur mon site en SPIP 4.1.7 :
1 erreur dans le squelette : aucun squelettes saisies/fichiers n’est disponible... plugins/auto/saisies/saisies/_base.html
Merci de bien m’indiquer une solution.
Ce n’est pas le plugion qui pose problème. Simplement tu as du desactiver par megarde le plugin cvt upload, qui fournit la saisies « fichiers » en question.
Répondre à ce message
Bonjour
Pour une saisie
inputdéclarée avec la balise#SAISIEet dont on veut qu’elle ne saisisse qu’un entier, est-ce qu’on peut utiliser ’verifier’ ? et avec quelle formalisme alors ?C’est marqué dans la doc, c’est incompatible dans les termes mêmes. #SAISIE c’est juste dans un squelette, donc pour générer un morceau de HTML, c’est juste un #INCLURE.
Alors que Vérifier c’est en PHP côté serveur, dans l’API CVT.
Ah OK. Merci j’oubliais.
https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies/input.html#L28
L’option « type »
J’avais cherché la doc de
typeet pas pigé : la doc principale de type semble être là : Référence des saisies mais ça indiqueTexte masqué lors de la saisie (ex : mot de passe) — Texte masqué lors de la saisie (ex : mot de passe) (type). Le redoublement indique qu’il y a un problème dans la génération de la doc, mais même sans redoublement je pige mal que « type » soit réservé aux textes cachés. Quelque chose m’échappe ?Alors
- oui il y a sans doute un bug dans la génération de la doc
- par ailleurs la doc est génére automatiquement à partir des fichier .yaml qui servent aux constructeur de formulaire (type « champ extra interface » ou « formidable »), et dans les constructeurs on ne propose pour l’heure que mot de passe -> on pourrait imaginer d’étendre -> je me demande du reste s’il n’y a pas un tickets à ce sujet.
Cela étant sur le fond, j’ai tendance à penser que tu devrais utiliser l’API de saisie complète pour avoir aussi une vérification en PHP, et pas uniquement coté client.
Répondre à ce message
Bonjour,
Il y a eu une évolution entre la version 3 et 4 au niveau des balises englobantes d’une saisie.
Pour la version 4, dans le fichier « saisies/_base.html » il y a la notion de saisies autonomes, qui de fait n’encapsulent pas du tout la saisie, ce qui peut être pratique, sinon les conteneurs par défaut sont sur « div » et « label ».
Cependant, si la saisie fait partie de la liste
#LISTE{oui_non,radio,checkbox,case,choix_grille}alors les conteneurs deviennent « fieldset » et « legend ».Ne serait-il pas possible de rendre cette liste paramétrable dans mes_options.php afin de simplifier la surcharge ?
Alors le choix de cette liste est pour des questions d’accessibilitsé, et c’est du reste la norme que suit également SPIP sans saisies désormais.
DOnc il ne me semble pas judicieux de permettre de revenir en arrière.
Pour un nouveau site, effectivement, cela n’est pas nécessaire, mais un site utilisant Saisies 3 qui passe sur la version 4 doit reprendre toutes les CSS des formulaires utilisant ces éléments, cela peut être assez fastidieux.
Merci pour le retour, c’est noté.
oui, je comprend, mais ce n’est précisement pas pour rien qu’on a eu un changement de x lorsque ce choix a été fait.
Répondre à ce message
Bonjour,
Un bug du plugin ChampExtra (Interface) semble venir d’un bug du plugin Saisies.
Donc je pose ça là :
https://discuter.spip.net/t/supprimer-la-validation-dun-champ-extra/167981
Merci
J’ai répondu. Ce n’est pas un bug du plugin. C’est plus un bug d’ergonomie des nav.
Répondre à ce message
Bonsoir,
En Espace privé, la configuration du plugin propose de cocher l’option « Charger le javascript et les CSS sur toutes les pages, dans la balise head »
Qu’est-ce que cette option apporte par rapport au fonctionnement de base ?
Merci d’avance,
Cordialement,
Hervé
Si tu as beaucoup de formulaire coté publique, cocher cette case permettra d’optimiser les performances. Sinon, ca alourdit pour rien.
Merci Maïleul d’avoir répondu aussi vite et aussi clairement
Répondre à ce message
Bonjour
Demande d’amélioration : quand on utilise la saisie « couleur », ce serait bien qu’on ait une option "transparent" .
tu sais les demande d’amélioration c’est comme les rapports de bug : le mieux est d’ouvrir un ticket pour éviter que l’on perde les infos.
OK je le ferai la prochaine fois
Répondre à ce message
Bonjour
Suite à la mise à jour d’un site en spip 4.2, j’ai un petit souci.
J’ai ce type de saisie dans des formulaires de configuration
Le résultat affiché est
<:escal:documentation:>c’est à dire que la chaîne de langue n’est pas interprétée. Pareil pour celle du title du lien. Je n’ai pas ce souci avec spip 4.1.7Le fichier complet est ici
Il aurait été préférable d’ouvrir un ticket. Je regarde.
OK je le note.
Répondre à ce message
Bonjour,
soit SPIP 4.2.0 + Escal 4.5.81
avec SPIP Bonux 4.1.1 + Saisies pour formulaires 4.7.0
je rencontre un pb avec les messages suivant :
Comment y remedier ?
merci
ps/ la ligne 91 de spip bonux
Bah deja en rapportant les bugs sur git.spip.net et pas ici.
Et ensuite en voyant qu’il s’agit un peu près du même bug, a priori, que précedemment cité par Jean Christophe. Je regarde.
Répondre à ce message
bonjour,
j’utilise SAISIE avec la norme de déclaration en PHP.
cela fonctionne bien mais je voudrais ajouter un bouton supprimer au formulaire je ne vois pas comment . ?
merci
C’est précisément l’objet de ce ticket :)
https://git.spip.net/spip-contrib-extensions/saisies/issues/251
Répondre à ce message
Bonjour
Dans mon plugin, j’ai un formulaire avec ce code
Si je coche « oui » pour « fondtransparent », que je valide puis que je coche « non », la couleur affichée par « couleurpage » est toujours #000000, quelque soit la couleur enregistrée auparavant.
Une idée du souci ?
#fffffftu veux dire ? Dans tous les cas c’est bizarre car normalement si t’a condition n’est pas remplie, alors le champ conditionné est vidé, sauf siafficher_si_avec_postest activé au niveau global du formulaire.Mais si tu tu nous donnais le code / le plugin complet on pourrait y voir plus clair.
non non, c’est bien #000000 (noir) qui s’affiche.
Le fichier complet est là
https://git.spip.net/spip-contrib-squelettes/escal/src/branch/master/formulaires/configurer_escal_fonds.php
Le code cité est à la ligne 155 et suivantes
ça fonctionne mieux en rajoutant un
Merci pour la piste
Bon bah tant mieux. Mais oui par défaut, si tu ne poste pas un truc parce que la condition n’est pas rempli, alors on reprendre la valeur par défaut (et ca me parait logique...)
Sauf que là, ce n’était même pas la valeur par défaut !
Mais qu’entendu tu par « la couleur affiché ». Dans le formulaire ? Mais si la saisie est masquée, comment la voie tu ?
Oui, la couleur affichée dans le formulaire et donc ensuite dans l’espace public si on ne fait pas attention et qu’on enregistre.
je soupconne plus un bug sur le réglage de la valeur par défaut. Bon je laisse comme cela, mais à l’occasion je creuserai.
Répondre à ce message
Bonjour
Petite demande d’amélioration : quand on utilise la saisie « couleur », une fois la couleur choisie, j’ce serait bien, à mon avis, que le code hexa de la couleur soit affiché.
Merci.
Répondre à ce message
Bonjour à tous,
Je viens de faire la mise à jour du plugin et j’ai une message omni présente :
« Aucun squelette formulaires/inc-saisies-cvt-boutons-cda n’est disponible... plugins/auto/formidable/v5.2.3/formulaires/inc-formidable-boutons.html »
Je suis passé de 4.5.1 à 4.6.0 et ne comprends pas ? Ce fichier n’est pas présent dans le plugin formidable ?
Merci de votre aide !
Hum, j’ai la même version et aucun problème. Par contre ton message m’intrique
formulaires/inc-saisies-cvt-boutons-cdaca n’est appelé nul part dans formidable, ce qui existe c’estformulaires/inc-saisies-cvt-boutons. On dirait que ta version de formidable est incorrecte / mal récupéré. Tente peut être de désactiver le plugin, puis le supprimer (ATTENTION : pas de desinstallation) puis le remettre en place.Bonsoir !
Merci pour a réponse, mais cette mannip n’a pas focntionné. J’ai sauvertagrdé, desintallé et réinstaller les plugin avec la verion récente, bug se reproduit. J’ai refais ce processus en réintégrant la version précédente et tout fonctionne.
MAIS oui, il y a un soucis avec le #NOM_DU_SITE dans lequel j’ai mis un
<br>et je vois que j’ai petitb triangle jaune dans l’onglet de page web et un drole de titre… Cela sera lié ?Lorsque je vire la ballise l’onglet retrouve une apparence presque normale, le nom du site apparait entre crochet…
hUm, je teste. Mais attention c’est
<br />pas</br>mouais, non je ne reproduis pas, meme avec ca.
Est-ce que vous pourriez m’envoyer en mp une identifant admin pour le site (monprenomsanstrema@monprenomsanstrema.net)
C’est fait… lien envoyé ;-) Pfff merci pour le
…
rien recu :(
Et donc comme expliqué par email : fausse alerte, ton site surcharge brutalement le code de formidable et de saisies, ce qui explique la rupture à la mise à jour.
Répondre à ce message
Bonjour,
Je souhaite utiliser formidable et le formulaire de participation pour que les membres de notre association puissent s’inscrire en famille.
Il sont connectés au moment de l’inscription, hors sur le formulaire le mail est obligatoire, donc il doivent ressaisir leur adresse mail.
J’ai ouvert un ticket sur formidable, mais la réponse a été que l’on ne peut pas charger un formulaire en l’appelant dans un article et un de ceux qui m’ont répondus ma écrit ceci : "On pourrait envisager d’ajouter pour la saisie « email » une option pour préremplir avec l’email de la session courante -> ouvre un ticket sur le plugin saisies. A mon avis c’est le plus perenne"
Alors question, es-ce possible et si oui comment ?
Sachant que je suis un webmestre lambda et que je me suis jamais lancé dans la programmation Spip.
Merci par avance de toutes les infos que vous pourrez me donner,
André
Oui c’est possible, faut juste que je trouve le temps de faire cela (sans doute pas avant longtemps, d’autant que ce n’est clairement pas ma priorité).
Pour que l’information ne soit pas perdues, peut tu :
1. Te créer un compte sur git.spip.net en suivant le lien « s’inscrire pour contribuer »
2. Lorsque ton compte sera créé, te rendre sur https://git.spip.net/spip-contrib-extensions/saisies/issues et créer ton ticket ?
Bonjour,
Je pense laisser tomber l’utilisation de formidable, je voulais l’utiliser pour ne pas utiliser réservation et réservations multiples qui me paraissait une usine juste pour enregistrer des réservations sans notion commerciale.
Mais devant les difficultés, les délais, etc.
Je vais utiliser réservation !
Merci de tes réponses.
Au fait j’ai eu un soucis avec le mot de passe sur git et malgré plusieurs demande je n’ai jamais reçu le mail de réinitialisation.
Pb lié à mon compte ? ou plus général ?
André
Bah je vois pas les difficultés en fait. Tu demande juste une petite fonction supplémentaire. Mais enfin tu fais ce que tu veux.
Aucune idée pour git.spip.net. Je transmet le message à la personne qui s’en occupe.
Répondre à ce message
Avec SPIP 4.1.5 et tous les plugins à jour, le champ extra sélecteur d’article ne marche plus (alors que sélecteur article ou rubrique marche bien) (on peut bien sélectionner des articles, mais ils ne sont pas visibles dans la fiche article après enregistrement de l’article) : spip enregistre dans la base articles|25 et non article|25.
Si, via phpmyadmin on supprime le S, alors tout marche bien.
Je ne sais pas trop qui gère ce libellé : saisie ? Bonux ? Iextra ?
Une idée de l’origine de ce s intempestif ?
Merci de votre aide.
Julien
Merci de pas poster la même question en différents endroits, ça multiplie le travail pour te répondre ... et d’autres personnes intéressées par le même sujet n’auront que des petits bouts de l’ensemble des réponses.
En l’occurrence la réponse a été fait là : Bonux pour SPIP3
Répondre à ce message
Je viens de mettre à jour ce plugin vers 4.5.0 sur 2 sites en SPIP 4.1.5 sur 2 serveurs différents
et depuis impossible modifier les sites référencés :
Page blanche sur / ?exec=site_edit
dans distant.log je vois :
IP adresse IPV6 108151 Privé erreur Erreur connexion 0mais je ne sais pas si c’est lié.
Merci
Bonjour,
Pareil pour moi, voici l’erreur affichée :
Mais pourquoi vous mettez ça là, quel rapport avec Saisies pour le moment ? Le plugins-dist « Sites syndiqués » n’utilise évidemment pas Saisies et l’erreur collée indique très clairement un fichier *du noyau* ecrire/inc/editer.php:226
Bon bé si ya peut-être bien un problème plus profond, dû à un appel aux fonctions charger() de *tous* les formulaires (même ceux qui n’ont pas de saisies déclarées) à un moment où ya des choses pas chargées… c’est à la fois dû à une nouvelle inclusion de Saisies ET à un mauvais code du noyau qui n’inclue pas le bon fichier pour être sûr avant d’utiliser une fonction qui est ailleurs.
Et donc à priori depuis cette PR fusionnée récemment : https://git.spip.net/spip-contrib-extensions/saisies/pulls/215#issuecomment-41545
Et donc v4.5.1/v3.56.4 corrigent cela
Oui merci Maïeul, la nouvelle version élimine le problème pour moi.
Répondre à ce message
La mise à jour du plugin saisie vers sa version 3.56.3 empeche la modification des articles dans spip 3.2.16.
Même problème que le fil précédent https://git.spip.net/spip-contrib-extensions/saisies/pulls/215#issuecomment-41545
merci pour votre rapidité. Ca ne fonctionne pas. Je dois avoir fait une mauvaise manip.
Euh j’ai juste mis le même lien que dans le fil de com précédent où ça explique d’où vient le problème en disant que vous parlez les deux du même problème. Ya aucune manip à faire, c’est juste une explication de la source du problème.
Bonjour,
si on remet l’ancienne version du plugin ça pose pb ?
Non, hormis la perte de quelques bugfix très spécifiques. Mais on va generer dans la journée une version corrigé.
merci bcp !
Et donc v4.5.1/v3.56.4 corrigent cela
Répondre à ce message
Bonjour
je viens d’installer SPIP 4.1.2 avec le plugin Escal 4.5.52, saisies 4.4.1 j’utilise wampserver 3.2.6 avec php 7.4.26, mySQL 5.7.36
et lorsque je vais dans la config du plugin Escal (dans tous les items mise en page, éléments, page d’accueil,...) j’ai le message ci dessous :
Warning : array_merge() : Expected parameter 2 to be an array, null given in C :\Site\wamp64\www[mon site]\plugins\auto{saisies\v4.4.1\inc\saisies_lister_disponibles.php on line 45
Avez vous une idée pour supprimer ce warning ?
Merci
bonne journée
1. Deja normalement les warnings ne devraient pas apparaitre publiquement -> il faut configurer ton hebergement pour éviter cela.
2. Dans tous les cas, active le plugin YAML, ca évitera de les déclencher (et je vais de ce pas signaler cela au contributeur d’Escal).
Bonjour,
Pour info je rencontre le même souci sur un site en 4.1.5.
Le squelette n’est pas ESCAL mais Html5up Phantom.
La version de PHP est la 8.1.0.
Le message apparaît sur les pages de modifications des articles ou des pages (plugin Pages uniques).
L’installation du plugin Yaml a fait disparaître le message.
Pour info, on me signale le même souci sur un site avec Escal et php 8.1.
De mon côté je n’ai aucun souci avec php 7.4.28 ou 7.4.30 sur plusieurs sites.
Comme expliqué, il faut que YAML soit installé pour que la declaration de formulaire en full PHP marche. Du coup il faudrait qu’Escal le marque en « necessite » dans son paquet.xml et ce sera bon.
Comme Escal utilise saisies, je vais le faire mais à mon avis, ce serait plutôt à Saisies de le faire non ?
D’autant qu’avec php 7.4, même sans yaml, je n’ai pas de souci.
Non puisque Saisies peut parfaitement être utilisé sans PHP uniquement en squelette, donc sans YAML, donc ya pas à obliger YAML pour ceux qui n’utilisent pas l’API PHP. Donc c’est à ceux qui utilisent l’API PHP de nécessiter YAML.
Je vois pas ce qu’il y a de bizarre à ce que ça marche avant et pas après : tout l’objet de PHP 8 est justement de passer à un truc mille fois plus strict sur toutes les erreurs, donc ya plein de choses qui étaient juste des notices ou des warnings et qui maintenant génèrent des erreurs bloquantes.
Répondre à ce message
Je crois qu’il y a une coquille là :
C’est < 4.3.0 plutôt
Effectivement. Corrigé. Merci !
Répondre à ce message
Testé en spip 4.1.1 sans problème en forçant la borne.
Répondre à ce message
Bonjour,
Le plugin semble incompatible avec spip 4.0.1 (ce qui bloque du coup la m-à-j de nombreux autres plugins). Existerait-t-il un moyen de contourner cette incompatibilité ? J’ai mis à jour tous mes sites à la v4.0.1 (dernière en date) en croyant que « compatible avec spip 4.0 » signifiait « compatible avec 4.0.* »
Euuh c’est marqué dedans :
https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/paquet.xml#L6
Donc bien pour tout 4.0.* infini
Merci, RastaPopoulos
J’ai pu installer mes plugins.
Mais allez savoir pourquoi, lors de mes premières tentatives, mon spip me signalait que le plugin SAISIES n’était pas la bonne version.
Bonjour,
Il m’était aussi indiqué comme incompatible ainsi que quelques autres pourtant compatibles. Pas de menu « mettre à jour », j’ai été obligé de le supprimer puis de le réinstaller via l’archive zip car je ne le retrouvais pas dans « ajouter des plugins ». Bizarre, surement un bug qui traîne sur la partie Core de Spip :(
A suivre...
P.S. : le plugins « Vérifier la compatibilité de vos plugins » indiquait aussi des informations erronées.
Oui il y a un bug lors du passage à SPIP 4 sur SVP (le service qui permet d’installer/mettre à jour les plugins). Il faut supprimer le depot distant et le recreer.
Répondre à ce message
pour info. Je viens juste d’installer la version saisie V4.03 dans le répertoire plugin a la place de la précédente.
Immédiatement ... je ne vois plus dans configuration des plugins ( actif ou incaif) , les plugins non verrouillés par exemple inserer_modele il semble que cela soit ceux dont l’id est supérieur a celui de saisie dans la table plugin. Je vois ceux dont l’id est inférieur .
ils sont toujours dans la table plugin et dans le cache. J’ai effacé local et tmp... idem
j’ai remis la version V4.02 .... mais je ne vois toujours pas les plugins.
heureusement j’ai fait le test en local
les plugins qui étaient déjà actif fonctionnent mais ne sont plus visible au niveau de la gestion des plugins.
Ton SVP a l’air un peu en vrac on dirait :
&var_mode=reinstaller_svpmerci ... les plugins sont visibles et actifs
Répondre à ce message
Bonsoir,
J’ai une question quant au format de texte (html ou brut) à utiliser dans les options (info_obligatoire) des saisies, car selon différent cas de figure j’obtiens différent résultat, je m’explique.
Un de mes clients insiste pour avoir des astérisques rouges pour les champs obligatoires dans un formulaire. Pour des raisons de confort technique j’utilise deux méthodes pour générer les saisies.
D’un coté j’utilise la syntaxe #SAISIE :
Dans mon fichier de langue :
Jusque la tout a bien, côté utilisateur, j’obtiens un astérisque rouge.
J’utilise également la syntaxe php suivante :
$saisies[]= array(
’saisie’ => ’selection’,
’options’ => array(
’nom’ => ’levels’,
’label’ => _T(’choix_niveaux_cours’),
’obligatoire’ => ’oui’,
’info_obligatoire’ => _T(’info_obligatoire_asterix’),
’datas’ => $datas_levels,
)
) ;
Par contre, coté utilisateur, j’obtiens le code html :
Le fait que j’utilise une chaine de langue ne change rien à l’affaire, j’ai testé sans.
Merci d’avance pour votre aide.
Julien
coté PHP, dans l’environnement, ton tableau de saisies il porte bien un nom préfixé par
_? dans le cas contraire il y a un echappement de la part de SPIP.Mais sinon, vu que de toute facon
info_obligatoirepasse automatiquement par_T_ou_typo, bah pas la peine de passer par_Tcôté php, tu met juste la chaine de langue en syntaxe spip (avec les chevrons).Je t’invite à relire la doc d’introduction à saisies ;-). Ainsi que le très bonne article de romy sur le signalement des obligations http://romy.tetue.net/signaler-les-champs-obligatoires
Merci de l’info, j’ignorer qu’on pouvait se passer de _T pour les chaines de langue en php.
Je viens de faire un teste :
Mais ca passe pas :
Parse error : syntax error, unexpected ’<’
En tout cas effectivement il fallait effectivement que je rajoute le _ au nom de mon tableau de saisies.
Cette subtilité m’échappe parfois, je l’ai pourtant mise en place sur la majorité de mes formulaires... Je me demande si l’inverse ne serait pas plus intuitif, devoir mettre le _ pour que spip échappe.
Merci encore.
Après quand tu fais en PHP, ya quasiment aucune raison de faire le squelette toi-même justement. Comme l’indique la doc tu devrais plutôt laisser le squelette totalement vide et laisser Saisies générer cela bien comme il faut, en déclarant ton tableau dans tonformulaire_saisies(). De cette façon tu seras sûr que ça se génère comme il faut :)
il manque les guillemets dans ton code php autour de ta chaine de langue :p
quand aux règles de SPIP, ce sont les régles de spip, et j’ai tendance à penser que la sécurité par défut est une bonne régle (car n’oublie pas que #ENV peut potentiellement venir d’un POST)
Oui RastaPopoulos, j’ai prévu de le passer complétement en php, c’est le cas mes formulaires en générale, mais celui-ci est long et compliqué, je l’améliore étape par étape ;)
Pour Maieul, j’ai testé la syntaxe avec des apostrophes, sans succès, j’avais pas testé les guillemets ;)
Merci à vous deux de vos lumières.
oui alors apostrophe ou guillemet, je parlais bien de ce qui est utilisé en php pour définir un string :)
En gros : si tu déclare en PHP, il faut utiliser la syntaxe de PHP :P
(il vaut mieux préférer en général les simple quotes aux doubles quotes, car ces dernières impliquent une analyse du contenu à la recheche d’éventuelle $, donc un peu plus lent).
Répondre à ce message
Bonjour
ma question est un peu bête mais dans un formulaire j’ai besoin de sélectionner une brève
j’ai testé avec saisies/selecteur mais que des rubriques/articles
aucun des sélecteurs proposés ne concerne les brèves : normal ?
et y a t’il une solution ?
Merci
Natacha
effectivement on n’a pas prévu la saisie breve, car... c’est un objet spip plus trop utilisé.
Il faudrait
1. Créer votre propre saisie en vous inspirant de la saisie articles
2. Idéalement nous la partager pour qu’on puisse l’intégrer au plugin
Merci Maïeul
ceci dit je ne vois vraiment pas comment faire :-)
commence par lire ceci https://contrib.spip.net/Creer-ses-propres-saisies (tu peux deja pour commencer te contenter de la première partie + éventuellement de la partie sur les héritages)
Comme visiblement il n’y a nul part dans SPIP le besoin de selectionner une breve, tu pourrais te baser sur la saisie « selection » par ex.
Je suis dubitatif, car ça dépend du nombre : si l’idée des brèves c’est « des petits articles » et qu’ils peuvent être donc en quantité très importantes, genre des centaines ou plus dans chaque secteur, bah non un select va pas trop le faire… :)
Je vois plutôt ça comme les sélections d’articles et de rubriques donc, mais c’est plus complexe à mettre en œuvre.
effectivement. pour ce genre de cas avec beaucoup de choix, j’ai fait dans le cadre d’une association un input avec datalist. Ca marche pas trop mal (900 personne), mais je sais qu’à partir d’un certains nombre ca foire. peut être qqchose à base de choosen/select 2 ?
La manière graphique de le présenter à l’écran n’est pas trop ce qui me préoccupait là : c’est que c’est généralement mal de garder dans le HTML des centaines voire milliers d’éléments, juste pour permettre d’en choisir (ce qui est le cas avec ton datalist, ou un select qui utiliserait chosen). C’est bien pour ça que les sélecteurs d’articles et de rubriques ne fonctionnent pas comme ça (mais nécessitent ajax… mais c’est un gros défi de savoir faire des saisies dynamiques qui fonctionnent aussi sans JS).
mais justement choosen a pas un API pour chercher en json, donc sans tout charger d’un coup ?
Répondre à ce message
La dernière mise à jour provoque une erreur :
Fatal error : Uncaught Error : Call to undefined function lire_config() in /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/plugins/auto/saisies/v3.49.0/saisies_pipelines.php:68 Stack trace : #0 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/ecrire/inc/utils.php(199) : saisies_affichage_final(’...’) #1 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/tmp/cache/charger_pipelines.php(142) : minipipe(’saisies_afficha...’, ’...’) #2 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/ecrire/inc/utils.php(265) : execute_pipeline_affichage_final(’...’) #3 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/ecrire/public.php(176) : pipeline(’affichage_final’, ’...’) #4 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/spip.php(26) : include(’/home/clients/c...’) #5 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/index.php(3) : include(’/home/clients/c...’) #6 main thrown in /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/plugins/auto/saisies/v3.49.0/saisies_pipelines.php on line 68
Dès que l’on désactive le plugin, tout fonctionne...
Une idée ? CAr du coup ni GIS, ni champ extra, ni formulaire ne peuvent fonctionner !!
Merci de votre aide
Julien
La v3.49.1 qui devrait être disposer dans quelques minutes corrige cela.
https://git.spip.net/spip-contrib-extensions/saisies/commit/44ed5601
MERCI !
Et quelle réactivité !
Répondre à ce message
Bonjour.
Dans les commentaires de Formidable, j’avais posté les suggestions suivantes mais, comme je le supputais et comme Maïeul me l’a confirmé, ça relève plutôt de Saisies. Je me permets donc de le reposter ici :
Bonjour.
Quelqu’un me fait remarquer que, dans un champ date, le sélecteur d’années va de -60 à +40 ans (en 2019, on a donc le choix d’années entre 1959 et 2059).
Or une telle gamme n’est pas toujours souhaitée (on pourrait ne vouloir que trois années) ni toujours adéquate (pour une date de naissance, pas besoin des années à venir, mais probablement bien de dates en deçà de 1959).
Ne pourrait-il pas y avoir des options pour jouer sur l’étendue proposée ? On pourrait ainsi mettre de 2020 à 2022, ou de 1919 à aujourd’hui, ou d’aujourd’hui à 2042, etc.
Peut-être que ça existe déjà, mais je n’ai alors pas trouvé…
(Et peut-être que ça relève plus de Saisies que de Formidable…)
Et, tant qu’à faire, ne pourrait-on pas implémenter dans Formidable le champ HTML5
, qui a le gros avantage de proposer une ergonomie plus adaptée sur appareils mobiles ?
(OK, il faudrait garder le système actuel en fallback pour les navigateurs qui ne le supportent pas encore, et je crains que ça coince pour Safari, où le type date est reconnu mais où aucun outil de saisie n’est présent.)
Plus d’infos sur le type date chez Mozilla…
Merci d’avance pour vos réponses, et bon week-end !
1138.
PS : dans la prévisualisation, le texte
affiche réellement le champ . ;-)
Tu peux faire un ticket sur la nouvelle forge pour cette demande ou tu veux qu’on le fasse ?
https://git.spip.net/spip-contrib-extensions/saisies/issues
Bonjour
je suis confrontée à ce problème. Y a-t-il du nouveau à ce sujet ?
En attendant, quelle est la surcharge que je peux appliquer pour que mon formulaire (qui demande une date de naissance) puisse proposer des dates qui conviennent ?
Florence
Je ne crois pas qu’il y ait de nouveau. Par contre il n’y a toujours pas de ticket non plus. La première chose serait d’en créer un pour cette demande ici : https://git.spip.net/spip-contrib-extensions/saisies/issues
Tu dois sûrement pouvoir surcharger la saisie, en appelant des paramètres différents de à la lib fournie par le core ? Sinon c’est qu’il y a une amélioration à faire directement dans le truc fourni par le core, et dans ce cas le ticket sur Saisies ne suffira pas.
J’ai fait le ticket.
De mon côté (en attendant une éventuelle nouvelle option), je n’arrive pas à trouver à quel endroit la librairie est appelée. Tu as une idée ?
En ajoutant un bout de JS, j’arrive à ce que je veux, mais c’est pas idéal :
Je reviens sur ma tentative d’inclure un script JS dans mon header pour initialiser le calendrier avec les bons paramètres
Le problème est que le code qui appelle la librairie Jquery.dateur.js est appelé dynamiquement en ajax après la fin du chargement de la page. (je le vois dans la console de mon navigateur).
Du coup, mon code produit une erreur car la fonction
datepickern’est pas encore déclaréeComment faire pour que mon code soit appelé après ce code dynamique ?
Bonjour,
Vous pouvez essayer avec onAjaxLoad() .
un exemple ici : https://programmer.spip.net/insert_head
Sinon, pour un fix temporaire vous pouvez surcharger sous squelettes le javascript d’appel de Jquery.dateur.js (ou meme directement Jquery.dateur.js ) en rajoutant votre code derriere .
Bonjour
Merci pour la fonction onAjaxLoad(). C’est nickel.
Répondre à ce message
Bonjour à tous et excellente année 2021.
Je viens de tomber sur une chose un peu bizarre avec une balise #SAISIE.
Je passe à un formulaire l’identifiant de la rubrique courante pour que
l’utilisateur puisse sélectionner un article _de la même rubrique_. Le
passage de paramètre se passe bien, mais la saisie ne fonctionne pas
comme attendue.
J’ai écrit dans mon formulaire :
Je récupère bien dans la sortie html la valeur 14 qui correspond à la
rubrique en cours. Voir pour cela la pièce jointe.
Comme je n’arrivais pas à faire fonctionner limite_branche, j’ai testé
la valeur de rubrique 4 (qui est la rubrique parente de la rubrique 14).
Là, comme on peut le voir, j’obtiens bien des liens sélectionnables sur
les trois rubriques présentes à ce niveau puis sur les articles contenus
dans ces rubriques qui fonctionnent (au css près qu’il faut que
j’adapte). Je m’attendais à trouver la même chose avec la rubrique 14
(qui contient naturellement des articles). À la place de cela, je
n’obtiens que le titre de la rubrique sans aucun lien vers les articles
de la rubrique en question.
J’ai essayé de voir comment était créé ce selecteur_article et ça m’a
renvoyé à prive/formulaires/selecteur/navigateur.html qui est un peu
cryptique.
Toute idée pour contourner le problème sera la bienvenue.
Bien cordialement,
JB
Je me suis perçu trop tard que le code avait été mal transmis. Là, ça devrait être mieux... Désolé.
Répondre à ce message
Bonjour,
Il semble avoir une coquille dans la dernière version, j’ai des « [ » qui apparaisse dans le label des champs date.
Merci
oui ca a été corrigé depuis, mais le tag n’avait pas été posé. La version 3.42.7 bientôt disponible corrige cela.
Ah ok, super, merci.
Répondre à ce message
Bonjour,
j’ai 3 erreurs identiques lorsque je recalcule une page article où il y a un formulaire :
1 Filtre saisies_nom2classe non défini plugins/auto/saisies/v3.42.1/saisies/checkbox.html _checkbox 66Dans ce formulaire il y a 2 cases à cocher pour spécifier une valeur
+ 1 case à cocher pour s’inscrire à une newsletter.
Je ne sais pas laquelle pose problème.
Elle sont toutes décochées par défaut.
Avec Saisies pour formulaires 3.42.1 - stable
Merci
évidemment cette version n’a durée que 5min et il a fallu que tu mettes à jour celle là :p
j’ai refait le tag de cette version 5min plus tard sans la coquille donc il faudrait retélécharger cette version… sinon il faudra que j’augmente la version
mouais, on dirait qu’il y a un bug dans le système de cache du debardeur,
cf le zip joint à cet article.
Bon alors je viens de vérifier et apparemment le système ne refait pas le ZIP quand on supprime et refait le tag… :(
Je modifie la version donc…
Merci !
Je ne fais pas de mise à jour tous les jours, mais là j’ai été trop rapide....
j’ai fait
3.42.1 à 3.42.2
et l’erreur a disparu.
Répondre à ce message
Bonjour,
J’ai une colle pour les meilleurs SAISISTES dans les parages.
J’ai fais un super formulaire CVT en exploitant à 200% SAISIES et c’est top ;) Par contre j’arrive à mes limites en souhaitant mettre de l’ajax et ne pas trop me salir avec du JS inutile.
Mon formulaire étant AJAXé via la class ’ajax’, j’aimerais pouvoir le recharger pour lui renvoyer une données saisies par l’utilisateur, je m’explique.
Il s’agit d’un formulaire d’inscription, et j’aimerais généré via SAISIES autant de champs (nom, prenom, emails) que nécessaire, selon le nombre de personnes spécifié par l’internaute via des ’selects’.
Pour ce faire j’ai commencé par rajouter du javascript dans l’html pour pouvoir déclarer un attribut onChange à mes selects... chose qui n’est pas possible via SAISIES (sauf erreur). Puis un script lancant un ’ajaxReload’ pour renvoyer le nouveau nombre d’inscrits en argument du formulaire, pour généré via une boucle mes champs (prenoms...), enfin bref, ca marche po.
L’ajaxReload ne fait rien du tout... Je ne suis pas d’ailleurs très sur de la syntaxe. Car AjaxReload prends en argument l’id du bloc ajax pour un inclure, mais pour un formulaire CVT c’est moi évident.
Donc si quelqu’un à un exemple sous la main, je suis preneur.
En vous remerciant,
JuL
un an plus tard…
il ne faut pas faire des ajaxReload car sinon tu vas perdre les saisies déjà effectuées, comme avec un rechargement de page quoi
quand on veut recharger un formulaire CVT de SPIP avec des nouvelles informations, il faut *valider* le formulaire, mais détecter qu’on veut s’arrêter dans verifier() en générant une fausse erreur invisible qu’on n’affiche pas (c’est ce que fait la prévisu des forums par exemple)
dans ce cas toutes les saisies sont conservées en mémoire, après à chacun de faire des choses en plus quand tu détectes qu’il y a ci ou ça dans l’environnement en plus (dans le charger() ou les saisies(), c’est après verifier(), donc si ya eu des set_request() ou autre dans verifier() tu peux les retrouver ensuite )
Répondre à ce message
Re-Bonjour Rastapopoulos et Maïeul,
Je viens vers vous pour une question un complexe qui mériterait une documentation à part entière.
Il s’agit d’utiliser AJAX dans les formulaires CVT exploitant SAISIES (j’ignore si c’est le meilleurs endroit pour poster ce message)
Voici donc, j’ai un formulaire publique CVT dont tous les champs sont générés via le php puis inlcus dans le HTML via la balise #GENERER_SAISIES.
Je souhaite que le formulaire se recharge avec de nouveaux arguments au fur et a mesure de la saisie de ce même formulaire donc avant la validation de celui-ci.
Il s’agit d’un formulaire d’inscription a des activités, avec des inscriptions groupés ou on souhaite recueillir les noms des participants.
Actuellement, je récupère les noms des participants dans un TEXTAREA, ce qui n’est pas top à manipuler. je souhaiterais avoir autant d’input que de nom à saisir, pour les « serializer » lors du traitement du formualire.
J’ai cherché et testé puis abandonné...
Il y aurait un exemple sur lequel je pourrais m’appuyer ?
Je sais utiliser l’ajax proposé par SPIP, mais comme il s’agit d’un formulaire je m’en sors pas.
Merci d’avance.
Reéponse coute : je ne sais pas.
Réponse longue ; j’ai un besoin similaire
Réponse très longue : la piste la plus prometteuse serait la saisie « groupe », mais il faut la travailler pour la rendre accessible et générique.
heu, saisie « liste ».
https://git.spip.net/spip-contrib-extensions/saisie_liste.git
La saisie liste pour telle besoin précis ok, mais pour le besoin plus générique de « faire dépendre l’ajout de certaines saisies à la saisie d’autres trucs précédents » c’est forcément plus compliqué et plus générique.
Deux possibilités :
Tente avec les formulaires par étapes. Si à une étape t’as rempli un truc, tu récupère la valeur dans l’étape suivante, et tu mets pas la même saisie ou le même nombre de saisies.
Plus globalement, même sans le système d’étapes qui prémache certaines choses, il s’agit d’utiliser le « verifier » quoi. Sachant que le charger (et donc la déclaration des champs quand on fait avec saisies) ça arrive APRES verifier et traiter. Donc normalement quand tu es dans la déclaration des champs, tu es capable de savoir la valeur d’un autre précédent, pour peu que t’as arrêté la validation durant « verifier ». Donc 1) quand tu postes un champ « nombre de participants » par ex, faut dire dans verifier() de s’arrêter, et 2) lors de ce deuxième chargement, faut mettre le bon nombre de gens à remplir. Un truc comme ça.
Effectivement le système de formulaire par étape pourrait être une solution.
Originellement, j’aurais souhaité qu’un javascript intervienne comme on peut le faire avec l’AJAX des INCLURE permettant de recharger un bloc a distance avec des arguments.
https://contrib.spip.net/Exemple-de-bloc-telecommande-en-Ajax
Sauf que les blocs ajax des formulaires ne semble pas d’avoir d’ID ajax définissable contrairement au bloc INCLURE.
La solution des étapes me semble une bonne piste effectivement, si la seconde étape prends en compte les données de la précédente, c’est déjà ca. Je pense toutefois que cela porte préjudice à l’ergonomie, en tout cas dans mon cas de figure ou le formulaire n’est pas très compliqué.
Répondre à ce message
Bonjour,
Dans l’exemple
https://contrib.spip.net/Saisies#La-balise-80c3
Pouvez-vous préciser comment est défini le nom de la variable
#ENV{_saisies}?Est-ce parce que la fonction
formulaires_monformulaire_saisies_dist(…) {termine par _saisies_dist ?Ou bien est-ce précisément lié au nom de variable array créée dans cette fonction et renvoyée par le return ?
Merci
Le contenu de cette variable est le tableau renvoyé par
_saisies_dist()si vous l’utilisez, sinon vous devrez le remplir à la main dans le tableau de retour de votre fonction_charger.J’ai bien compris ce que contient ou doit renvoyer la variable.
La question est sur le nom de la variable à utiliser : #ENV_saisies
- Est-ce qu’il faut mettre toujours “_saisies” sans chercher à comprendre ?
- Est-ce qu’il faut mettre “_saisies” parce que la variable locale dans la fonction “formulaires_monformulaire_saisies_dist(” est : $saisies = array( (ou bien aucun lien) ?
- Est-ce qu’il faut mettre toujours “_saisies” parce que c’est le fonctionnement du formulaire avec la fonction formulaires_monformulaire_saisies_dist ?
Merci
Il faut mettre
_saisiesparce que c’est conventionnel ET parce que c’est ce que renvoie la detection automatique des saisies définie parformulaires_monformulaire_saisies_distBah ça dépend ce que tu fais, si tu fais tout tout seul tu fais bien ce que tu veux.
Mais
Par ailleurs le _ devant est absolument obligatoire, même si tu t’amuses à utiliser un autre nom, puisque c’est ce qui permet à CVT de ne PAS traiter la variable avec des choses qui vont la péter.
OK c’est clair.
Peut-être à préciser dans l’article.
Merci à tous les deux.
Répondre à ce message
Bonjour,
Dans l’exemple
formulaires_monformulaire_saisies_dist(…) {Qu’il y-a-t-il dans les “…” entre les parenthèses ?
Merci
Normalement les mêmes choses que dans les fonctions _charger(), _traiter(), etc. Je précise la doc.
Répondre à ce message
Bonjour,
Manifestement, il y avait un bogue sévère dans la dernière version de Saisies, qui a été supprimée pour revenir à une version antérieure. Problème, mon site avait été mis à jour entre temps et est resté 2 semaines avec tous ses formulaires bloqués (nous avons es messages importants en ce moment d’intérimaires qui ont de gros soucis de paie), jusqu’à ce que je piste les erreurs dans php avec un développeur pour retrouver l’origine du problème, puis par google que nous retrouvions que l’extension Saisies était en cause.
Suggestion : Il serait sans doute plus efficace pour tous les utilisateurs je pense, que l’ancienne version (celle qui fonctionnait), soit republiée avec une nouvelle numérotation, plutôt que de simplement faire disparaître la dernière. L’extension boguée disparaitrait ainsi naturellement des sites qui entretiennent leurs mises à jour, au lieu de rester coincée en production.
D’autant que je ne suis pas certains que d’autres sites ne sont pas encore dans le cas que je décris...
Merci en tout cas pour vos excellentes extensions (c’est le principal :-)
Alors, non, on ne vas surtout pas faire ça. À la limite s’il s’était agit d’une version très mineure encore… mais là on va certainement pas passer à un numéro majeur 4.X alors qu’il n’y a strictement rien de nouveau, aucune refonte, rien dans le plugin. Passer de 3.X à 4.X c’est pas un truc commun quoi…
La version fautive est une version qui n’a jamais existé du tout plus de 30min, et elle est apparue publiquement suite à un changement majeur dernièrement dans le système de génération des paquets SPIP. On a essuyé les plâtres, c’est comme ça… mais cette version vraiment n’existe pas. Et elle n’avait aucun bug, c’est juste que c’est un état (un tag en l’occurrence) du plugin de… 2018, donc forcément il manquait plein de choses qu’attendaient les formulaires récents.
Il faut donc la supprimer et remettre la vraie dernière version.
Répondre à ce message
Où en est le problème de version d’il y a quelques jours ? Est-ce que la version 4.0.0 est valide ? Est-ce qu’on peut l’installer sur un SPIP 3.2.7 ?
Dans la capture faite à l’instant, on voit 3 fois une version 3.36.2, toutes trois de tailles différentes.
D’avance merci
La référence c’est
https://plugins.spip.net/saisies.html
Vivement que ces deux sites soient fusionnées enfin !
Je supprime les merdouilles.
Merci
Vivement que la page /ecrire/ ?exec=admin_plugin ne mentionne plus « version obsolète » sur la ligne du plugin Saisies pour formulaires 3.36.2
oui Rasta, le script de synchronisation s’est visiblement embrouillé avec le passage au débardeur. Il devient urgent d’accélerer la fusion des deux sites.
Guillain, la version 4.0.0 ainsi qu’expliqué n’a jamais vraiment existé. C’est une erreur si elle a été annoncée.
si ils t’annonce encore que c’est obsolète, je craint qu’il ne faille passer par une correction « à la main » dans la table spip_paquets et spip_saisies (après tout de même aovir testé une actualisation manuel des depot distants)
Merci
Je vérifierai ce soir ou demain
J’ai du supprimer et ajouter les dépôts pour corriger le problème
Merci
Répondre à ce message
ATTENTION ! => Le plugin SAISIES n’est pas encore actualisé en AUTO ce qui désactive le plugin FORMIDABLE ! Ce qui est gênant, car nous attendons des inscriptions à un événement par un formulaire créé avec FORMIDABLE.
MESSAGE :
Erreurs survenues
Impossible d’activer le plugin ../plugins/auto/formidable/v4.1.1
Nécessite le plugin SAISIES en version ≥ 3.34.0.
C’est très bizarre que tu ai cela. D’abord la version 4.1.1 de formidable ne nécessite pas saisies 3.34.0 mais 3.26.0
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/formidable/trunk/paquet.xml?rev=122758
En revanche la version 4.2.0 le nécessite
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/formidable/trunk/paquet.xml?rev=122772
mais elle a été posté après le poste de la version de saisies
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/saisies/trunk/paquet.xml?rev=122770
donc c’est étrange...
J’ai trouvé où est le problème chez moi : Saisie est marqué 3.33 sur le site alors qu’elle est la 3.34.
En effaçant le plugin/saisies sur mon site et en le téléchargeant à la main, la fausse 3.33 qui dans paquet.xml est marquée 3.34, ça marche.
Ça n’empêche que ce bug est étonnant et je ne l’explique pas.
@Maieul : La version 4.2.0 a le même problème.
Et si Saisies n’annonçait pas bonne version ? Je ne connais pas le mécanisme d’annonce en mise à jour auto.
visiblement tu n’a pas eu de chance, mais effectivement il y a un bug. Je sais que dans le passé la même situation c’était produite mais à l’époque j’avais commité formidable avant saisies, et à quelques minutes près cela avait posé problème.
Mais là... je ne sais pas, c’est au niveau du generateur de paquet qu’il y a un bug.
En tout cas sur un autre site, j’ai reussi à mettre à jour formidable via svp sans aucun souci.
Répondre à ce message
C’est OK maintenant !
Merci !
Michel
Répondre à ce message
Depuis la dernière maj de SAISIES, le plugin BIG UPLOAD ne fonctionne plus : l’image ou le doc ne s’uploade jamais.
Je suis donc revenu sur une version antérieure du plugin SAISIES en attendant.
Quelle màj ? En passant de quelle version à quelle version ?
En version 3.31.3 de SAISIES ça fonctionne. Sur /ecrire/ ?exec=admin_plugin j’ai un message
Dès que je passe SAISIES en version 3.31.4, BIG UPLOAD ne fonctionne plus.
Je suis en SPIP 3.2.7 [24473] et tous mes plugins sont à jour, sauf SAISIES.
BIG UPLOAD est en version 1.0.4.
Alors la seule modif entre ces deux versions précises ne concerne que le constructeur de formulaires, et absolument aucune saisie :
https://zone.spip.net/trac/spip-zone/changeset/120902
Donc je vois pas comment ça pourrait avoir un quelconque changement sur Bigup n’importe où ailleurs, ça ne modifie strictement rien nulle part de chez nulle part. Donc ça peut pas être ça.
Vu la fréquence des maj du plugin SAISIES, il est possible que je sois passé d’une maj précédente à 3.31.3 vers 3.31.4
Dans mon infrastructure, les seuls plugins dont l’un ne fonctionne pas quand les 2 sont actifs sont BIG UPLOAD est SAISIES. BIG UPLOAD n’a pas été mis à jour depuis plusieurs semaines et d’un coup s’est mis à ne plus fonctionner
Et BIG UPLOAD ne dispose pas d’une page sur CONTRIB, ce qui rend toute alerte compliquée
Par ailleurs je sais pas pourquoi tu tomberais sur 3.31.4 alors que Saisies en est à une version bien plus loin (dans la même branche 3), donc ça se trouve c’est déjà corrigé…
La version actuelle, la vraie dernière 3.33.1 du 22/02/2020 de SAISIES et la version1.0.4 de BIG UPLOAD ne fonctionnent pas ensemble. C’est un fait. J’utilise donc une ancienne version de SAISIES.
Que le problème vienne de la dernière maj, de l’avant dernière ou de l’avant avant dernière, etc... ne résout pas mon problème. Quand j’aurais le temps de tester je désactiverai tout encore une fois puis je verrai.
Quand on est pas développeur soi même, c’est vraiment la jungle pour savoir où trouver quoi entre contrib et les autres plateformes. Quant aux explications des maj, il faut s’accrocher pour décrypter et surtout comprendre les implications. C’est l’un des éléments qui à la longue usent. Pour que SPIP vive longtemps, il faut pourtant que des gens comme moi s’y retrouvent sans y perdre des jours et des nuits.
J’ai présentement sous les yeux plusieurs sites avec Saisies totalement à jour 3.33.1 et Bigup à jour (version de github), et il n’y a AUCUN problème, ça upload direct quand j’ajoute un document dans un article par exemple.
C’est un fait.
Par ailleurs je vois pas de quelles autres plateformes tu parles, il n’y en a pas 40000. Pour les users c’est Contrib la porte d’entrée pour tout ce qui est ajout, pour tous les plugins que les devs ont rendu public et distribuent.
Si un dev a pas fait de doc, bah c’est qu’il veut pas en faire du support, je sais pas moi… Donc après c’est à utiliser en conséquence, si on utilise un plugin non documenté nulle part, c’est bien qu’on l’a trouvé quand même, donc qu’on est un « power user », et c’est alors qu’on sait ce qu’on fait, on peut pas se plaindre d’être un pauvre « juste utilisateur » sans défense.
Je me permet d’intervenir, non pas sur le fond, mais sur la forme.
J’ai l’impression qu’on ne va pas s’en sortir comme cela avec du « chez moi ca marche » / « chez moi ca marche pas », et de « non mais les sites SPIP sont pas clair » et « si si les sites SPIP sont clair ».
De facto, chacun à sa vision. Il y a sans doute un élément technique qui explique cette différence de vision, car je ne pense pas que Guilain ou Rastapopoulos s’amuse à dire des choses qu’ils ne voient pas.
Donc maintenant Guilain
1) peux tu me dire avec quelle version de saisies cela fonctionne chez toi
2) peut tu me dire où ton formulaire bigupload ne marche pas
Bé si le « chez moi ça marche » sert à dire : avec cette version de Saisies et la dernière de Bigup, ça PEUT bien marcher puisque ça marche chez moi DONC ça signifie que ce n’est pas UNIQUEMENT le fait d’avoir Saisies à jour qui fait que ça merdouille chez lui. Il y a forcément autre chose.
Et autant que possible, ce n’est pas à nous de faire 40000 tests : c’est pour ça qu’à l’origine au dessus du champ de commentaire il y avait une explication relativement claire disant qu’avant de rapporter un bug, il fallait d’abord tester sur une installation vide contenant uniquement les 1 ou 2 trucs qu’on veut tester (cette explication a été perdue avec la refonte). Ce qui permet déjà d’isoler et de savoir si c’est la conjonction avec encore un autre plugin qui fait merder.
Merci Maieul pour cette approche non caricaturale.
Comme je l’avais écrit, j’ai trouvé le temps de refaire ce que j’avais déjà fait : désactiver tous les plugins, réinstaller les dernières versions des plugins incriminés, vider les caches, comme je le fais à chaque fois que ça merdouille depuis plus de 10 ans que j’utilise SPIP
Mystère, tout refonctionne à priori pour BIG UPLOAD
@RastaPopoulos, je ne vais pas t’apprendre qu’il ne manque pas de plugins en version test après plusieurs années, ou de plugins qui obligent à télécharger d’autres plugins en test, et qu’il ne manque pas non plus de plugins sans documentation.
Ce plugin BIG UPLOAD est un de ceux là : imposé à l’install d’un autre plugin. Il me semble qu’il s’agit du plugin espace privé plus large mais n’en suis pas sur.
Et je continue à croire que SPIP conduit à un web plus vertueux grâce à ses indéniables qualités qui ne gomment hélas pas la liste de ses défauts, dont celui d’être coincé si on utilise pas un plugin non documenté ou en test.
Répondre à ce message
(re) Bonjour
Petit dysfonctionnement :
quand on limite l’extension et/ou la taille des fichiers à uploader, et que cette limitation n’est pas respectée, le message indique « Vous pouvez renvoyer un nouveau fichier ou bien soumettre le formulaire tel quel... ».
Or dans le cas où la soumission du fichier est obligatoire, on ne peut pas soumettre tel quel (j’ai un utilisateur très fâché d’avoir eu un tel message).
Peut-être faudrait-il faire 2 messages distincts en fonction du caractère obligatoire ?
Oui, effectivement, le message est trop générique (mais l’utilisateur même pénible à toujours raison).
La version 3.32.0 du plugin corrige cela.
https://git.spip.net/spip-contrib-extensions/saisies/commit/19d30b59357a2e34ff59b982099428a8bcf6f653
Répondre à ce message
Bonjour à tous,
Je voudrais savoir comment mettre en ligne un formulaire que j’ai créer depuis le plugin.
Je peux dans une page ajouter le formulaire mais je ne le vois pas en ligne !!!
Il y a t’il une manipulation en plus à faire ? Peut être dans l’édition de la page un champ à rajouté ?
Merci
J’imagine que tu parle du plugin formidable.
Tu peux intégrer un formulaire (publié) sur une page en utilisant le raccourci
<formulaire|formidable|id_formulaire=xxx>, ou xxx est le numero de formulaire.Je t’invite la prochaine fois à poster la question dans le forum du plugin formidable, pas de saisies.
super merci :)
Répondre à ce message
La tentative de mise à jour de Saisies pour formulaires 3.27.7 - stable vers 3.28.0 fait péter le site avec une ribambelle de plugins en erreur.
La 1e erreur concerne : SPIP Bonux 3.4.6 - stable (désactivé de facto)
met a jour aussi bonux vers 3.5.0
Pour info, sur le carnage....
Gestion des plugins
Erreurs survenues
Impossible d’activer le plugin ../plugins/auto/saisies/v3.28.2
Utilise le plugin SPIP_BONUX en version ≥ 3.5.0.
Impossible d’activer le plugin ../plugins/auto/jeux/v3.4.4
Nécessite le plugin SAISIES en version ≥ 2.28.0.
Impossible d’activer le plugin ../plugins/auto/gis/v4.47.9
Nécessite le plugin SAISIES en version ≥ 3.27.5.
Impossible d’activer le plugin ../plugins/auto/gisgeom/v1.11.7
Nécessite le plugin GIS en version ≥ 4.42.0.
Impossible d’activer le plugin ../plugins/auto/inserer_modeles/v1.3.4
Nécessite le plugin SAISIES en version ≥ 2.28.0.
Impossible d’activer le plugin ../plugins/auto/contact/v0.16.5
Utilise le plugin INSERER_MODELES en version ≥ 1.0.0.
Impossible d’activer le plugin ../plugins/auto/odt2spip/v3.0.6
Nécessite le plugin SAISIES en version ≥ 2.28.0.
Impossible d’activer le plugin ../plugins/auto/agenda/v3.32.1
Utilise le plugin FULLTEXT en version ≥ 1.0.0.
Utilise le plugin SAISIES en version ≥ 3.27.0.
Utilise le plugin PAGES en version ≥ 1.3.10.
Impossible d’activer le plugin ../plugins/auto/fullcalendar_facile/v2.4.3
Nécessite le plugin AGENDA en version ≥ 3.18.4.
Impossible d’activer le plugin ../plugins/auto/albums/v3.5.7
Utilise le plugin SAISIES en version ≥ 1.40.0.
Impossible d’activer le plugin ../plugins/auto/media/v1.4.10
Utilise le plugin INSERER_MODELES en version ≥ 1.1.11.
Impossible d’activer le plugin ../plugins/auto/rainette/v3.6.1
Nécessite le plugin SAISIES en version ≥ 3.12.7.
Impossible d’activer le plugin ../plugins/auto/sarkaspip/v3.4.9
Utilise le plugin CONTACT en version ≥ 0.9.0.
Utilise le plugin GRAVATAR en version ≥ 1.5.0.
Utilise le plugin NOTATION en version ≥ 2.0.4.
Utilise le plugin PHOTO_INFOS en version ≥ 2.0.0.
Utilise le plugin RAINETTE en version ≥ 1.5.3.
Utilise le plugin RECOMMANDER en version ≥ 1.0.3.
Utilise le plugin SHOUTBOX en version ≥ 0.2.0.
Utilise le plugin SOMMAIRE en version ≥ 1.0.6.
Utilise le plugin SPLICKR en version ≥ 0.4.5.
Utilise le plugin TICKETS en version ≥ 2.9.1.
Utilise le plugin TODO en version ≥ 2.0.6.
Utilise le plugin ZENGARDEN en version ≥ 2.5.1.
Impossible d’activer le plugin ../plugins/auto/cvtupload/v1.17.2
Utilise le plugin SAISIES en version ≥ 3.18.1.
Impossible d’activer le plugin ../plugins/auto/formidable/v3.42.5
Nécessite le plugin SAISIES en version ≥ 3.26.0.
Impossible d’activer le plugin ../plugins/auto/timecircles/v1.5.3.23
Utilise le plugin AGENDA en version ≥ 3.19.0.
Actions réalisées
La mise à jour du plugin « Saisies pour formulaires » (de la version : 3.27.7 à 3.28.2) s’est correctement déroulée
Vous avez pas eu de chance, au sens où vous avez recu la mise à jour de saisie sans la mise à jour de bonux. Mettez à jour bonux, puis réactivez vos plugins.
Répondre à ce message
Bonjour,
En faisant une mise à jour du plugin vers la version 3.22.0, le site a été bloqué.
En revenant à la version antérieure 3.21.2, ce problème a été réglé.
SPIP 3.2.4
Cordialement
Que signifie « le site a été bloqué » ? Si tu as une page blanche tu dois configurer PHP pour afficher les erreurs, afin de savoir vraiment ce qui se passe.
https://www.spip.net/fr_article4453.html#erreurs
Bonjour,
Après la mise à jour du plugin, j’ai bien une page d’erreurs PHP. Je n’ai pas fait de capture d’écran.
Je l’ai désactivé et réinstallé. Le plugin reste obsolète.
Cordialement
bah en l’absence de message d’erreur, ca va être dur d’aider...
Merci, avec la version 3.22.1 j’ai pu mettre à jour et cela fonctionne.
la version 3.22.1 ne portait pas sur ce problème, puisque je le connaissais pas ....
Répondre à ce message
Bonsoir,
Je n’arrive plus à configurer mes groupes de champs et mes champs ’explication’ dans champs extras, je pense qu’une mise à jour récente en est la cause. Est-ce que SAISIES en est la cause ?
Bien à vous,
Jul
oui, mea culpa. J’ai voulu exclure les saisies fichiers mais j’ai été un peu trop radical. Je vais regarder comme faire.
la prochaine version de saisies et de champ extra interface corrige ce bug.
Youpi. Merci !!!
Répondre à ce message
Bonjour, j’ai mis un sondage réalisé avec formidable.
Depuis peu, j’ai ses messages d’erreur qui s’affichent dans les résultats du sondage. J’ai cherché pour voir de quoi ça vient sans trouver.
Une idée ?
Merci d’avance pour votre aide.
Warning : array_keys() expects parameter 1 to be array, null given in /home/chipfm/public_html/plugins/auto/saisies/v3.18.5/inc/saisies_lister.php on line 135
Warning : array_shift() expects parameter 1 to be array, null given in /home/chipfm/public_html/plugins/auto/saisies/v3.18.5/inc/saisies_lister.php on line 136
Warning : Invalid argument supplied for foreach() in /home/chipfm/public_html/plugins/auto/saisies/v3.18.5/inc/saisies_lister.php on line 141
Pouvez vous envoyer un export yaml du formulaire ? cela me permettrait de remonter la piste.
A priori, ce n’est pas très grave. Cela étant, il faudrait demander à votre hébergeur, ou régler vous même, pour que les messages d’erreurs ne s’affichent pas publiquement.
merci pour votre aide.
J’ai fait l’export., comment vous l’envoyer ?
Comment puis je régler pour que les messages d’erreur ne s’affichent pas ?
vous pouvez m’écrire à monprenom@monprenom.net
pour le réglage de l’affichage des erreurs, ca depnd des hebergeurs. Mais dans tous les cas
dans votre fichier mes_options.php pourrait masquer cela. Cela étant, ce serait bien de voir avec votre hebergeur pour que ce soit masqué par défaut.
Merci, je regarde ça tout de suite.
Je suis long a répondre car j’ai des coupures internet fréquentes.
la version 3.36.6 du plugin Formidable devrait corriger le problème.
Répondre à ce message
Bonjour,
avec la version 3.12.6, je n’arrive plus à définir de valeurs personnalisées pour la saisie oui_non.
J’obtiens une erreur « Valeur postée non acceptable. »
la fonction
oui_non_valeurs_acceptables($valeur, $description)semble exclure en effet la possibilité d’utiliser de valeurs personnalisées.arf, j’ai du oublier de mettre cela, parce que je savais pas que c’était possible (pas déclaré dans le yaml)
j’essaie de m’occuper de cela présentement.
voilà, la version 3.12.7 devrait résoudre le problème.
Parfait, merci
Encore un bug ou je comprends mal le fonctionnement
La valeur par défaut dans« oui_non » et « selection » n’est pas pris en compte.
Actuellement, dans les saisies correspondantes, la valeur est définie
et ma valeur défaut est ignoré.
Si je remplace par
ma valeur défaut est bien prise en compte.
Spip 3.2.3 avec php 7.2
Répondre à ce message
Bonjour,
depuis la mise à jour du plugin vers sa dernière version disponible (v3.12.5) sous SPIP 3.2.1, j’obtiens à la validation d’un formulaire :
ERREUR : fonction execute_pipeline_saisies_verifier absente : pipeline desactive
Une idée de la raison ?
Quelle était la précédente version de saisies ? on n’a pas touché recemment aux pipelines.
Est-ce que tu as essayé en supprimant le fichier tmp/cache/charger_pipelines.php ?
Merci de ta réponse rapide et de ton aide. Oui j’ai vidé tous les caches. Je ne me souviens plus la version précédentes de saisies installée, mais ma dernière mise à jour des plugins ne remonte pas plus loin que novembre dernier. J’ai fait des tests avec différents formulaires, et j’obtiens toujours le même message.
Ce sont des formulaires de SPIP ? ou des formulaires formidable ?
tu as mis à jour tous les plugins ? ou seulement saisies ?
Je pense que la version 3.12.6 binetôt disponible devrait résoudre ce problème, mais à confirmer car je n’arrive pas à le reproduire.
Cela se produit avec les formulaires Formidable et oui j’ai mis à jour tous les plugins. J’espère que cela n’est pas trop grave. Ok je verrais avec la MAJ du plugin. Merci de ton attention.
J’ai le même log étrange :
fonction execute_pipeline_saisies_verifier absente : pipeline desactive
Et je ne parviens pas a en trouver l’origine, d’autant plus que les vérifications fonctionnent très bien, et que rien ne semble désactivé (SPIP 3.2.3 [24211] & API Verifier 1.8.2).
Bonne soirée,
Effectivement il y a un problème. Même message.
Celui-ci n’apparait pas lorsque le formulaire n’utilise pas afficher_si
C’est cette utilisation qui génère ce problème.
Soit notre appel n’est pas convenablement fait, ce qui est probable, soit il y a un autre souci.
Je travaille sur la question...
Non, après un vider le cache, l’erreur se maintien et cela ne semble pas lié à « afficher_si »
Le test se base sur :
https://contrib.spip.net/Un-formulaire-C-V-T-avec-Saisies-par-l-exemple
et le log
2019-01-31 09:00:43 ::1 (pid 60629) :Pri:ERREUR : fonction execute_pipeline_saisies_verifier absente : pipeline desactive
Trouvé. C’était yaml. Le plugin en version test (2.0.10 - en test) n’est pas très sympathique avec SAISIES.
Mais de quoi c’est yaml ? Quel rapport avec le pipeline « saisies_verifier » ? Vous avez bien la dernière version de Saisies avec la modif de Maieul qui déclare le pipeline manquant, qui n’était pas déclaré depuis le début ?
https://zone.spip.net/trac/spip-zone/changeset/113611/spip-zone
J’avoue non plus ne pas voir en quoi il y pourrait y avoir un lien avec yaml.
En attendant, la question reste : quelle version du plugin saisies utilisez vous ?
J’étais sous SAISIES 3.12.4, j’ai tout resintallé (dont SAISIES 3.12.6 ) et j’ai eu ce message :
Erreur dans les plugins :
/Applications/MAMP/htdocs/plugins/yaml_v2/yaml_fonctions.php,
/Applications/MAMP/htdocs/plugins/verifier/verifier_fonctions.php
Après le retrait de Yaml, tout se passe bien.
D’ou ma conclusion, certainement hâtive...
est tu repassé par la page d’admin des plugins après reinstall ?
Oui, car j’avais même réinstallé SPIP. J’avais fait table rase en local pour tout reprendre à zéro et comprendre ce qui se passait.
bah c’est peut être une coincidence alors.
le mieux reste encore d’installer le plugin eu mode automatique, pour être sur d’avoir la dernière version à chaque fois.
En tout cas plus de problème et merci pour votre aide (ainsi que pour cette API Verfier et ce plugin SAISIES super).
Répondre à ce message
Je regardais pour rendre obligatoire une saisie « radio » (pour une vérif html5) et en testant je me rends compte que ca ne fonctionne pas tip top.
Et le fichier radio.html ne fait aucune mention d’un test sur obligatoire.
C’est voulu ?
Du coup je surcharge ma saisie avec le code ci-dessus.
Et d’ailleurs ma solution n’en est peut-être pas vraiment une car elle entraine des effets de bords indésirables sur les saisies radio obligatoires avec afficher_si, qui du coup me sort des jolis
Merci du signalement.
Il fallait aussi modifier le code du js pour afficher_si
https://zone.spip.net/trac/spip-zone/changeset/113558/spip-zone
fait cela
Ah nickeul Maïeul !
Merci, ca marche bien du coup :)
Répondre à ce message
Bonjour à tous,
Je rencontre un soucis avec l’utilisation du paramètre « afficher_si » dans un formulaire dont les champs sont généré via PHP, puis en exploitant la balise #GENERER_SAISIE.
Voici un morceau de mon formulaire CVT en php :
Je souhaiterais n’afficher dans mon formulaire le champ prenom_inscrit que si le champ précédent est égal à ’public’.
Malheureusement, je me retrouve avec une erreur Javascript :
Uncaught SyntaxError : Unexpected token &
On peut effectivement constater que dans le javascript généré on voit cela :
Les guillemets sont remplacés par leur code html, je ne pense que cela soit normal, et provoque ensuite une erreur ...
Voici le début du code javascript généré
Coté html, je vois que mon champ est bien généré :
J’ai essayé de nombreuses syntaxes différentes pour définir la condition mais rien n’y fait...
Merci de vos lumières !
Jul
SPIP protège automatiquement les guillemets pour les variables passé au chargement du formulaire. D’où le « " ».
Mais tu peux désactiver cela en mettant un _ devant le nom de la variable dans le tableau de retour.
et
Merci Maïeul !
Une réponse simple et efficace ! Je viens de tester, et cela fonctionne fort bien !
J’avoue que je n’aurais jamais trouvé !
Malgré tout est-ce normal comme comportement vu que c’est obligé d’utilisé les ’ ou ’’ dans la condition de afficher_si ?
Il n’y a pas mention de cette subtilité dans la doc, est-ce un oubli d’après toi ou c’est moi qui utilise cet outil de manière non-conventionnelle ?
un grand Merci !
En fait :
- le comportement de protection des attributs relève du comportement de CVT. Et c’est donc documenté dans la doc de CVT : https://www.spip.net/fr_article4151.html
- la présente doc a été écrite avant que
_afficher_sisoit implémenté.Je viens de corriger ici ainsi que dans la doc spécifique à
_afficher_si.J’ai eu le même problème avant cette discussion et je l’avais résolu par :
Mais bon je ne sais pas si c’est le mieux :)
bof, c’est pas terrible, car tu pourrais avoir besoin d’entité encodées pour x raison.
Bon et bien je vais adopter l’astuce du underscore :)
Répondre à ce message
bonjour,
je télécharge saisie depuis cette page
Version 3.8.3
(ZIP – 193.5 ko) SPIP 3.0, SPIP 3.1, SPIP 3.2
quand j’active le plugin il me met dans la page des plugins actif :
Saisies pour formulaires 2.28.0 - stable
Écrire facilement des champs de formulaires
Est ce normal ? quelle est vraiment la version
merci
je suis étonné. La version marqué « saisies_v3 » contient bien la version 3.x de saisies
Bonjour,
merci de me répondre., entre temps, pressé par une démo à faire, j’ai posé la question sur la liste et j’ai eu cette réponse de Frank
« ce qui c’est passé, c’est que au moment de la création de la 3e branche, il y a eu oubli de faire l’ajout du zip dans l’article puisque ce n’est pas automatique (contrairement à plugin.spip). Je viens de mettre à jour les zips dans l’article de contrib😊 »
Si j’ai bien compris les différentes réponses, il est préférable :
- En manuel de prendre en priorité sur plugin.spip
- En automatique suivre la procédure expliqué sur https://www.spip.net/fr_article3396.html
A oui, c’est bien possible (même si normalement c’est censé être automatique, ca bug)
Oui normalement c’est bien automatique (mais pas immédiat) : d’abord ça génère les ZIP, ça se met à jour sur plugins.spip (après déjà un délai) et ensuite un autre robot reporte ces ZIP sur Contrib (deuxième délai).
Je sais pas si des trucs ont pu sauter avec la mise à jour des squelettes de Contrib…
Rasta : c’est surtout que le robot qui met à jour sur contrib le fait de la mnière aléatoire (il prend x plugin au hasard) et pas de manière linéaire...
LA sortie de la version 3 de saisies date de bien avant la nouvelle version de contrib
Répondre à ce message
Bonjour,
Dans la descriptions des saisies, au niveau des styles de l’espace privé des formulaires, l’option d’avertissement (attention) n’est pas stylisée :
code généré entre « explication » et « la saisie »
Est ce possible d’ajouter les styles de saisie qui vont bien ? (attention = notice ?)
J’oublie peut être quelque chose ?
cela correspond à la norme prévue par SPIP.
https://www.spip.net/fr_article3791.html
si modification il doit y avoir, ce serait au niveau des css de l’espace privé de SPIP pourqu’il prenne en compte cela.
résolu. Merci !
https://core.spip.net/projects/spip/repository/revisions/24102/diff/spip/prive/themes/spip/forms.css.html
Répondre à ce message
Bonjour,
j’utilise saisie avec un formulaire yaml.
est-il possible d’avoir un champ <input type=’color’ avec la derniere version de saisie ? si oui comment ?
merci
Ya une saisie « couleur ». Sinon un input avec type=color.
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/saisies/trunk/saisies/couleur.html
merci j’ai activé palette et utilisé la saisie couleurs
je n’arrive pas à utiliser la saisie mot avec id_groupe j’ai toujours Unable to parse line 197 (id_groupe :’20’) idem avec "2 ou 20
options :
nom : ’style’
id_groupe :’20’
sans le id_groupe cela marche
Répondre à ce message
Je note ici pour ne pas oublier : l’option afficher_si ne fonctionne pas pour les saisies enfants d’une saisie fieldset
Je m’en sert régulièrement sur un formulaire formidable sans souci.
Ah oui, je confirme, ça fonctionne dans formidable.
Moi c’est dans le contexte de saisies générées à partir d’un yaml, pour une noisette.
Le JS n’est pas présent dans le squelette compilé (mais il y a bien le data-afficher_si sur le .editer).
Ça fonctionne très bien tout compte fait, je n’avais pas indenté le yaml correctement, cf https://contrib.spip.net/noiZetier-v2#forum494678
Salut !
Lorsque j’utilise un fichier yaml pour générer mes saisies j’ai un gros bug avec la syntaxe des critères afficher_si
Avec une condition de type == ou != pas de problème
Salut,
je n’ai jamais utilisé YAML pour des saises. Pas impossible qu’il y ait des soucis dans le parseur. Mais sinon, je suis même pas certains que IN soit acceptés en tant que tel (je me rappelle plus).
Dans tous les cas, il me faudrait un YAML complet mais minimum pour résoudre le problème.
chez moi dans les options ceci fonctionne :
regarde si tu n’as pas un problème d’indentation
Répondre à ce message
Bonjour,
Je teste le générateur de formulaire qui utilise ceplugin, et il m’a l’air très bien, sauf qu’il me manque des champs importants, la possibilité de saisir des coordonnées gps, et surtout d’afficher des cartes (google map ou open street) avec ses coordonnées et des infos sous forme de bulles sur la carte.
Des idées pour pouvoir le faire ?
Merci de votre travail partagé à la communauté.
Répondre à ce message
Bonjour,
Pour éviter à d’autres d’avoir le problème.
Avec formidable, j’ai un formulaire qui a des cases à cocher.
Il est donc possible de sélectionner plusieurs items dans la liste.
Mais dans le mail envoyé, et dans ecrire/ ?exec=formulaires_reponses&id_formulaire=1 quand je vais voir le détail, je n’ai que la première option de mémorisée, alors que j’ai mis d’autres valeurs.
Raison : je faisais :
165/Hotelvendredi|Hôtel vendredi 9 novembre<br />165 €En remplaçant le / par &, plus de problème !
Précision : ce qui marche, c’est donc :
165&Hotelvendredi|Hôtel vendredi 9 novembre<br />165 €A oui, le
/est utilisé pour des sous entrées. Du coup je ne sais pas si on peut résoudre ce bug facilement sans casser le reste. Il faudrait pouvoir échapper le / mais je ne suis pas sûr que cela vaille la peine....Non, je ne crois pas que ça vaille la peine.
Par contre, où est la doc de ce « / » ?
Je sais pas s’il y une doc. J’ai vu passer cela récemment en lisant le code pour améliorer un point.
Des sous entrées de quoi ?
Moi je me rappelais juste du truc ajouté par Maieul qui ajoute de la syntaxes pour faire des groupes dans les textarea libres pour les valeurs de select. Mais pour les radios et cases là je me souviens pas d’ajouts.
j’ai du confondre avec autre chose, je retrouve pas.
Répondre à ce message
Bonjour,
Suite à une mise à jour, j’observe un problème très spécifique avec le plugin Champs_extra_interface. Cela concerne concerne l’affichage d’erreur si la condition de champs extra sont activé à la fois dans le champ « Afficher si remplissage » et dans le champ « Afficher si ».
Il me semble qu’il faille une condition « AND » entre le traitement de ces 2 champs. Si c’est le cas, je propose d’ajouter ligne 498 de « saisie_afficher.php » :
Mmm je ne connais pas assez le afficher si (pas du tout même) pour avoir un avis :(
Maieul ?
Les dernières versions du plugins suppriment ce double système d’afficher_si pour avoir juste une option qui conditionne le même où afficher_si s’applique.
Il n’est donc pas possible d’avoir plusieurs valeurs ?
Parce que, comme je le note ci-dessus, ça ne fonctionne pas...
Ni comme ça d’ailleurs :
Il faut faire un array ?
Si tu veux faire un test « ou », tu fais
Super ! Merci !
Répondre à ce message
Bonsoir,
d’abord désolé pour les accents, je n’ai pas de clavier azerty.
Dans un soucis de mise a jour de mon site de spip 3.0 -> spip 3.2, je viens de tester la zone de saisie de date utilisant le dateur de Bonus sur le squelette-dist du dernier spip 3.2 avec un Saisie compatible version 2.19.8 SVN [107777]. Avec un Bonus compatible version 3.4.6 SVN [107681] active, le Datepicker de Bonus n’apparait malheureusement pas.
Je l’avais auparavant sur mon propre squelette en spip 3.0 (je l’ai aussi teste sur le squelette-dist de spip 3.0) avec un plugin Saisie moins recent version 2.5.16 SVN [91819] et Bonus version 3.2.1 SVN [90054]. C’était impeccable.
Y-a-t-il un bug de la zone de saisie de date utilisant le dateur de Bonus avec le nouveau spip 3.2 ?
C’est le seul bug de ma mise-a-jour, pas de bol ;-(
Merci pour votre attention !
Sorry, fausse alerte : je pense que mon squelette était responsable du Bug. J’ai bidouille de sorte a mettre a jour quelques scripts de mon squelette et les choses sont rentrées dans l’ordre.
Spipement,
Répondre à ce message
Bonjour
Je rencontre un problème avec ce plugin lors l’activation de la compression JS (dans l’admin > Fonction avancées > Optimisations et compression > Activer la compression des scripts)
J’ai une erreur JS dans la console :
Ce qui correspond a cette ligne inclus automatiquement dans ma page au niveau du formulaire :
$("#afficher_si_1385088934").parents("form").change(function(){verifier_saisies_1385088934(this);});Qui est généré par le fichier saisies_afficher.php L.411 (plugins/saisies/inc/saisies_afficher.php) :
code .= '$("#afficher_si_'.$id_form.'").parents("form").each(function(){verifier_saisies_'.$id_form.'(this);});';Sans compression, aucun problème
Avec compression, l’erreur apparaît
Quelqu’un peut m’aider ?
Merci.
Ça sent le javascript de jQuery mais qui n’est pas inclus dans un entourage standard qui permet de le lancer seulement quand on est sûr que tout est chargé avant. Ce qui fait que ce serait lancé avant jQuery et que donc ça planterait puisque ça ne trouverait pas $.parents etc.
Répondre à ce message
Bonjour à tous
Juste pour signaler que sur un site 3,1 j’ai une petite erreur dans la console de mon navigateur :
ReferenceError: Can't find variable: jQuerysur le fichier saisies.jsavec mon formulaire (formidable)
Pourquoi ?
(le site fonctionne et je n’ai pas de conflit jQuery )
Merci de votre aide
Re,
Je réponds, j’ai effectué un nettoyage dans mon html ( notamment balise
en doublon)
et tout est rentré dans l’ordre.
Merci encore aux personnes présentes sur irc #spip qui sont là entre autres à veiller au grain du Core, mais aussi à dépatouiller les âmes en détresse ;)
Cordialement.
Répondre à ce message
Bonjour,
Je trouve deux chaînes codées en dur dans le fichier saisies_doc.html
Peut-être une petite modification pour une prochaine version de cet excellent plugin ?
Cordialement,
Hanjo
Répondre à ce message
Bonjour,
sans conséquences notables à ce moment, voici les messages (que je trouve alarmants inutilement) sur un mise à jour de quelques plugins :
Erreurs survenues (donc en rouge)
Impossible d’activer le plugin ../plugins/auto/saisies/v2.18.1
Utilise le plugin VERIFIER en version ≥ 1.6.0.
Impossible d’activer le plugin ../plugins/auto/ieconfig/v1.3.1
Impossible d’activer le plugin ../plugins/auto/jeux/v3.4.1
Impossible d’activer le plugin ../plugins/auto/menus/v1.6.5
Nécessite le plugin ZPIP
Nécessite le plugin SPIPR
Nécessite le plugin SPIPR_BLOG
Nécessite le plugin SPIPR_DIST
Nécessite le plugin SPIPR_DOC
Impossible d’activer le plugin ../plugins/auto/fbantispam/v1.2.3
Impossible d’activer le plugin ../plugins/auto/noizetier/v2.5.0
Impossible d’activer le plugin ../plugins/squelette_maparaan
Nécessite le plugin TYPOENLUMINEE
Nécessite le plugin GRAVATAR
Nécessite le plugin SLOGAN
Impossible d’activer le plugin ../plugins/auto/formidable/v3.0.1
Utilise le plugin COLLECTIONJSON en version ≥ 1.5.0.
Utilise le plugin CVTUPLOAD en version ≥ 1.9.4.
Utilise le plugin CORBEILLE en version ≥ 3.1.0.
Impossible d’activer le plugin ../plugins/auto/aveline/v2.5.7
Utilise le plugin ZVIDE en version ≥ 2.0.0.
Utilise le plugin SUIVANT_PRECEDENT en version ≥ 1.3.1.
Utilise le plugin ANYTHINGSLIDER en version ≥ 2.0.0.
Actions réalisées (en vert = OK)
La mise à jour du plugin « Saisies pour formulaires » (de la version : 2.17.1 à 2.18.1) s’est correctement déroulée
La mise à jour du plugin « NoSPAM » (de la version : 1.5.15 à 1.5.16) s’est correctement déroulée
La mise à jour du plugin « Facteur » (de la version : 3.4.8 à 3.4.9) s’est correctement déroulée
L’installation du plugin « Facteur » (version : 3.4.9) s’est correctement déroulée
La mise à jour du plugin « API de vérification » (de la version : 1.4.2 à 1.6.0) s’est correctement déroulée
Ces problèmes (ordre pas toujours correct des plugins à activer) sont corrigés en version 3.2 de SPIP (actuellement en beta), ce qui enlève la plupart de ces fausses erreurs.
Répondre à ce message
Bonjour,
Pouvez-vous me dire s’il est possible d’associer à un champ input un élément « datalist » de manière à avoir non seulement la possibilité de saisir une valeur mais également une liste de valeurs possibles. La fonction autocomplete peut être une piste mais elle ne prend en compte que les valeurs déjà saisies par l’utilisateur alors que je voudrais m’appuyer sur une liste de choix déterminée. Merci pour votre retour
Pour le moment ce n’est pas possible, mais on peut ajouter cela (mais perso je n’ai pas le tps en ce moment)
Euh si si c’est déjà possible hein. Il faut envoyer l’options « datas » dans la saisie « input », avec la liste des valeurs, cf le code
https://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/trunk/saisies/input.html#L27
a oui, je suis resté coincé dans le passé… désolé. J’ai mis à jour la doc de références.
Répondre à ce message
Bonjour,
Est-il voulu que sur une saisie de type
radioet obligatoire (en html5) il n’y ait pas derequired="required"sur l’input correspondant ?C’est peut-être un oubli oui, mais note quand même que normalement pour des radios, en ergonomie il *devrait* y avoir l’un des boutons déjà coché, car ce sont des radios et qu’on ne ensuite jamais revenir à l’état « pas coché ».
Pas d’accord avec toi. Car avec une option déjà coché, au cours le risque que la personne ne vérifie pas la valeur.
Ex avec deux choix : « j’autorise à prendre des photos » / « je n’’autorise pas ». Si je coche par défaut l’un des deux je risque de ne pas réeellement recueillir le consentement
Il peut sûrement y avoir des exceptions mais c’est une mauvaise pratique la majorité du temps.
Le W3C dit
Vos deux points de vue se valent !
Dans mon cas c’est un simple choix de civilité Monsieur / Madame, mais qui est obligatoire.
Je ne peux pas préjuger de la civilité de la personne qui remplit le formulaire, je préfère donc que rien ne soit coché par défaut et qu’en cas d’oubli le fait que ce soit obligatoire « force » les gens à choisir la bonne civilité.
J’ai donc surchargé localement la saisie radio pour prendre en compte le required.
merci :)
Répondre à ce message
Bonjour,
J’ai rencontré un problème avec la fonction « afficher_si » sur des checkbox donc la valeur est composé de plusieurs mots. J’ai corriger ce problème dans le fichier « saisies_afficher.php » à la ligne 386 :
$condition = preg_replace('#@'.preg_quote($nom).'@#U', '($(form).find(".checkbox[name=\''.$nom.'[]\'][value=\''.$value.'\']").is(":checked") ? $(form).find(".checkbox[name=\''.$nom.'[]\'][value=\''.$value.'\']").val() : "")', $condition);Ajout de « \’ » dans « [value=’.$value.’] »
Cependant les valeurs contenant des espace et des « ’ » risque de poser problème non ? :)
j’avoue ne pas savoir. A tester non ? et puis il faut aussi du coup modifier un fichier qui effectue un test sur afficher_si lorsqu’on vérifie qu’un champ obligatoire est bien rempli
Répondre à ce message
Amélioration ?
Bonjour , je cherche à paramétrer et supprimer les 3 lignes envoyées dans l’email de confirmation à celui qui poste :
« Envoi via le site MONSITE
Vous pouvez voir cette réponse sur cette page.
Vous pouvez gérer l’ensemble des réponses sur cette page. »
Comment est-ce possible SVP ? Merci d’avance
(MAJ de V2.18.1 vers 2.18.2 sans soucis au passage)
Salut, je ne vois pas de quoi tu parles ni le rapport avec Saisies, ce plugin n’envoyant aucun email. Repose sûrement la question sur le plugin qui fait cet envoi dont tu parles. :)
oui effectivement , c’était pour toi mais dans le plugin Formulaires.désolé
Répondre à ce message
Bonjour,
Aussitôt que le plugin Saisies est actif, j’obtiens cette erreur javascript, qui bloque d’autres scripts.
Uncaught ReferenceError : onAjaxLoad is not defined
Pourquoi ?
Tu as testé en installant QUE le plugin saisies ? Sinon ça ne teste pas ce plugin uniquement mais la conjonction de plein de trucs.
Salut !
Je viens de désactiver tous mes plugins, et ça ne fonctionne pas plus. Toujours la même erreur.
Vincent
Je cite notre cher Edgard :
Parce que chezmoiçamarche © :p
Répondre à ce message
Bonjour,
Y a-t-il une raison spécifique pour laquelle le plugin insère ses fichiers JavaScript et CSS dans l’espace public à des positions « fixes » plutôt que de passer par les pipelines dédiés et d’utiliser les mécanismes #INSERT_HEAD et #INSERT_HEAD_CSS ? Ou est-ce juste un oubli ?
Merci !
Parce que ça ne les ajoute pas sur toutes les pages du site mais seulement quand ça trouve des saisies dans la page (car le cas le plus courant n’est pas d’avoir des formulaires sur toutes les pages du site, et encore moins des formulaires avec Saisies).
À priori le plugin n’insère ses trucs que s’il y a *vraiment* des saisies dans la page (la plupart des sites n’ont pas du tout des formulaires sur toutes les pages du site, inversement c’est plutôt une exception). Donc ça ne se fait qu’avec le pipeline affichage_final, quand on a disponible le contenu complet. Et non pas dans les pipelines qui ajoutent ça sur toutes les pages du site.
Répondre à ce message
bonjour
j’ai l’erreur suivante dans l’espace privée
Parse error : syntax error, unexpected ’@’ in /var/www/html/httpdocs/plugins/auto/saisies/v2.7.0/inc/saisies_afficher.php(448) : eval()’d code on line 1.
Aidez moi svp
C’est à priori que tu utilises l’options « afficher_si », et qu’il y a une mauvaise syntaxe.
Effectivement .
Merci beaucoup
Moi j’avais le message
Warning : Illegal string offset ’selection_1’ in /www/lesite/plugins/saisies/inc/saisies_afficher.php(448) : eval()’d code on line 1
Résolu en modifiant la ligne 448 du fichier saisies_afficher.php en : @eval(’$ok = ’.$condition.’ ;’) ; au lieu de eval(’$ok = ’.$condition.’ ;’) ;
Fonctionne maintenant sans afficher l’avertissement
Répondre à ce message
Bonjour,
avec cette config SPIP 3.1.1 - Saisies 2.7.3 - php 5.4.45, et le plugin formidable, j’ai le message d’erreur php suivant :
Warning : Illegal string offset ’selection_1’ in www/lesite/plugins/saisies/inc/saisies_afficher.php(448) : eval()’d code on line 1
Cette erreur survient uniquement quand avec formidable, je définis un champ de formulaire avec une condition d’affichage de type :
@selection_1@==« structure »
La syntaxe de la condition est-elle la bonne ? Je pense que oui. L’erreur disparaît lorsque j’enlève la condition.
Répondre à ce message
Bonjour,
Sur un SPIP version 3.1.0, avec le plugin Saisie 2.5.22, je développe un formulaire en CVT. Dans l’une de mes saisies, j’utilise l’option « afficher_si ». Or, mon champ s’affiche tout le temps et ne respecte pas la condition que je lui ai donnée.
En utilisant la version 1.42.6 de Saisie, la fonctionnalité marche correctement. J’ai regardé le code du plugin, et j’ai vu qu’avec la version 2.5.22, chaque champs est contenu dans un bloc « div », tandis que dans la version 1.42.6, chaque champs est contenu dans un bloc « li ». Malgré cette évolution, le JavaScript généré pour gérer l’affichage du champ veut travailler sur un bloc « li » alors que c’est une « div » qu’il faut récupérer.
Du coup, je pense que c’est un bug du plugin. Puis-je avoir un éclaircissement sur la question s’il vous plaît ?
Merci d’avance pour votre réponse :-)
Dans le javascript qui masque ou affiche les champs, je ne vois pas de référence à la balise
<li>pourtant.Le code a bien l’air d’utiliser uniquement des attributs : soit l’identifiant « data-id », soit la classe du bloc (par ex « .editer_truc ») :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/trunk/inc/saisies_afficher.php#L384
Est-ce que tu vois des erreurs javascript dans la console (de Firefox par ex) quand tu charges la page ? Si un autre script JS plante en amont, ça arrête TOUT le javascript entier, et donc tout ce qui suivra ne sera jamais exécuté.
Effectivement, le code n’utilise aucune référence à la balise
li.Mais, je me suis rendu compte que mon code surcharge le fichier
saisies_afficher.php, et ajoute systématiquement, en dur, la baliselidevant l’identifiant « data-id » ou devant la classe du bloc, comme dans l’ancienne version de Saisie. Donc le problème vient de mon côté.J’ai vu dans la fonction
saisie_balise_structure_formulaireque l’on retournediv, en dur, à la place delipour SPIP 3.0 :http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/trunk/saisies_fonctions.php#L25
Est-ce qu’il existe une alternative à cette balise écrite en dur, comme une GLOBAL qui contiendrait la balise que l’on veut utiliser pour nos blocs du formulaire ? Ou une autre solution qui ne perturberait pas le fonctionnement de mon site lors du mise à niveau du plugin ?
Merci pour votre réponse précédente !
Non ce n’est pas personnalisable par une variable. Le plugin Saisies suit la structure « officielle » recommandée pour SPIP, et à partir de la version 3.1, tous les ul/li ont été viré et remplacé par des div plus neutre, justement pour corriger des problèmes d’accessibilité. Donc le plugin ne fait que suivre cela. Mais ce n’est pas normal si le JS ne marche plus à cause de ça (mais si c’est juste à cause d’une surcharge de votre côté ça va : faut pas surcharger comme ça :D)
D’accord, c’est noté. Je vais corriger sa de mon côté.
Merci pour les informations et pour la rapidité des réponses ! ;-)
Répondre à ce message
Bonjour,
Après mise à jour de spip 3 vers spip 3.1 (et Version 0.15.5 du plugin Contact avancé et version 2.5.22 pour Saisies), je vois apparemment un petit « bug » quand j’envoi un message avec le formulaire. (peut-être que c’est plus ancien et que je ne l’avais pas vu)
Avec la prévisualisation, j’ai un message : « Il y a 2 erreurs dans votre saisie, veuillez vérifier les informations. » Sauf que je ne vois pas d’erreurs dans ma saisie (les champs obligatoires sont remplis), et quand j’envoie le message en confirmant l’envoi ça part, et je reçois le message.
C’est gênant car ça peut dissuader l’envoi en faisant croire à une erreur.
exemple ici : http://art-engage.net/Contact-artiste-David-Myriam.html
Merci pour toute piste utile, j’ai posté aussi sur la page du plugin Contact Avancé, car je ne sais pas au juste à quel niveau ça se passe...
Résolu par le plugin Formulaire contact avancé. :-)
ca ne concernait pas Saisies
Répondre à ce message
Bonjour,
Aprés une mise à jour 3.1 le plugin saisies plante spip -page blanche dans la zonne administration et public-.
Cela n’est que sur un ordi upgradé d’ubuntu 12.xx à 14.04. Quelles librairies linux sont utilisées par le plugin et en quelle version ?
C’est très bloquant car saisies est indispensable pour entre autres la fabrique.
Merci
Qu’est-ce qui te fais dire que c’est Saisies qui contient le code qui fait planter ? As-tu un message d’erreur PHP quelque part ? Sinon, il faut activer l’affichage des erreurs PHP, car une page blanche ça signifie à priori « Fatal Error » de PHP :
Bonjour,
Uniquement parce que dés que je charge et demande l’activation de saisies, aprés la phase de chargement j’obtiens une magnifique page blanche.
Ou mettre les deux lignes que tu me propose pour avoir les messages php ?
MErci bien
Dans
config/mes_options.php(avec<?phpau début du fichier évidemment)Cher RASTAPOULOS,
Et voila le résultat :
Fatal error : Cannot redeclare selecteur_lister_objets() (previously declared in /var/www/html/ecrire/inc/filtres_selecteur_generique.php:30) in /var/www/html/prive/formulaires/selecteur/generique_fonctions.php on line 10
A toi de voir
Une démarche ’docteur’
Merci bien.
T’es sûr que tu as bien mis à jour comme il faut ?
Parce que dans
prive/formulaires/selecteur/generique_fonctions.php, désormais il n’y a justement plus QUE une inclusion deinc/filtres_selecteur_generique.phpavec la fonction SPIPinclude_spip()qui n’inclue jamais deux fois la même chose.Regarde ce que tu as dans generique_fonctions car il n’y a PAS 30 lignes en 3.1 (ton erreur dit « déjà déclaré ligne 30 »).
Bingo ! RastaPopoulos
Le fichier generique_fonctions.php avait : 184 lignes !
J’ai remplacé le dossier privé de ce SPIP par celui récupéré pour une nouvelle installation et la tout est redevenu ’NORMAL’.
Il est probable que la mise à jour s’est plantée ou du moins n’a pas tout bien fait. Peut être une question de marche de spip_loader.php.
Merci bien et félicitations pour ta dextérité.
Alain BOURDEAU
Répondre à ce message
Bonjour RastaPopoulos
Quand on créé un modèle de saisie perso, le plugin encapsule automatiquement un
<li>...</li>autour du code défini dans le modèle perso.Si je donne un paramètre « label » dans ma #SAISIE, alors le plugin génère le code
<label>....</label>Est-il possible de désactiver ce comportement pour ma saisie perso ?
c.a.d pas de
<li> et de <label>Pour info, j’ai créé une saisie perso avec les classes css de bootstrap, donc qui n’utilisent pas de
<li>Et mon label est utilisé dans le placeholder. Donc pas de
<label>.Cette saisie me permet d’afficher une icone à gauche de l’input.
MERCI
J’ajoute que l’icone que je veux rajouter à gauche de mon input est un glyphicon de bootstrap.
Donc cela ne peut pas être fait avec un background-image en css.
Je dois ajouter le code
<i class="icon-xxx">/<i>à gauche de mon input.Ce qui implique de modifier le code html habituellement utilisé dans SPIP.
Je continue mon monologue...
En regardant de plus près le fichier _base.html, qui, comme son nom l’indique, est appelé pour chaque saisie, je vois qu’il vérifie si type_saisie (par ex input_icone) est défini dans le tableau saisies_autonomes.
Si c’est le cas, la saisie perso (input_icone.html) est directement inclue, sans ajout des
<li>et autres traitements standards.Pour ajouter la nouvelle saisie dans saisies_autonomes, il faut utiliser un pipeline. Voir http://contrib.spip.net/Saisies-fai...
A priori, cela pourrait correspondre à mon besoin.
Mais...
Il serait tout de même plus judicieux d’utiliser la saisie INPUT existante. Et de jouer avec les CSS pour ajouter mon icone à gauche de la saisie. En utilisant le sélecteur li.editer_xxx:before (xxx nom du champ).
J’ai aussi plusieurs classes css à ajouter dans le li et le input, pour que cela fonctionne. Je pense pouvoir me débrouiller avec les paramètres li_class et class.
Répondre à ce message
Bonjour,
Suite à une mise à jour de spip en 3.1 depuis une 3.0.21 en local, le plugin saisie bloque le site.
Même après une mise à jour depuis spip_contrib.
Avez-vous eu cette erreur ?
Et quelles pistes possibles ?
Merci Alain
Répondre à ce message
Bonjour,
je souhaiterai que la personne qui a rempli le formulaire puisse avoir un N° unique en retour dans son email (pour faire un « RMA » = N° de retour atelier ).
Je pensais mettre le N° du formulaire rempli (« Id » que l’on voit dans le tableau des réponses).
Comment intégrer ce N° Id dans la réponse email SVP ?
Merci d’avance.
Tu confonds pas avec le plugin Formidable ?
Mais dans tous les cas, ce dernier a des traitements totalement séparés et il n’y a pour l’instant pas de moyen de savoir à coup sûr l’ordre d’exécution des traitements. En conséquence, il n’est pas possible d’être sûr que l’enregistrement en base (produisant alors un identifiant SQL) soit fait AVANT le traitement « envoyer par email ». Et du coup dans l’email on a pas moyen d’être sûr d’avoir un enregistrement en base sous la main.
En revanche on pourrait imaginer que tu ajoutes un champ « hidden » et que tu notes son nom (hidden_1) puis, si tu appelles ton formulaire en squelette uniquement (ça ne peut pas le faire pour un appel dans un contenu avec le modèle), tu peux pré-remplir le champ avec une valeur quelconque, donc tu peux produire un identifiant aléatoire et mettre la valeur dans « hidden_1 » au moment de l’appel (cf la doc de Formidable, appel en squelette, il y a un paramètre tableau pour pré-rempli les champs).
Bonjour,
merci de ta rapidité . C’est vrai je confonds, mais avec Forms&Table 2.5 .
Je vais tenter de ce côté là. Merci et désolé.
Répondre à ce message
Bonjour RastaPopoulos, avec SPIP 3.0.20, suite à la récente mise à jour saisies (2.5.20) l’enregistrement des traitements dans formidable (à jour : 2.9.5) semble perturbé.
J’ai bien la réponse :
Traitements activés
- Envoyer par courriel
- Enregistrer les résultats
Mais on dirait que la configuration n’est pas conservée. Je retrouve en cliquant sur « configurer le traitement » les cases « non cochées » suivantes :
- Envoyer par courriel
- Enregistrer les résultats
- Paiement
Et puis surtout la valeur des champs par défaut affiche désespéramment 1.
En revenant à l’ancienne version 2.5.19, tout rentre à nouveau dans l’ordre.
C’est corrigé en 2.5.21, merci du signalement
Répondre à ce message
Bonjour,
j’essaye d’obtenir un formulaire de réservation simple avec #SAISIE de date + horaire en utilisant le dateur de Bonux (plugin à jour).
Dans mon squelette de formulaire, tant que option « horaire=oui » est absente, tout va bien :
- >Date : 27/11/2015
Dès que j’utilise l’option « horaire=oui », la date affichée en prévisu devient « array », comme si aucune donnée de date n’était plus transmise par le formulaire :
- >Date : Array
C’est un problème connu ? J’ai beau farfouiller, je ne trouve pas de piste pour lever le problème.
Si quelqu’un a une piste... Merci d’avance.
LExi
Ma config :
SPIP Bonux 3.2.1 - stable
Saisies pour formulaires 2.5.16 - stable
SPIP 3.0.17 [21515]
Formulaire en question sans saisie d’horaire
De quelle prévisualisation tu parles ?
Il me semble que ça génère deux champs mais avec le même « name », avec les deux valeurs dans deux clés du même « name » : name=truc[date] / name=truc[heure]
Quelque chose dans ce genre : il suffit de regarder le HTML généré une fois que tu as activé l’option.
C’est donc à toi de récupérer correctement les valeurs suivant les champs que tu génères. Donc récupérer
#ENV{truc/date}et#ENV{truc/heure}et non pas juste#ENV{truc}Très juste, Rastapopoulos ! J’aurais dû y penser. J’ai trouvé deux inputs avec deux noms différents, du type name=« ma_date[date] » & name=« ma_date[heure] ». Cela fait sens avec l’obtention d’un « Array » à la place de la date dans le formulaire de prévisualisation. Merci de ton aide précieuse.
Ainsi dans la partie prévisualitsation de mon formulaire en html, je charge la date avec par exemple :
Je remarque cependant que, dans le fichier php, la fonction charger liste avec succès dans la variable $valeurs le champs de date comme un champs unique.
Comment traite-t-on ce champs pour l’envoyer à l’auteur ? Dans la fonction traiter, si je demande
... Je me retrouve de nouveau avec un array dans le email de réception.
J’ai essayé sans succès
Comme il est incompétent en php, il est de nouveau paumé le gars là. ;-)
Bé non,
_request('ma_date')est un tableau, donc il faut le récupérer tel quel dans une variable. Puis demander les deux clés$ma_date['date']et$ma_date['heure'].Message reçu. Mais ça, je ne suis actuellement pas capable.
Mais j’ai trouvé ça pour zapper la récupération dans une variable : selon Programmer Spip _request, si on souhaite récupérer certaines valeurs présentes dans un tableau, on peut passer ce tableau en second paramètre :
Or dans la fonction traiter de CVT
ne fonctionne pas. Selon ta remarque, il aurait été logique qu’il en fûsse autrement ;-). Ou il y a un truc qui m’échappe de nouveau ?
J’ai pas pigé de quoi tu parles, t’es pas capable de quoi, puisque tu fais déjà du PHP ?
Ya juste UNE ligne en plus par rapport au code que tu avais avant hein… Par exemple :
Moi j’ai pigé de quoi tu parles, et ça marche. Le php, c’est pas mon terrain de jeu. Voilà pourquoi je fais appel à spip depuis de si longues années. Donc je résume pour les nuls, qui flânent sur ce forum :
Pour utiliser #SAISIE de date + horaire en utilisant le dateur de Bonux, j’active le champs horaire avec la class class=« date heure » l’option horaire=oui. Exemple :
Dans la partie prévisualisation de mon formulaire en html, on récupère les valeurs saisies par :
Pour la partir php, dans la fontion traiter, _request(’ma_date’) est devenu un tableau, donc il faut le récupérer tel quel dans une variable. Puis demander les deux clés $ma_date[’date’] et $ma_date[’heure’].
A la bonheur !
Répondre à ce message
Bonjour, j’ai installé la dernière version du plug-in. Mais l’installation ne se fait pas correctement. Quand j’active le plug-in, j’ai bien le message qui me dit que l’activation du plug-in s’est correctement déroulée. Mais en fait il n’apparait pas dans la liste des plug-ins activés et reste dans la liste des plug-ins inactifs. Merci d’avance pour votre aide.
François
Répondre à ce message
Bonjour,
Je viens de faire la dernière màj du plugin « saisies » en version 2.5.17.
L’option html5 est postée sur mon site.
Pour la saisie suivante :
Je me retrouve dans le source de la page avec required=« required » !!
Est-ce normal ou ai-je raté quelque chose ?
Mais du coup, une sélection (non vide) est devenue obligatoire.
Merci par avance d’une explication ;-)
Il y a eu un ajout il y a 3 jours pour signaler en HTML5 que les listes déroulantes pouvaient être obligatoires.
Mais la modification que je vois test bien que la variable « obligatoire » soit présente ET différente de « non » pour s’activer. C’est là :
http://zone.spip.org/trac/spip-zone/changeset/91915/_plugins_/saisies/trunk
Donc je ne comprends pas comment en ayant « obligatoire=non » ça puisse l’activer…
Oui je lis bien la même chose et suis aussi surpris.
Si la condition n’est pas vrai, quelle peut-être la valeur de required ? Ne peut-elle garder une valeur précédente par défaut ?
Je reviens sur l’attribut ’obligatoire’ de la fonction ’selection’ :
J’ai supprimer l’attribut dans le paramétrage de la balise #SAISIE de mmon formulaire pour retrouver le fonctionnement d’avant évolution.
Mais sans comprendre l’origine du problème :-( J’ai simplement utilisé le premier terme de la condition (obligatoire existe : non).
Répondre à ce message
Bonjour,
J’aimerais savoir si il y a un moyen d’empêcher de sélection une date antérieur à la date du jour ?
C’est pour un champ date avec le pickdater...
Merci d’avance !
J’ai trouvé une solution avec jquery pour avoir comme date minimum celle du jour :
<script type="text/javascript">
$(document).ready(function() {
$('#champ_date_identifiant').datepicker("option", "minDate", new Date('[(#DATE|affdate{'Y/m/d'})]'));
});
// --></script>
En espérant que ça en aide d’autre !
Gilles L.
Et sinon c’est normalement possible à partir de ce commit :
https://core.spip.net/projects/spip/repository/revisions/21482
En envoyant dans la saisie l’option « attributs » avec dedans
data-yearRange="truc". Avec « truc » étant ce qu’on veut, je connais pas la syntaxe.Après avoir chercher un moment :
Si ça peut aider ....
Répondre à ce message
Bonjour,
Je cherchais à utiliser les codes de langue pour internationaliser mon formulaire en utilisant un fichier YAML pour générer mon formulaire. J’ai essayé avec :
Mais ça m’écrit « <:coordonnees:label_voie :> » dans le formulaire sans traduction.
Est-ce qu’il existe déjà une méthode prévue dans le plugin Saisie ou dans YAML pour effectuer la traduction des éléments label ? Ou faut-il se le faire à la main en parcourant récursivement le tableau après importation du fichier YAML et en appliquant la fonction _T sur les clés ’label’ du tableau ?
Si tu utilises bien
#GENERER_SAISIES{tableau}, ya déjà la fonction_T_ou_typo()qui est appliquée partout, donc ce n’est pas normal que ça ne soit pas déjà traduit.Salut Rastapopoulos,
J’ai identifié ce qui ne marche pas mais je ne trouve pas la solution au problème. Lorsque j’effectue yaml_decode_file, j’obtiens bien des :
'label'=>'<:coordonnees:label_voie:>', etc.Ensuite quand j’effectue un
[(#VALEUR**|var_dump)]dans le squelette inclure/generer_saisies.html, j’obtiens des :'label'=>"<:coordonnees:label_voie:>"Et du coup, la fonction _T_ou_Typo ne fait pas son boulot... Je n’arrive pas à trouver l’endroit ou les chaînes du tableau transmis à generer_saisies est transformé en entités HTML.
Ben dans charger(), toutes les valeurs de formulaire (= destinées à des champs HTML) sont échappées. Les autres doivent être envoyées avec un souligné devant :
array('_saisies' => $saisies)Youpi, merci, ça marche !
Avec dans ma fonction
charger:Et dans mon squelette :
[(#GENERER_SAISIES{#ENV{_mes_saisies}})]Tout fonctionne parfaitement ! Dans la doc, le paragraphe sur la balise
#GENERER_SAISIEmérite peut-être d’être amendé pour signaler cette subtilité ? Je crois que peu de personnes sont au courant du truc. Par exemple dans le plugin coordonnees, il est fait appel à la fonction_Tdans la fonctionchargerdans la déclaration du tableau transmis à#GENERER_SAISIE.Au fait, pour les curieux, le coup de l’underscore est expliqué ici : http://programmer.spip.net/Charger-les-valeurs-du-formulaire ... J’aurai pu effectivement trouver la solution en grattant encore un peu, enfin... en creusant beaucoup :)
Faut faire attention quand même : ne pas échapper des éléments risque d’entraîner des trous de sécu sérieux (de type XSS au moins). Le problème par rapport aux codes de langue c’est, à mon avis, qu’ils devraient être traités avant que le nettoyage html ne soit effectué.
@Gilles, « échapper » c’est une opération qui sert à protéger ce qui vient de l’extérieur, soit de l’environnement, soit d’une soumission de formulaire, etc. Là on parle d’un tableau PHP codé par un⋅e dev, le contexte est donc totalement différent. Et c’est bien pour ça qu’il existe les clés avec soulignement « _truc » dans le charger() de CVT : pour que les devs passent des valeurs internes sans rapport avec l’extérieur, et donc sans passage par l’échappement (qui peut casser bien d’autres choses que juste les chaînes de langue, ça ne suffirait pas de gérer juste ça).
Répondre à ce message
Bonjour
j’utilise la saisie des dates et j’aimerais savoir si on pouvait récupérer la valeur au format date directement Y-m-d plutôt que d/m/Y ?
Cordialement
Les saisies ne s’occupent que d’afficher des champs, pas de les traiter. Donc soit tu dois faire ça à la main (dans verifier() ou traiter() du CVT), soit tu peux utiliser le plugin Vérifier qui contient une vérification de date, et dans celle-ci il y a une option de normalisation de la valeur en datetime (avec l’heure par contre, quitte à ce qu’elle soit à 00h00, il faudrait peut-être ajouter une option date sans time).
OK, merci
J’ai bien assimilé que saisies ne s’occupe que d’afficher les champs. C’est tout de même saisies qui renvoie la date cliquée à un certain format. Je pensais que l’on pouvait choisir ce format..
Je vais donc garder ma solution actuelle de modifier le format dans la partie traitement.
Merci pour la réponse rapide
Théoriquement il y aurait la possibilité de changer le format de la valeur au tout dernier moment en JS, mais ça veut dire que ça obligerait à JS et que ça ne marcherait pas sans, ce qui est mal.
Là le fait de le faire après, ça permet qu’au niveau interface ça soit au format humain habituel (et dans l’ordre FR par défaut), mais qu’ensuite pour le traitement on le passe en format SQL-friendly.
Répondre à ce message
Bonjour,
j’essaie d’utiliser l’option valeur alternative pour les checkbox mais elle n’est pas fonctionnelle, la valeur est bien enregistrée, mais n’est pas récupérée par le champ dans le formulaire. Le problème a été signalé ici https://www.mail-archive.com/spip-zone@rezo.net/msg35064.html, une solution a t-elle été trouvée ? merci d’avance
corrigé par http://zone.spip.org/trac/spip-zone/changeset/91257 (par contre ni l’un ni l’autre des messages n’est clair... il fallait comprendre à quel moment c’était censé s’afficher et cela ne le faisait pas)
super, merci beaucoup et désolé du manque de clarté.
J’ai un souci si cette valeur alternative contient une apostrophe, en base et dans saisies/checbox.html ça va bien, mais pas à l’affichage en squelette dans une boucle avec
{valeur LIKE %(#GET{valeur_demandee})%}, l’apostrophe bloque... merci encorepas sûr encore une fois de comprendre. on pourrait avoir une boucle plus détaillé ? le valeur est censé être le champ ? et le
#GET{valeur_demandee}contenir une apostrophe ? et que veux tu dire par « bloque »ah oui, re flûte, j’avais
#GET{valeur_demandée}parceque j’ai essayé de filtrer avec texte_script, mais sans succès. en fait la boucle c’estoui les champs bd c’est
situation_actuelle_type_emploietsituation_precedente_type_emploi_1#ENV{type_emploi}est un parametre urlla boucle ramène tous les auteurs quand
#ENV{type_emploi}contient une apostrophe ...ce n’est pas un problème lié à saisie, mais un problème plus général aux caractères spéciaux dans #ENV.
Le pb : #ENV transforme les caractères spéciaux en entités HTML (voir par exemple avec un
[(#ENV{toto|var_dump)])la solution : demander le champ semi-brut, avec une astérisque :
#ENV*{toto}. Attention ne mettre bien qu’une astérisques et pas deux, sinon risque de potentielle faille de sécurité.bingo, la bonne étoile s’appelle Maieul ;) résolu, mille mercis
Répondre à ce message
Bonjour
Je voulais télécharger la Version 1.42.6 sur cette page, mais le lien est cassé !
Si ça peut être réparé, je serais content....
Merci !
Répondre à ce message
bonjour,
il semblerai que les liens de téléchargement soient mort :-\
merci d’avance à vous !
J’ai changé le nom des ZIP ce matin. Il faut attendre que le robot passe sur Contrib pour mettre à jour automatiquement l’article (oui on a un robot pour ça, c’est magique :D).
super :-)
merci pour votre travail !
les archives sont de nouveaux disponibles !merci pour le job ! :)
Répondre à ce message
Bonjour
MERCI de votre aide
MERCI de votre attention
Spip 3.0.19
Processus de don pour une association
Comme administrateur, au passage en backend de
http://sourirepourlespoir.org/spipe
Erreur
Message
Numéro 1
Message Aucun squelette n’est disponible
Squelette plugins/auto/saisies/v2.2.1/saisies/_base.html
Boucle /
Ligne 0
NB :
la désactivation réactivation des plugins
(liés)
Formidable 2.8.9
Formulaire de paiement 1.0.4
Saisies pour formulaires 2.2.1
Formidable de participation Formidable 1.0.2
Fusion de formulaire pour Formidable 1.0.1
Spip Cycle2
fait bien disparaitre et ré apparaitre l’écran d’erreur
Aucun squelette n’est disponible
Pouvez vous me donner une piste pour aller plus loin dans l’analyse sinon la solution
MERCI
Cette erreur parle d’une saisie « montant » qui n’existe pas dans Saisies mais qui est propre au plugin de paiement. Donc je pense que tu devrais poser cette question aux gens qui maintiennent ce plugin. :)
pour RastaPopoulos
Merci de votre réponse
Juste en ajout au problème évoqué
Cette alerte
« Aucun squelette n’est disponible
Squelette plugins/auto/saisies/v2.2.1/saisies/_base.html »
n’est PAS
présente sur la même base de donnée
chez le même hébergeur
avec la même version de php
... mais un site en Spip 3017
je vais de ce pas voir du côté des plugins de paiements
pour moi
banque&paiements 2.32.1
mais c’est peut être aussi un problème spip 3.0.17 spip 3.0.19
MERCI de votre aide
Répondre à ce message
Suggestion d’amélioration pour la
saisie/date.html:- pour pouvoir passer des paramètrages au inc-dateur (standard de spip 3),
il faudrait en fin de saisie/date.html, rajouter un paramètre
,envà la ligne :
[(#INCLURE{fond=formulaires/dateur/inc-dateur, env, heure_pas=#ENV{heure_pas,30}})]], ou au moins transmettre une chaine/array d’options : je l’ai fait dans une surcharge perso mais..Est-ce un problème au niveau du cache de cette noisette ?
Merci
YannX
PS : exemple d’utilisation : transmettre un «
yearRange: 'c-100:c+1',» (pour pouvoir facilement saisir l’année de naissance) ou un format de date de saisie en fonction du langage !Répondre à ce message
Bonjour,
J’ai besoin de créer une nouvelle saisie spéciale qui n’a pas à accéder à un champ de la bdd (comme fieldset) mais qui doit par contre récupérer une variable dans l environnement de la page (id_auteur), et.... j’y arrive pas....
J ai créé mon couple de fichier html et yaml, je me dis que depuis le yaml faut p’etre passer un paramètre au html (comme pour les noisettes du noizetier) ?
J’utilise cette saisie avec les champs extra depuis l interface extra (je ne sais si ca change quelque chose)...
amicalement
triton
Mmmh je ne sais plus si c’est possible déjà. Ça me dit quelque chose que quelque part dans le code (ouais c’est hyper vague) il y a un endroit qui teste si on doit passer tout l’environnement ou seulement une partie précise nécessaire. Mais de tête je ne me rappelle plus des conditions.
Je dis ça, c’est pour l’API PHP où on génère pleins de saisies à partir d’un tableau complet. Quand c’est saisie par saisie avec la balise unitaire, là je sais pas (sûrement juste ajoute « , env » dans les params).
Pas eu le temps de re-fouiller le code pour l’instant, désolé. :(
J ai contourné le pb en dupliquant une saisie de type input que je positionne sur mon champ id_auteur (en lecture seul) et a partir de cet id_auteur je vais chercher mes données dans ma saisie...
Je vais quand même essayer de lire le code voir si je trouve...
merci pour la reponse
amicalement
triton
Répondre à ce message
En voulant ajouter un nouveau champ (après en avoir ajouté d’autres sans pb) je rencontre cette erreur : Fatal error : Maximum execution time of 120 seconds exceeded in /www/plugins/auto/saisies/v1.40.7/inc/saisies.php on line 132
Pourriez vous m’aider ??
Si tu ajoutes des champs, c’est à priori que tu parles du plugin champs extras, qui lui même est utilisateur du plugin saisies. M’est avis que tu devrait plutôt poser la question dans le forum de ce plugin, si ce n’est pas déjà fait. :)
Répondre à ce message
Bonjour,
Je débute dans l’utilisation des formulaires pour mettre en place une procédure de dons sur le site http://www.cubacoop.org/
J’utilise les plugins ;
Formidable 2,8,0
Saisies pour formulaires 1.42.1
YAML1.5.2
Transaction 0.3.1
Mes premiers test semblent satisfaisants mais je ne comprend pas pourquoi après validation de la saisie d’une entrée dans le formulaire, le message de retour est affiché 6 fois au lieu d’une.
Merci de me dire où je peux corriger cet affichage multiple.
le formulaire peut être testé ici
Répondre à ce message
Bonjour,
je configure un formulaire avec Formidable avec ces versions : [ Spip 3.0.16 / Formidable 2.5.14 / Saisies 1.40.4 ].
La fonction pliable d’un groupe de champs fonctionne très bien en partie privée, mais pas du tout sur la partie publique.
J’ai fait les vérifications suivantes :
Rien n’y fait, mon groupe de champs s’affiche déplié et ne se replie pas au clic.
ERRATUM. Il s’agit de la version 3.0.5 de Spip. Et non pas la 3.0.16.
Ben si ça marche dans le privé et pas dans le site c’est que dans le site le JS n’est pas ajouté à priori. Ou alors qu’il y a une erreur JS en amont de l’activation du pliage. Regarde déjà dans le code (sans compresser le JS évidemment) si le fichier JS de Saisies est bien inséré dans ton site. Et ensuite regarde dans la console de Firefox s’il y a des erreurs JS.
Merci. Problème résolu.
C’est le script menuder.js du Plugin Menuder pour MSIE qui me faisait planter.
$ is not a function
Ligne 19 $(’.menuder ul’)
En désactivant le plugin, tout rentre dans l’ordre. Et je n’ai pas besoin de ce plugin.
Bonjour RastaPopoulos,
quand le JS n’est pas ajouté, ça peut être du à quoi ? Comment remédier à ça ?
Est-ce que je devrais voir si un autre plugin bloque le script comme chez niconito ?
d’avance merci pour toute piste
joz
C’est pas ajouté ou tu as une erreur JS en amont ? Tu peux voir ça dans la console javascript de Firefox quand tu recharges la page. Il faut regarder si le script est bien dans le HTML aussi, soit tout seul soit concaténé si la compression est activé (mais au début du fichier concaténé il y a la liste en commentaire).
hmm, je t’avoue que je ne sais même pas comment le script en question dois s’appeler.. du coup comment vérifier s’il est présent ?
je ne trouve rien qui s’appelle ’saisie’ ou ’plie’ en tout cas
http://vivre-ensemble.be/Bon-de-commande-2014
désolé pour mon ignorance..
joz
Avant le script, je te demandais en priorité de regarder d’abord s’il y avait une erreur javascript, comme pour niconito. Ce qui est effectivement le cas sur ton URL : « ReferenceError : trackPage is not defined » dans la console du navigateur (F12 sur Firefox, onglet Console).
Je ne sais pas ce que c’est, pas un truc de SPIP en tout cas.
merci d’avoir jetté un coup d’oeuil !
j’ai nettoyé l’erreur (trace d’un plugin installé dans le passé), mais le pliable reste toujours non-fonctionnel..
ai je oublié d’autre chose ?
T’aurais pas un plugin gredin qui utilise le pipeline « affichage_final » et qui OUBLIE de renvoyer le flux à la fin (et donc les plugins suivants n’ont pas le bon truc) ?
Comme d’hab, dans tous les cas, pour tester un pugin, il faut d’abord désactiver absolument tous les plugins non-nécessaires à son fonctionnement. Sinon ça fait trop de combinaisons possibles.
Bonjour,
c’est encore moi...
Je n’ai pas de plugin qui s’appelle gredin et je ne vois rien de se nom dans les erreurs, ni nulle part dans mon site (squelettes, cache.. nulle part)...
En local j’ai désactivé tout les plugins, sauf ceux nécessaire pour formidable + j’ai enlevé mes squelettes. Mais le pliable ne fonctionne toujours pas
:(
Aurais-tu encore une autre petite piste à suivre pour moi ?
d’avance merci !
joz
Haha : http://fr.wiktionary.org/wiki/gredin
Un plugin qui ferait des saletés donc. :)
Actuellement tout ce qu’insère normalement le plugin Saisies grâce au pipeline « affichage_final » ne se fait pas DU TOUT sur ton site. Donc il y a un problème en amont. Tu peux par exemple modifier directement le code du plugin pour débuguer, et dans saisies_pipelines.php, dans la fonction « affichage_final », tu fais n’importe quoi, genre
echo "PROUT"; die();pour voir si déjà SPIP rentre bien dans la fonction. Si ce n’est pas le cas c’est qu’il y a un autre plugin en amont qui gêne.hihi
chouette, j’ai appris un mot de plus en français :)
j’ai mis ta ligne echo dans mon saisies_pipelines.php, mais le site ne prout pas..
voici les plugins actuellement activés (tous à jour, SPIP 3.0.17 [21515] ) :
API
Facteur
Formidable
Saisies
SPIP Bonux
YAML
...
joz
Dans ton code source, il n’y a a aucun endroit le commentaire HTML « inserer_saisie_editer » alors que c’est sur cette chaîne que ce base le test pour décider s’il faut insérer ou pas des choses de Saisies.
C’est normalement ajouté par chaque saisie dans ce fichier de base :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/_base.html
L’aurais tu surchargé dans ton squelette ?
Bonjour,
j’ai re-essayé en mettant le echo PROUT au debut de affichage_final (avant je l’avais mis à la fin après return $flux ;), et maintenant ça marche, ça prout sans faute : )
Egalement avec mes squelettes et avec tout mes plugins activés.
Mais pour rendre le pliable fonctionnel, comment ce prout peut m’aider ?
Bien à toi
Je t’ai déjà donné une autre piste dans mon message précédent.
Le PROUT signifie que ça passe bien dans cette fonction, c’était le but de cette vérification. Mais comme je le disais précédemment, dans cette fonction on fait un test sur l’existence de la chaîne « inserer_saisie_editer » dans le HTML final, or elle n’apparait nulle part chez toi !
Alors que cette chaîne est normalement insérée pour TOUTES les saisies quelles qu’elles soient (donc autant d’apparition de cette chaîne que de saisie dans la page).
Tu dois avoir une surcharger de « _base.html » quelque part, un truc dans ce genre, qui supprime ce morceau.
Merci pour ta patience.. sorry pour ma lenteur.
Quand je change dans saisies_pipelines.php
la ligne 17
if (($p = strpos($flux,"<!--!inserer_saisie_editer-->"))!==false){en
if (($p = strpos($flux,"<!--!inserer_saisie_editer-->"))==false){(donc sans !), le pliable fonctionne.
...
J’ai installé un spip3.0.17 fraiche + avec formidable et ses plugins dépendant, sans mes squelettes, mais ma base de données. Et le pliable n’y marche pas !
Donc si quelque chose surcharge la fonction, est-ce que ce serai dans ma base ? Est-ce que ça serai possible ?
Si oui, pourrais-tu me donner une chaîne de caractères à chercher dans ma base qui pourrait être responsable d’un tel bloquage ?
Pour trouver le gredin ..
Il n’y a absolument rien à changer dans la fonction PHP, c’est ton HTML qui ne va pas, qui ne contient pas le commentaire HTML avec la chaîne recherchée.
Comme dit précédemment, c’est dans ce squelette :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/_base.html
Regarde son code, tu vois que ce commentaire est bien là. Donc si tu ne l’as pas chez toi, c’est soit que tu as une surcharge perso de ce squelette, soit que c’est directement dans ton plugin Saisies que le fichier n’est pas bon.
Ouvre donc plugins/saisies/saisies/_base.html et regarde dedans pour voir.
Sinon fait « var_mode=inclure » dans l’URL, pour voir les blocs inclus, et donc voir si ya une surcharge.
Répondre à ce message
Bonjour,
J’ai un soucis lorsque je charge un formulaire dans une modalbox depuis l’espace privé
mon js :
ma noisette ’mon_squelette’
Le formulaire s’affiche sans problème et fontionne mais :
Dans les logs firebug j’ai des 404 not found.
En regardant un peu le code du plugin et plus particulièrement la fonction saisie_affichage_final je m’aperçois que la fonction generer_url_public genere des liens de script et css de la forme :
http://mon.domaine.com/ecrire/plugins-dist/jquery_ui/css/jquery.ui.theme.css
Ce qui m’amène à vous poser plusieurs question :
Quel est la meilleur façon d’afficher un formulaire dans une modalbox ?
Est il possible de court-circuiter affichage_final sur une noisette appeler via /spip.php ?page=
Est-il possible de dire à saisie qu’on ne veut pas de qu’il charge de script ?
J’ai trouvé !
Je pense que la meilleur solution c’est de créer une page vierge dans l’espace privé en utilisant exec.
1°) Creer un repertoire exec à la racine du plugin
2°) Dans le repertoire exec creer un fichier « script.php »
3°) Puis dans l’appel pour modalbox mettre l’URL du prive qui va bien :
Et ça roule :D Merci spip !
Wow, c’est moche. :D
Déjà ça fait des années qu’on ne fait plus de exec en PHP…
Ensuite page=truc/sous/dossier, ça ne marche que pour les admins complets.
Il faut que ce soit une page accessible pour pouvoir y accéder, donc si c’est avec #URL_PAGE, ça doit être un squelette à la racine (à la racine de ce qu’on veut, squelettes, plugins, etc, mais à la racine d’un dossier du Path).
Quand on utilise un squelette de type Z (et l’admin de SPIP 3 est comme ça), on peut ajouter le paramètre « var_zajax=nom du bloc » dans l’URL, et ça va alors chercher uniquement ce bloc Z pour la page demandée. Tu peux donc parfaitement construire une vraie page d’admin avec le formulaire ET l’interface autour, il suffit de faire un squelette /prive/squelettes/contenu/truc.html. Et ensuite quand tu l’appelles, tu vas chercher
#URL_ECRIRE{truc, var_zajax=contenu}et ça va te donner que le bloc principal où il y aura ton formulaire.Mais sinon, à part ça, je vois pas trop le rapport avec Saisies (qui n’insère la CSS de UI que s’il y a une saisie de date de trouvée).
Ah oui c’est si moche que ça ? :D
J’avais bien utiliser le « var_zajax=contenu » mais les retours cvt ’ajaxés’ reviennent sur l’URL d’origine du bloc contenu.
En utilisant href :’/ecrire/ ?exec=article_edit&new=oui&var_zajax=contenu’, je charge bien mon formulaire de creation d’article, mais si je valide (je ne selectionne pas de rubrique par ex) le retour d’erreur redirige sur la page d’origine /ecrire/ ?exec=article_edit&new=oui
Mais il faut que ton formulaire soi bien entouré de div class=« ajax » dans le squelette, pour qu’il soit lui-même validé en ajax à chaque fois.
Ca marche Merci !
juste une remarque.
Donc en fait, juste avec la class .popin sur un <a href ds l’espce privé suffit ...
ça n’a pas de rapport avec saisies mais un peu avec mon problème de départ
Ah je ne me souvenais plus de ce point, merci du rappel !
Répondre à ce message
Bonjour,
et merci pour ce plugin qui simplifie bien les choses !
En évolution, sera t-il possible d’uploader un document, une image par exemple ? Ce serait génial !
Répondre à ce message
Bonjour,
J’aimerais savoir quelle format doit avoir la colonne d’une table sql qui reçoit les données de saisie ’checkbox’ ou cases à cocher ?
Spip 3.0.16 et Saisies pour formulaires 1.40.4 - stable...
Merci d’avance de votre aide !
Une table SQL ne reçoit pas le contenu d’une saisie HTML. C’est traité par CVT avant. Or les champs HTML checkbox, select multiple, et certains autres, génèrent au serveur (donc ici PHP) des tableaux (array PHP donc).
À chacun⋅e d’en faire ce qu’ille veut avant d’envoyer dans la base. Ça peut être dans une table dédié à ces choix (je sais pas, je ne connais pas le contexte moi), ou bien basiquement une sérialisation du tableau (
serialize()) donc une chaîne de caractère (donc un champ SQL « text » à priori).Merci de tes explications.
Je vais approfondir le sujet en me basant sont ta courte, mais ô combien utile, réponse.
Bien à toi !
Répondre à ce message
J’utilise plusieurs champs date dans mon formulaire à l’aide de saisie.
Cependant le code suivant ne me permet pas d’avoir le calendrier au clic sur l’icone :
car l’inclusion du « formulaires/dateur/inc-dateur » est double et empêche le bon affichage de celui-ci.
Pour que cela fonctionne, je dois faire :
Est-ce normal ?
Merci
Non ce n’est pas normal, mais il faudrait corriger le inc-dateur du noyau qui ne devrait pas insérer deux fois le même JS si on l’appelle plusieurs fois. Il faudrait un test avec une variable globale ou un truc comme ça pour savoir qu’il a déjà été appelé avant.
bonjour,
Comment faites vous pour utiliser le date_picker sur un champ date et enregistrer au format ’date’ ou ’datetime’ ?
le picker complete le champ en JJ/MM/AAAA et mysql veut du AAAA-MM-JJ
ya bien la solution
[(#SAISIEdate_jour_mois_annee, datet, obligatoire=oui,
label=<:date :>)]
mais si je veux un date_picker je ne comprends pas comment convertir automatiquement le format.
Est ce un réglage php ou une options dans saisies ?
Avec le plugin Vérifier, il faut utiliser la vérification « date » et activer la normalisation SQL.
Sans le plugin Vérifier, on peut faire la même chose à la mano dans la fonction verifier() de CVT.
Merci Beaucoup !
Va falloir que je me décide alors :|
Répondre à ce message
Bonjour,
je suis en train d’écrire un plugin qui crée un formulaire CVT.
Pour créer formulaire j’utilise le plugin saisies en initialisant le formulaire au sein d’un fonction _charger.
Ma fonction charger cree un tableau de valeur avec les valeurs par defaut une valeur [’mes_saisies’] contenant la liste des champs à la norme saisies.
Dans ma balise formulaire, le formulaire est généré par un appel #GENERER_SAISIES#ENVmes_saisies
Mon formulaire s’affiche correctement avec tout ses champs, mais j’ai dedans 2 champs avec un affichage conditionnel : afficher_si . Cette affichage conditionnel ne fonctionne pas !!
Pourtant le javascript gèrent cet affichage conditionnel semble être chargé dans la page.
Le formulaire en question est visible ici :http://chaps-a-chap.com/spip.php?article101. Je souhaite que si on choisit conducteur, le champs nb_passager soit masqué et si on choisit passager, le champ places dispo soit masqué.
Quelqu’un aurait une petite aide pour moi ????
Peut-être que ce commit corrige, mmh ?
http://zone.spip.org/trac/spip-zone/changeset/83524
Répondre à ce message
Bonjour,
Mon environnement : SPIP 3.0.16 [21266] | Sarka-SPIP 3.2.36 [77717] |
Je n’arrive pas à personnaliser mon « /squelettes/css/perso.css » de façon à ce que les différents éléments de type checkbox se trouvent sur la même ligne malgré les différents posts que j’ai lus :
Code de mon html :
code de mon php :
Le formulaire CVT fonctionne parfaitement mais j’obtiens une checkbox par ligne.
Je voudrais que les checkbox de la même balise Saisie s’affichent sur la même ligne.
C’était le cas sous Spip 2, je loupe sans doute quelque chose d’évident mais je ne vois pas quoi, une piste ?
Merci
Philippe
Ben ça c’est ton thème CSS qui fait ça (ou celui que tu utilises).
Il faut mettre les labels internes des saisies en « display:inline », en ciblant par exemple « .saisie_checkbox .choix label », un truc dans ce genre, je ne me rappelle plus du HTML par cœur.
Cela n’a pas suffit, je me suis rendu compte qu’il fallait que mon fichier de personnalisation des css se nomme « perso.css.html » et non pas« perso.css ».
Merci pour l’info
Répondre à ce message
Question plus simple cette fois (saisies ne me quitte plus), comment enchainer 2 trads quand on est en yaml ?
ex :
Merci encore
Je ne crois pas que ce soit possible. En PHP si, avec
_T()._T()Hello,
J’ai pas mal sué sur le YAML et les traductions.
En faite, tu dois dire à SPIP de foutre la paix a ton fichier YAML. Dans ta fonction fonction charger, quand tu passes le paramètre au formulaire :
Tu mes un « _ » devant le nom de ta variable, cela indique à SPIP de ne pas faire de traitement de sécurité.
Ensuite, tu balances tout dans #GENERER_SAISIES :
#GENERER_SAISIES{#ENV{_form_saisies}}Et normalement tes traductions fonctionnent.
Je baliserai aussi les traductions avec des ’ comme cela :
explication: '<:video:id_groupe_tags_explication:><:video:id_groupe_explication_archives:>'Voilà pour le YAML et les traductions !
Je ne saisis toujours pas l’intérêt de mettre ça dans un YAML, alors que Saisies contient une API spéciale pour les CVT, qui est de fournir une fonction
formulaires_truc_saisies_dist($args)qui renvoie un tableau de saisies.En plus ça fait faire des traitements supplémentaires (décoder du YAML).
Pour un formulaire de config classique (donc pas besoin de verifier() ni de traiter()), il y a juste à déclarer les champs et avoir un squelette vide.
Il suffit juste de :
formulaires_configurer_foundation_saisies_dist()Et c’est tout. Saisies s’occupe du reste.
Avoir un fichier très simple pour modifier un formulaire. Pour les formulaires très complexes, cela aide fortement. C’est un peu le but du YAML de renvoyer des tableaux.
Documenté nulle part sur cette page... Je ne savais même pas qu’une telle fonction était possible. Tu ne peux pas reprocher aux gens de ne pas utiliser des choses non documentées...
Dans le cas des formulaires d’admin, ce n’est pas trop grave. Dans le cas des formulaires publics, ce sera dans le cache de SPIP non ?
Ça à l’aire chouette, je fais le même reproche, pas de documentation...
Bref, tout cela à l’aire parfaitement faite et pensée, malheureusement, la documentation pour que tout le monde puisse s’en servir est absente, c’est dommage.
Dans la documentation ci-dessus il y a un bloc « Consultez également » avec un lien avec cet autre article de doc (sur le wiki pour l’instant car c’est un fourre-tout bordel) :
http://contrib.spip.net/Doc-Saisies-complementaire
Et notamment ce chapitre :
http://contrib.spip.net/Doc-Saisies-complementaire#autocvt
Bien sûr, avec moins de flemme, cela aurait vocation à être intégré dans cet article principal, ça c’est sûr. En tout cas au moins pour ce point-là.
Hello,
Merci, le pire c’est que je connais cette page, mais je n’y fais que des recherches précises.
Cela dit, cela ne résout pas vraiment le problème : on doit toujours écrire des tableaux PHP dans la syntaxe est vite rébarbative. Le YAML a justement vocation à être très lisible et facile à modifier/maintenir.
C’est juste une question de préférence cela dit...
Répondre à ce message
Bonjour,
Sur un SPIP 2.1.25 [21141] le plugin saisies Version : 1.38.6 [80094] donne une page blanche quand je veux l’activer. La version 1.14.0 [50422] elle s’installe bien.
dd
Chez-moi-ça-marche. ©
Pour tester, il faut bien entendu n’activer QUE ce plugin-là et rien d’autres. C’est ce que tu as fait ?
Répondre à ce message
Salut Marcimat,
Merci encore pour ce travail fantastique.
Dans tes exemples tu ne parles pas de lire_fichier, or j’ai réussis à faire marcher yaml_decode, uniquement grâce à cette fonction, sinon ca me renvoie l’url de mon yaml.
J’ai manqué un truc ?
Sinon merci encore
++
Charles
Mmmh es-tu sûr que tu postes dans le bon forum ? Parce que dans cet article il n’est a aucun moment question de yaml_decode(). :)
Salut Rastapopoulos
Je me suis en effet trompé de personne, j’ai lu trop vite et j’ai du croire que c’était Marcimat qui avait fait ce tuto (doc complémentaire).
Désolé.
J’ai relevé sur google un échange de mail que tu as eu avec plusieurs contributeurs et developpeurs dont mathieu, cedric, joseph. (le lien chez moi ne s’ouvre plus...???)
Tu proposes à un moment donné de generer les saisies en fnct de leur contexte aussi aurais tu des pistes qui vont en ce sens, je suis justement dans ce cas de figure ?
J’ai 5 yaml nommés Xstatut.yaml dans un dossier yaml d’un plugin, contenant - des champs communs mais à labels différents - et d’autres champs dédiés au statut.
Dans un pipeline declarer_champs_extra, je veille à ce que tous les champs de ces 5 fichiers soient présent en base, le cas échéant les créer grâce à l’option sql de la saisie manquante.
Mon CVT quant à lui est composé de 5 #SAISIEs de base et d’1 #GENERER_SAISIES#ENVmes_saisies.
Mes champs s’affichent bien et s’enregistrent.
MAIS : comme mes champs sont TOUS déclarer j’ai dans mon cvt tous les champs rédiger dans tous mes yaml.
Et c’est à partir de là que je m’arrache les cheveux. Je viens de comprendre déjà les pipelines, quelque chose doit m’échapper (intellectuellement) ...
Comment obtenir le #ENVmes_saisies contenant l’array du yaml correspondant au contexte de mon cvt et en l’occurence du statut d’un auteur ?
J’ai bien essayer de récupérer le statut en get, c’est sale, ca affiche du coup les bons champs des bons yaml relatifs aux statuts, mais le form n’enregistre plus.
Ma question est donc la suivante :
Comment passer à la fonction ci dessus - qui réside dans mon pipeline de déclaration des champs extra - le statut de l’auteur afin de disposer de 5 yaml parametrant un seul et même CVT ?
Bidouiller un second passage de variable à GENERER_SAISIES ? // Bof bof
N’utiliser qu’un yaml mais gérer des autorisations dans les descriptions des saisies // Je perd l’interet d’un yaml par statut or c’est l’enjeu.
Qu’en pensez vous chère communauté ?
Bien à vous
Charles
Vu avec marcimat sur irc, en fait le cache de la déclaration des champs extra ne permet pas trop ce genre de chose.
Je pense à la solution suivante :
Garder mes 5 yamls puis en rajouter un qui serait merger à tous
Et dans ma fonction foreach tester le fichier yaml et rajouter au tableau de saisies l’option de restriction qui va bien, le résultat est une seule declaration, bien cachée
Je ferais un retour d’experience ici même
En tout cas merci à Marcimat et Rastapopoulos
Bon, conclusion.
Ma solution révele que ce post n’est en effet pas au bon endroit
L’un étant lié à l’autre cependant j’ai solutionné mon problème en surchargeant autoriser_modifier_extra et en ajoutant un parametre d’option à mes champs dans mon yaml
Je dépose le code si quelqu’un pourrait être interessé :
++
Correction :
if ( ($autor !== $qui[’statut’] ) AND !( $autor == $statut[’statut’] ) )
Pas réussit à faire plus propre
Répondre à ce message
Aujourd’hui : Formidable -> Saisie et Mediaspip ?
J’avance comme je peux... Faute d’infos et de piste.
Une autre découverte (peut-être ?) serait la piste du plugin Saisie.
C’est dans le fichier plugins/auto/saisies/v1.34.1/javascript/saisies.js
a la ligne 8 il dit :
$ is not a function (erreur js)si je commente la ligne 2 & 3 tout se remet a marcher
Vous avez une piste pour me débloquer ?
Merci à tous.
Le 14 septembre 2013 10:25, Formidable et Mediaspip ?
Bonjour,
Je suis toujours dans l’embarras... Pas de réponse...
Je n’arrivais plus à faire fonctionner la lecture de médias avec Mediaspip. J’ai posé la question. La réponse est une erreur javascript
"Uncaught TypeError: Property '$' of object [object Object] is not a function saisies.js:8"J’ai désactivé Formidable et Mediaspip fonctionne à nouveau normalement.
J’imagine donc que cette erreur vient de Formidable, non ?
comment régler mon problème pour faire fonctionner Mediaspip ET Formidable ?
Un grand merci à vous tous...
Robert
Je ne vois pas comment « $ » pourrait ne pas être une fonction à la ligne 8 (= jquery pas chargé) MAIS être pourtant interprété correctement à la ligne 1...
T’as un problème avec jQuery en général non ? Ya un truc qui se charge pas bien on dirait.
OUi, sans doute... Mais j’aimerais vraiment trouvé ce qui coince...
Page exemple : http://malle-arts.org/spip.php?article10
Merci, merci...
Robert
Rappel pour tester si un plugin précis est à l’origine d’un bug, et déjà marqué dans le lien « Les choses à faire avant de poser une question » que l’on trouve au dessus du champ texte de ce forum :
Donc as-tu déjà désactivé TOUS les plugins non obligatoires pour tester Formidable/Saisies ?
J’ai eu le même genre de message (
function saisies_fieldset_pliable(){ // On cherche les groupes de champs pliables $('li.fieldset.pliable') ... TypeError: $ is not a functiondans la console firebug.En passant de la version 1.34.1 à la version 1.38.3 : plus de problème !
Répondre à ce message
Bonjour,
Dans un contexte de Spip mutualisé (plusieurs sites avec une seule installation de spip, en 3.0.11) et avec des dossiers plugins par site, donc dans un dossier sites/www.domaine.tld/plugins/auto correctement déclaré (voir http://www.spip.net/fr_article4865.html et http://www.spip.net/fr_article5296.html pour les variables _DIR_PLUGINS_SUPPL et _DIR_PLUGINS_AUTO) qui nous permet d’installer des plugins dans le bon dossier de site par les dépôts, avec le code dans mes_options :
Seul le plugin Saisies nous donne un souci avec l’erreur suivante :
On voit « auto » collé à _ROOT_PLUGINS_SUPPL comme si à cet endroit, _ROOT_PLUGINS_SUPPL n’était pas connu ni remplacé par sa valeur ....
Le traitement de _ROOT_PLUGINS_SUPPL se fait apparemment dans inc/utils.php (ligne 1546) selon ce changelog :
Le plugin s’installe mais ne fonctionne pas ...
Le traitement dans utils.php, c’est ça (j’ai tenté de le déplacer dans mes_options.php mais cela donne une autre erreur sur saisies.css)
Une idée géniale ?
Merci d’avance !
Pierre
On peut d’ailleurs aussi se poser la question du « ecrire/ » devant « _ROOT_PLUGINS_SUPPL » alors que cette constante (par ex placée dans mes_options) produit un chemin absolu depuis la racine de l’hébergement, donc avoir « ecrire » devant semble sans issue ...
Ceci dans l’erreur qui apparait déjà mentionnée dans mon premier post :
Toute aide bienvenue et appréciée ... je sais on est en août !
P.
A priori, il n’y a aucun rapport avec le plugin saisies.
Cela dit, il te faudrait par exemple ajouter un test là où _ROOT_PLUGINS_SUPPL est utilisé dans le code de SPIP et provoque une erreur.
Tu pourrais tester un
Tu pourras alors fournir la pile d’exécution des fonctions pour arriver à cette erreur. Ce qui peut aider à trouver dans quel contexte ça se produit.
Bjr,
Oui je l’ai mentionné au niveau du plugin mutualisation, je pense que Saisies le révèle mais n’est pas la cause.
Je vais tenter ce qui est suggéré et revenir ici.
P.
Bonjour
Je pense que saisies et commun à tout les sites non ? Le mettre dans le répertoire centrale serais pas une facilité ?
Oui d’accord mais on revient au problème que depuis la version 3, la mise à jour d’un plugin le dévalide dans tous les sites d’une ferme à spip, c’est pour ça que je suis en train d’envisager de faire un dossier plugin par site de la ferme.
La ferme me permettra de mettre à jour le core, ensuite je peux m’occuper site par site de la mise à jour des plugins via l’interface ... tâche que je dois faire de toutes façons (je veux dire aller sur chaque site vérifier que tout marche).
Voir http://contrib.spip.net/Ferme-a-SPIP#forum465002 ou vous intervenez, je viens justement de rajouter un mot sur ce sujet, il n’est pas encore aparru.
Une suggestion ou mettre ça car là je n’ai pas trop de résultat ... Ou alors je ne sais pas ou regarder.
PS : je crois qu’il y a une parenthèse fermante de trop au premier defined.
Une autre chose que je constate, c’est que dans utils.php (ligne 1546 pour 3.0.11) qui a été modifié assez récemment : http://core.spip.org/projects/spip/repository/revisions/20029 on a
Et à cet endroit, _DIR_PLUGINS_SUPPL est vide donc ce if n’est jamais éxécuté. Pourtant _DIR_PLUGINS_SUPPL marche puisque mon spip voit le dossier plugins/auto qui est dans le dossier spécifique de ce site dans la ferme. (j’ai pris soin de renommer le dossier plugins central qui ne peut donc être utilisé).
J’ai l’impression qu’une réponse sur 2 est zappée et à chaque fois j’ai un message qui me dit que je suis soupçonné de spam, donc je sais plus trop ou j’en suis sur ce fil ... J’ai fait 2 réponses qui ne sont pas apparues (à Pierre et Mathieu), ... j’attends pour voir si c’est un souci de modération mais en général les messages apparaissent rapidement ...
C’est quand une réponse contient beaucoup de liens. Tes messages étaient en « proposés ». Je les ai validés.
Répondre à ce message
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
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
Merci RastaPopoulos, et bien maintenant je sais quoi faire comme devoirs de vacances ;)
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
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.
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
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.
Ç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 ».
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 ?
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).
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.
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.
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 ?
À 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.
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 ?
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
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() :
Répondre à ce message
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.
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 !
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
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
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
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
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
pardon, finalement ça marche parfaitement en mettant la fonction dans mes_fonctions.php
Répondre à ce message
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 !
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.
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 ;-)
Le plugin Vérifier permet déjà cela.
oui, mais pas en live au blur du champ !
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...
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 ;-)
Je viens de regarder le fichier
saisies/input.htmldu plugin, et c’est ce que je soupçonnais déjàEn effet, si dans la
#SAISIEon ajouteplaceholder=... c’est pris en compte ;-) Et pour le reste je vois qu’il est prévu de pouvoir mettreattributs=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 doncpatern=motif et nous faire des retours qu’on complète le wiki-like...:-)c’est ce que j’avais essayé spontanément, mais ca marchait pas.!
ceci dit j’ai pas verifié sur quelle version je tournais...
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
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.
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
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.xmlpour 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_coordonneesrenvoie 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
Bonjour
Je vais créer des modèles de saisies additionnels. L’idée est de reprendre tous les modèles de saisie existants et d’ajouter une vignette en plus du label du champs. Souvent, une image est plus parlante que du texte.
Pour partager ultérieurement mon travail, est-il plus judicieux de :
- proposer les saisies additionnelles sous la forme d’un plugin, par exemple saisies-vignette ?
- proposer mes modèles pour une intégration dans le plugin SAISIES ?
- proposer mes modèles sous la forme d’un fichier à dézipper dans le rép. /saisies du squelette ?
A+
Peut-être qu’il y a plus simple encore que de redéfinir tous les modèles un par un :
J’ai modifié le fichier _base.html pour afficher la vignette (facultative) sous le label. OK facile.
Maintenant, il faudrait une sorte de surcharge automatique de tous les modèles de saisies, pour ajouter la saisie de l’Id du doc image pendant la définition d’un formulaire. De sorte que l’on ait pas à redéfinir tous les modèles de saisie existants.
Deux possibilités :
- soit j’inclue directement la fonctionnalité dans le plugin SAISIE. Sachant que si l’utilisateur ne donne pas de doc image, c’est l’affichage actuel qui est pris.
- soit je crée un nouveau plugin qui redéfinit _base.html et qui arrive à ajouter automatiquement un champs de saisie du doc image aux modèles de saisie existant.
Quel est l’avis de l’auteur(s) du plugin SAISIES ?
Merci pour votre support
Ajouter des images qui ne sont pas du contenu, c’est de la décoration. C’est donc du ressort des CSS, et on peut déjà parfaitement cibler tel ou tel champ pour ajouter un padding et une image devant son label, j’ai déjà fait ça plein de fois :
.editer_monchamp label{ styles }Si on veut utiliser des images qui viennent de la médiathèque, je crois qu’il est possible d’appeler une image dans le label, du genre
<img123> Mon texte.Mais dans tous les cas je ne crois pas qu’il y ait besoin de modifier le code actuel des squelettes.
Une image n’est pas toujours de la décoration. Elle a souvent un caractère informatif bien plus puissant que du texte.
Mettre un modèle
<doc123>dans le label, cela ne marche pas.Pour illustrer le besoin, voici une page : Checklist outils
Les images sont mises en vrac au début de l’article (pour qq heures encore).
Il y a ensuite une checklist qui permet à l’utilisateur de vérifier qu’il a tous les outils.
Il serait évidemment préférable que les vignettes des outils soient intégrées à l’intérieur de la checklist. C’est simplement une question d’ergonomie.
Il s’agit de décoration s’il y a de toute façon le texte : l’image n’est qu’une illustration du texte du label qui est le vrai contenu. Après on peut ne pas vouloir de texte mais juste une image avec un alt=« le texte », et dans ce cas là oui c’est l’image qui est le contenu.
Mais donc quand c’est de la déco, on style en CSS, et quand on veut une vraie image il faudrait que le modèle d’insertion fonctionne dans le champ. C’est ça qu’il faut modifier à mon avis. Et donc c’est pas dans le squelette mais dans le traitement du champ dans l’API.
En fait en vérifiant le code les champs passent effectivement par typo() donc par la gestion des modèles MAIS seulement si ya au moins un dans la chaîne.
Essaye avec
<multi><doc123> Mon label</multi>Génial ça marche en encadrant avec
<multi>...</multi>Je ne comprends pas pourquoi ça marche ? mais l’essentiel c’est que ça marche.
Répondre à ce message
Bonjour,
En local pour essai avec spip 3.05 de sept 2012, j’ai installé le plugin mosaïque qui demande une mise à jour de saisie et de champ extra.
C’est fait.
Tout fonctionnait bien jusqu’alors...
Dans la partie privée, j’ai ce message à la modification d’un article (il disparait en supprimant saisie et en replaçant une ancienne version de saisie.)
Ce n’est pas catastrophique (test) mais j’aimerais bien tester mosaïques...
Fatal error : Call to undefined function yaml_decode_file() in D :\Travail sur les sites\spip_v3\www\plugins\auto\saisies\inc\saisies_lister.php on line 290
Pour résumer, je n’ai pas le message avec l’ancienne version de saisies et j’ai accés à la rédaction des articles, par contre avec la dernière version de saisies, je ne peux plus changer mes articles.
Merci de toute façon pour cette contribution.
Je viens de charger et placer le plugin YAML, tout marche.
Je ne pensais pas avoir à surchager, puisque YAML est dans les plugins dist.
Merci excusez le bruit.
Répondre à ce message
Bonjour,
Tout d’abord un grand grand merci pour ce plugin. C’est fou le temps qu’il fait gagner. On code plus vite, la maintenance est beaucoup plus aisée. Bref que du bonheur.
Une remarque sur la version 1.26.12 : dans le fichier saisies/radio.html, ligne 25 il y a le code suivant
<div class="#ENV{choix,choix} #ENV{choix,choix}_#CLE">Pour une raison que j’ignore, il produit le HTML suivant :
<div class="choixchoix_maison">Les deux ’choix’ sont collés ce qui peut poser des micros soucis d’appel CSS ou JS.
ps : je précise que j’utilise SPIP 3.0.5
voilaaaa
Merci ! Et oui, j’oublie toujours ce BUG du compilateur de SPIP, qui supprime sans ménagement des espaces autour des #ENV.
Normalement corrigé par :
http://zone.spip.org/trac/spip-zone/changeset/66621
wowh ! Ca c’est de la correction rapide :)
et merci pour l’info concernant le bug du compilateur. J’ai pu corriger un problème...incompréhensible sans cette info.
cheers
Peetdu
Répondre à ce message
Dès que j’active Saisies en version 1.25.13 avec Spip 2.1.14 sous PHP Version 5.3.2, j’ai une page blanche. L’url est : ecrire/ ?exec=admin_plugin&actualise=1
J’ai tenté pas mal de choses comme :
- désinstaller tous les plugins,
- vider le cache,
- supprimer le dossier TMP,
- réactiver chaque plugin individuellement
Rien à faire, dès que j’active Saisies, ça coince, une idée ?
Une page blanche n’est pas une erreur précise. Sur le site de dev, il faut toujours activer l’affichage des erreurs pour savoir ce qu’il se passe plus en détail. Par exemple comme ça : http://www.spip.net/fr_article4453.html?var_recherche=debuggage#infos_plus
Merci, le message est :
Fatal error : Cannot redeclare picker_selected() (previously declared in /plugins/spip-bonux/spip_bonux_fonctions.php:76) in /prive/formulaires/selecteur/generique_fonctions.php on line 86
J’ai les extensions SPIP Bonux 2.3.0, Imprimer document 2 0.2 et CFG 1.16.0
Ben non c’est pas logique. Si la fonction est dans le noyau de SPIP, c’est que tu as SPIP 3, pas SPIP 2.1. Et dans ce cas c’est pas la bonne version de Bonux.
J’ai bien une 2.1.14 mais j’ai essayé de lancer spip_loader pensant que cela chargeait la dernière version de la série 2. Comme cela ne marchait pas, j’ai tout effacé et fait la mise à jour manuelle. Il y aurait des traces de la version 3 alors ?
Le fichier dont tu parles n’existe que dans SPIP 3. Tout effacer ça signifie tout effacer, sauf config/ et IMG/ (et squelettes/ s’il existe).
J’ai supprimé tous les répertoires sauf ceux contenant mes données et profité de passer sur SPIP 2.1.16. Cette fois ci, la validation du plugin s’est bien déroulée mais quand j’essaye de configurer Saisies :
ecrire/ ?exec=configurer_saisies
J’ai ce message :
Fatal error : Call to undefined function yaml_decode_file() in /plugins/saisies/inc/saisies_lister.php on line 290
j’avais le même message suite à une mise à jour 2.1.12 -> 2.1.19. De plus je ne voyais plus les plugins, activés ou non.
En FTP dans plugins/auto/ j’ai renommé le dossier saisie et verifier avec .old à la fin (saisie.old et verifier.old)
Depuis le spip, j’ai rafraichi la fenêtre plugins : bingo ! il me dit que verifier et saisie sont manquants....
Je retourne en ftp je leur rends leur nom (saisie et verifier)
Je n’ai plus qu’a réactiver ces 2 plugins dans le spip.
Cette méthode a marché pour moi. si ça peut aider
Bon courage
Répondre à ce message
Bonjour,
Je n’arrive pas à rendre une checkbox cochée par défaut.
J’ai tenté les configurations suivantes :
Avec également les mêmes valeurs entourées de guillemets, mais rien n’a fonctionné. Comment devrais-je m’y prendre ?
Tu parles de quoi ? En squelette ? et de quelle saisie parles-tu ? « case » qui est unique (comme oui_non mais en une case) ou bien « checkbox » qui gère plusieurs choix ?
Alors oui, je suis dans un squelette.
Et j’ai utilisé checkbox, mais je ne connaissais pas « case », qui me semble plus approprié pour ce que je veux faire (Une activation de plugin).
Finalement non, ça ne marche pas mieux avec « case ».
Voilà le code que j’utilise actuellement :
Et tu voudrais que ça fasse quoi ?
je voudrais juste que la case soit cochée par défaut, ce qui n’est pas le cas actuellement.
Il s’agit de l’activation /désactivation d’un plugin. je voudrais qu’il soit activé lors de son installation.
« defaut=on » donc avec la saisie « case » à priori
Remarque sur le besoin précis : c’est quoi l’intérêt de cette case vu que ya déjà une interface à SPIP pour activer/désactiver chaque plugin ? :)
Non, ça ne marche pas.
Sinon, pourquoi ? je sais que c’est redondant, mais je voulais donner la possibilité d’activer la fonctionnalité sur la même interface que le reste des options, pour plus de simplicité.
Mais c’est aussi pour ça que je voudrais que ça soit activé par défaut.
Arf, oui c’est vrai il ya un bug commun à « case » et à « oui_non » qui est que la valeur réelle doit être NULL pour que ça prenne la valeur par défaut à la place. Or le charger() de CVT ne renvoie jamais null mais chaîne vide, je crois.
On a pas encore trouvé de solution simple me semble-t-il. :(
Pas de souci, je ferai en sorte que ce soit une case « Désactiver » ;)
Et sinon, ce ’nest pas possible de vérifier uniquement par une égalité double et non triple dans le plugin ? Ou ça causerait plus de souci que ça n’en corrige ?
C’est pas une question d’égalité triple, c’est un test « is_null ». Car Les deux valeurs possibles pour une case sont soit remplie avec une valeur, soit chaîne vide. Or faut pouvoir différencier « chaîne vide » qui veut dire « pas cochée » de « null » qui veut dire « ya pas de valeur pour l’instant ».
Ok, merci pour les précisions !
Répondre à ce message
Bonjour Rastapopoulos,
Ce serait super une saisie Fichier_joint qui joindrais dans tmp/
genre :
[(#SAISIEfichier, f_joint, , label=Votre cv, dossier=« mon_dossier »)]
J’aimerais bien mettre une issue mais je sais pas où ca se passe.
Peut être d’autres aimeront ?
Merci pour ce plug en tt cas que j’utilises à toutes les sauces
++
Répondre à ce message
Bonjour,
Voici le message d’erreur avec la version de SPIP et la dernière version du plugin « Saisies » avec l
SPIP 2.1.16
version du plugin saisies 1.26.5
Parse error : syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ’}’ in /mnt/106/sda/5/1/lpg45/plugins/saisies/balise/saisie.php on line 13
Merci
PHP 4 n’est plus supporté, il te faut PHP 5 (voir la doc de ton hébergement, souvent une ligne dans un .htaccess)
Merci à vous maintenant c’est OK en créant le fichier .htaccess à la racine de mon site et en écrivant dedans seulement <php5> .
Répondre à ce message
Bonjour,
tout d’abord merci pour le plugin, qui me sert beaucoup.
J’ai juste une suggestion à vous faire, pour l’améliorer. Je ne suis pas spécialiste, donc c’est à valider, notamment au niveau de l’impact sur le reste du plugin
J’utilise un fichier YAML pour spécifier mes formulaires puis les envoyer à GENERER_SAISIES (j’ai piqué l’astuce ici : http://contrib.spip.net/Doc-Saisies-complementaire)
Par contre les chaines de langue sur les labels ne fonctionnent pas si on les mets telles quelles dans le YAML
J’ai réussi à les faire traduire automatiquement par GENERER_SAISIE en remplaçant, dans _base.html « #ENV*label » par « (#VAL#ENV*label|_T) » et en .
Il faut spécifier dans le YAML la chaîne de langue au format « code:id_chaine » et ça roule. Si ce n’est pas une chaîne de langue qui est spécifiée dans le YAML, le nom est affiché tel quel.
Si un des développeurs pouvaient confirmer, ça serait cool.
Merci !
Pierre
avec les balises code ...
P.
Depuis le début, les saisies acceptent de mettre en paramètre des chaines de langue comme dans les squelettes :
<:préfixe:code:>, c’est utilisé partout, y compris pour les fichiers de config des saisies elles-mêmes (cf saisies/*.yaml).Arf.
effectivement c’est utilisé dans les fichiers du répertoire « saisies »
par contre je ne comprends pas pourquoi ça ne fonctionne pas chez moi.
Il m’affiche <:code:id_chaine :>
je vais investiguer
Merci d’avoir pris le temps de répondre ..
P.
Bon, je n’ai pas réussi à comprendre pourquoi ça ne marche pas.
Si quelqu’un pouvait m’aider, je l’en remercie par avance.
SPIP 3.0.4 [19781]
Saisies 1.26.5
PHP 5.3.13
MySQL 5.5.24
extrait de mon YAML
j’ai aussi testé avec :
extrait du code qui parse le YAML (dans formulaires_editer_objet_charger_dist)
et dans mon formulaire :
extrait de mon fichier de langue objet_fr.php (qui est bien reconnu ailleurs dans l’espace privé)
Je précise que j’affiche tout ça dans l’espace privé.
Merci d’avance !
P.
Alors :
Pour cela il faut créer une fonction
formulaires_truc_saisies_dist($arg1, $arg2, etc)sur le même modèle sur charger(), verifier() etc. Cette fonction doit renvoyer un tableau PHP de saisies, selon la norme de ce plugin. Ce tableau soit tu l’écris directement dans cette fonction, soit tu le fais venir d’où tu veux, peu importe. Lorsque cette fonction existe, SOIT tu laisses le HTML du formulaire VIDE (mais le fichier doit exister) et dans ce cas Saisies te construit le formulaire entier, SOIT c’est toi qui fait le squelette et tu peux récupérer le tableau des saisies dans#ENV{_saisies}. Tu as pas mal d’exemple d’utilisation de cette API déjà sur la zone : http://zone.spip.org/trac/spip-zone/browser/_plugins_/produits/formulaires/configurer_produits.phpMerci beaucoup de ta réactivité !
Ca fonctionne !
Pierre
Répondre à ce message
Bonjour
c’est a dire que les plugins fonctionnant avec (saisie) ne fonctionne pas on me demande de telecharger l’ancienne version, avec la nouvelle , les plugins ne fonctionnent pas
Qui ? Quoi ? Où ? Quand ? Quelles versions ? Quel SPIP ? Expliques vraiment ton cas d’utilisation, parce que là c’est un peu flou.
Répondre à ce message
Bonjour
aprés mise à jour version 1.25.4 de ce plugins, plus rien ne fonctionne avec les plugins ayant besoin de celui-ci, on me demande de remmettre l’ancienne version 1.24 bien entendu que je ne trouve plus
qu’en pensez-vous
Ça veut dire quoi « plus rien ne fonctionne » ?
Répondre à ce message
Bonjour,
J’ai rencontré un bug sur un formulaire contenant plusieurs champs #SAISIE, dont 1 #SAISIE(carte) du plugin GIS.
La carte ne s’affichait pas.
Elle est réapparue apres avoir modifié dans le fichier _base.html du plugin saisie la ligne
<!--!inserer_saisie_editer-->en
<!--inserer_saisie_editer-->(sans le 2e point d’exclamation)
quel navigateur, quelle version ?
Voici les versions ;
Google Chrome Version 21.0.1180.79 sur MacOs 10.7.4
SPIP 3.0.4
Saisies 1.26.4
Gis 3.3.11
Répondre à ce message
Réponse à mon post (dsl du dble post et de la question un peu bête). j’ai réussi à tout remettre en ordre après quelques temps de panique.
Répondre à ce message
Gros problème avec le plugin, je l’ai pris pour faire fonctionner le plugin jsquery. Au moment de l’activation, il a planté tout le site et depuis impossible d’accéder à l’espace privé. Quelqu’un aurait il une idée de la manip à réaliser pour accéder à nouveau à l’espace privé et le désactiver.
Merci
Ps je suis un débutant
Répondre à ce message
Bonjour
j’utilise le plugin formidable et j’ai compris qu’il utilise le plugin « saisies » pour afficher les formulaires. Mais lorsque j’insère un formulaire avec des boutons radio, les input s’affiche sur une ligne et les label sur la ligne suivante, je souhaiterais que les 2 s’affichent sur la même ligne.
Merci de votre aide.
Aucun de ces deux plugins ne s’occupent du style. Donc si ça fait ça c’est forcément dû aux CSS utilisées par ton site. À toi de les changer ou de les personnaliser pour mieux coller à ton besoin.
Ok RastaPopoulos je vais essayer de revoir encore un peu mes styles.
Merci
J’ai remarqué que ce sont mes « label » qui font des retour à la ligne. Quelqu’un pourrait m’aider à corriger cela ?
Merci
Oui pourquoi pas, mais peut être si c’est pour du css vaux il mieux poster sur le forum de spip, et donner une url (adresse), ça évitera de remplir le forum de saisies avec des infos qui ne concernent pas directement le plugin.
Merci Mist. GraphX je vais faire un tour sur le forum
Répondre à ce message
Bonjour,
be ca, c’etait la deuxieme question !
ca ouvre vraiment de grosses perspectives...
J’ai passé la journée a tester tout ca, c est vraiment incroyablement pratique, terriblement bien foutu... mais faut pas perdre le fil... J en suis a surchager les « saisies_vues » afin de récupérer les saisies au format spip...
Un grand merci pour ce super cadeau
Triton
Répondre à ce message
Bonjour,
y a t il un moyen grace a la fonction formulaires_xx_saisies de récupérer les descriptions de champs crées grâce au plugin « formidable » (champs sérialisés dans la colonne « saisies » de spip_formulaires) et ce afin de les inserer dans un formulaire CVT ?
La fonction traiter de ce formulaire CVT n’etant réalisable avec le plugin formidable, mais il serait vraiment bien que les champs du formulaire soient modifiables par simple administration....
Pas sur que ce soit tres clair...
function formulaires_XX_saisiescharge la description d un formulaire crée avec « Formidable »
function formulaires_XX_chargeraffiche ce formulaire
et ensuite fonctionnement normal du form CVT
Je sais faire les formulaires en decrivant les champs sous forme d’array dans formulaires_xx_saisies, me demande juste si possible d’inserer automatiquement les champs formidable dans cette fonction
Il semble bien que « formidable » et « saisies » sont capables de communiquer, mais je ne vois pas comment.
Un grand merci
Triton
il semblerait que la reponse etait deja dans la question....
function formulaires_XX_saisies(
$form = sql_getfetsel(’saisies’,’spip_formulaires’,« identifiant = ’identifiant_du_form’ ») ;
$form=unserialize($form) ;
return $form ;
et c est vraiment... formidable...
merci beaucoup pour ces 2 supers plugins
triton
Alors :
Il suffit de créer
traiter/montraitement.php+traiter/montraitement.yamlen s’inspirant des deux traitements fournis par défaut. Ce nouveau traitement sera alors proposer dans la liste des actions possibles du formulaire.Répondre à ce message
J’ai plusieurs problème avec SAISIES depuis que je suis passé en spip3 (c’est peut-être lié) :
- les saisies radio et sélection ne sélectionnent pas la valeur defaut, les champs input oui.
- les saisies case ne permettent pas de décocher
Une idée ?
Répondre à ce message
Il y a un bug avec « Saisies » sous IE7 et IE8 (Pas sous IE9). J’en ai parlé sur la page du plugin « Formidable » mais comme il concerne « Saisies » je le remet ici.
C’est le texte qui se trouve entre les balises
<button ...>et</button>qui est transmis par IE8 (ou inférieur) au lieu de la « value ».c.f. : http://www.w3schools.com/tags/att_button_value.asp
Je rencontre aussi ce problème en IE8
Y’a-t-il une alternative autre que changer de navigateur ?
Pfff ouais c’est relou ces navigateurs qui suivent pas la norme. La solution c’est de modifier (je dis pas corriger parce que c’est IE qui bug, pas le formulaire) le code pour feinter en utilisant des « input » avec des name=« truc[machin] » plutôt que des « button » avec name=« truc » et value=« machin ».
Ça c’est du côté des codeurs de spip-zone. Du côté des utilisateurs, en attendant, la solution est (évidemment) d’utiliser un navigateur moderne qui respecte les standards.
Répondre à ce message
Salut,
Y a-t-il un moyen d’éviter de retrouver coté public les css de saisie ? C’est pas très chouette et en plus c’est toujours un petit peu de poids en plus. Surcharger me chagrine. ;)
Merci de vos réponses.
Calomnie ! Vérifies tes CSS avant de dire ça ou donne une URL, parce que les styles que Saisies ajoutent ne concernent que des saisies précises et pour des besoins fonctionnelles dont ont besoin ces saisies (fieldset pliables, date en trois parties, sélecteur par navigation).
Raaa mais je me plante de page, c’est contact et organisation qui me chagrine. Sorry Rastapopoulos, ton plugin est grand.
Je l’avais viré récemment pour SPIP 3 :
http://zone.spip.org/trac/spip-zone/changeset/62387/_plugins_/contacts_et_organisations
Répondre à ce message
Merci pour ce plugin fort utile !
Petite remarque au passage : pour stocker des champs de type booléens, ce serait plus propre d’utiliser... des booléens. « oui/non », c’est un peu noob, et très embêtant quand on veut relier spip à d’autres systèmes. (Cette remarque est valable pour l’ensemble de SPIP en fait).
Je ne comprends pas trop de quoi tu parles car la saisie « oui_non » aboutit à une chaîne pleine pour le oui (évaluée à true en SQL et PHP) et à une chaîne vide pour le non (évaluée à false en SQL et PHP). Les valeurs booléennes, quant à elle, n’existe pas en HTML. (Et on peut aussi personnaliser les options « valeur_oui » et « valeur_non ».)
Répondre à ce message
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
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
PHP trop vieux.
Exact !
Un grand merci
Répondre à ce message
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
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>dansformulaires_constructeur.csspour que ça ressemble à du<h3>.J’ai modifié localement les fichiers
saisies/saisies/fieldset.htmletsaisies/saisies-vues/fieldset.htmlen 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
idsur 2<input>danssaisies/saisies/fieldset.htmllignes 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 attributforprécisé)J’ai ajouté
id="champ_#ENV{nom}"à côté de l’attributnameet 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.htmlet non desaisies/saisies/fieldset.htmlVé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.legendparlegend.La correction des points n°1(fichiers
saisies/saisies/fieldset.htmletsaisies/saisies-vues/fieldset.html) et n°2 (danssaisies/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.htmletsaisies/saisies-vues/fieldset.html(en remplaçant<h3 class="legend"></h3>par<legend></legend>), il faut aussi modifiersaisies/css/formulaires_constructeur.htmlen remplaçanth3.legendparlegend.A priori, si les utilisateurs du plugin ont une règle CSS personnalisée pour
h3.legend, il suffit de renommerh3.legendenlegenddans 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
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).
C’est tout à fait cela ... j’ai activé php5 et cela fonctionne.
Merci pour ton aide !
Répondre à ce message
ATTENTION ca bug...................
Mise a jour du 4/04/2012
Longue vie à Spip et ses plugins
Mais encore ?
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
http://zone.spip.org/trac/spip-zone/changeset/60115
Log de commit :
Répondre à ce message
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_nonsuivante......génère ce code html :
Il manque donc le
name=camembertdans 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).
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.
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 :
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
Bonjour à tous,
J’ai une erreur qui semble être reliée au plugin saisies :
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_HEADdans 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 :
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 :
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
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 :
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) :
Ce qui peut donc devenir peut être pour toi :
D’un côté la saisie :
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) :
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
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
Ben c’est juste logique quoi... Saisies ne peut que s’insérer dans le pipeline « formulaire_verifier », qui forcément est appelé après la fonction de base.
Sinon il faudrait modifier SPIP pour modifier les pipelines : « formulaire_pre_verifier » + « formulaire_post_verifier » et ce pour C, V, et T. Tout comme il y a « pre_edition », « post_edition ».
Donc tu pourrais plutôt faire ta suggestion en lançant le sujet sur spip-dev, c’est pas idiot du tout !
Répondre à ce message
Hello
Le problème de vérification des saisies obligatoires non affichées étant en passe d’être résolu, un autre problème voit le jour ;-(
La vérification de Saisies est effectuée après celle du plugin appelant. L’inverse ne serait-il pas plus logique ? => Saisies s’occupe de vérifier tout ce qui a été défini lors de la définition de chaque saisie, puis l’utilisateur vérifie ses trucs propres à son fonctionnement. J’ai par exemple un champ input qui s’attend à recevoir un entier, l’idéal serait que, quand j’arrive dans ma fonction de vérification, cette vérification soit déjà effectuée...
Répondre à ce message
Bonjour,
Mon problème est résolu mais peut-être qu’il pourra intéresser du monde ;-)
Je me suis confronté à un problème avec l’utilisation de 2 champs date dans un même formulaire : dans un premier temps, j’avais déclaré ces 2 champs avec le type « date » dans mes #SAISIE et si mes icônes de datepicker s’affichaient bien, pas d’ouverture de calendrier lors du clic sur l’icone...
J’ai trouvé la solution en déclarant mon premier champ en « DATE » et mon second en « INPUT »
Du coup, le code généré par le Jquery ne se charge qu’une seule fois et les 2 champs fonctionnent avec leur datepicker respectif ;-)
Voici le code :
Répondre à ce message
Bonjour,
J’utilise Saisies pour faire un formulaire de CFG. Je n’ai pas de problème pour récupérer la valeur d’un champ de type « radio », par exemple, si je crée un champ :
[(#SAISIE{radio, institut, label=Choix de l'institut de tutelle, defaut=autre,datas=#ARRAY{....}})]je peux récupérer la valeur choisie dans un squelette par la balise habituelle de CFG :
[(#CONFIG{kitcnrs/institut})]Par contre, ça se corse avec les champs de type « selecteur_rubrique ». Par exemple, avec un champ :
[(#SAISIE{selecteur_rubrique, id_rubrique_a_la_une, label=« À la une »})]Si j’utilise :
[(#CONFIG{kitcnrs/id_rubrique_a_la_une)]la balise renvoie un tableau. J’ai bien essayé d’utiliser le filtre table_valeur :
[(#CONFIG{kitcnrs/id_rubrique_a_la_une|table_valeur{0})]Mais ça renvoie le type d’objet (article/rubrique) et son identifiant séparés par un pipe. Y aurait-il un moyen pour récupérer la valeur du champ ?
Merci.
Il y a une fonction
|picker_selected{rubrique}(par exemple), associée. Ça permet de récupérer un tableau des identifiants du type d’objet mis en paramètre (ici rubrique). Ensuite si yen a qu’un tu prends le premier.[(#CONFIG{truc}|picker_selected{rubrique}|table_valeur{0})]Un truc dans ce genre. Par contre je ne sais plus où se trouve la fonction donc il faut peut-être inclure quelque chose pour l’avoir. C’est un sélecteur qui vient de bonux (et qui est intégré dans SPIP 3 maintenant), c’est pas dans Saisies.ça marche sans qu’il soit nécessaire de faire une inclusion, merci bien.
Répondre à ce message
Bonjour,
Après un parcours rapide de la documentation, j’ai l’impression que Saisies ne propose pas de champ pour uploader des fichiers et les supprimer. Est ce que cette fonctionnalité est envisageable ? Merci.
Tout est toujours envisageable... si on a du temps pour le développer. :)
Ça n’existe pas pour l’instant et c’est compliqué pour le faire proprement et générique. C’est dans la « todo list » depuis le tout début du projet.
C’est noté, merci.
Répondre à ce message
Bonjour,
J’ai plusieurs problèmes qui apparaissent dans l’admin avec ce plugin :
- Le chargement des images téléchargés dans spip tourne indéfiniment, les images se téléchargent bien malgré tout lorsqu’on actualise la page
- La page informations personnelle dans auteurs ne s’affiche plus
- Le formulaire mot de passe oublié ne s’affiche plus
J’ai la dernière version de spip (2.1.11)
Ce plugin n’a rien à voir avec tous ces points. D’ailleurs ce plugin ne modifie pas le comportement de SPIP (il ne s’insère dans aucun de ses points d’entrée) et n’ajoute aucune page. C’est un outil pour développeur qui ajoute de nouvelles fonctions.
Qu’est-ce qui fait dire que c’est ce plugin précisément qui provoque ça ? As-tu désactivé TOUS les plugins pour ne tester que l’activation/désactivation de celui là ?
En effet je me suis trompé, c’est le plugin afficher objet qui pose ce problème. Désolé.
Répondre à ce message
Bonjour,
Je tente d’ajouter un champ date comportant un datepicker avec SAISIE.
Quand je mets :
le champ est fonctionnel mais il n’y a pas le date picker.
Quand je mets :
il y a bien le date picker mais celui-ci réinitialise la date (0000-00-00)
dans la table de bdd le champ est de type date (0000-00-00)
Que dois-je faire pour que ça fonctionne ?
Merci pour votre aide
Chez-moi-ça-marche ©.
Sans exemple concret (URL ?) je ne vois pas comment aider.
Ok donc comment prévu, ni le datepicker, ni le plugin Saisies n’ont rien à voir là-dedans. Ce n’est d’ailleurs même pas lui qui met la date. C’est vous qui dites quoi mettre comme valeur dans votre fonction charger() du CVT. Donc à vous d’aller chercher la bonne valeur et de la formater dans le bon sens (vu que le datepicker est en format français alors qu’en base ça sera en format SQL).
Donc faut aller chercher votre date, transformer la version SQL en version français jj/mm/aaaa, et la mettre dans le contexte de charger() :
$contexte['date_echeance'] = ...;et inversement dans le traiter() il faut retransformer le date FR en date SQL pour l’enregistrer en base.Merci beaucoup pour ces précisions. Je vais creuser cette piste.
Si je n’y parviens pas, il me suffirait donc de changer, dans la bdd, le type du champ date_echeance, pour passer de DATE à VARCHAR ?
Encore merci pour votre aide et bonne continuation dans vos projets.
J’ai été accidentellement confronté au même problème et je précise :
- on peut bien mettre une date par défaut (sinon il n’y a rien, ce qui équivaut à 0000-00-00 en bdd) et cette date par défaut peut être au format ISO-8601 ! ainsi, dans ma fonction charger(), un
'date_echeance'=>date('Y-m-d')renvoie positionne bien la date sur aujourd’hui (affiché 29/08/2011) \o/- mais mon vérifier() —qui s’assure que d’une part la date est au format ISO-8601 et qu’elle est valide met systématiquement le champ en erreur (et donc sans ça, la date qui arrive en bdd est incorrecte, ce qui équivaut à 0000-00-00 pour MySql) ;-( il faut donc, au niveau du traiter(), le retraiter... (chez moi, sans revérification, c’est :
$parts_date_echeance=explode('/',_request('date_echeance')); $bonne_date_echeance=parts_date_echeance[2].'-'.parts_date_echeance[1].'-'.parts_date_echeance[0];ce qui est bien entendu une façon de faire parmi d’autres)Oui, la fonction verifier() doit faire son travail de vérification avec la valeur de la saisie en « / ». Il y a d’ailleurs une fonction du plugin Vérifier pour ça. Et ensuite au dernier moment il faut transformer la date pour la mettre au format ISO. On peut utiliser un preg_replace() en une fois, ça va plus vite. Ou bien utiliser les fonctions de date de PHP pour transformer la date en « / » en timestamp qu’on retransforme en date ISO ensuite.
Merci pour la confirmation RastaPopoulos.
Le
preg_replace()pour transformer une date-fr en date-iso serait du genre :$date_echeance = preg_replace('$(0?[1-9]|[1-2][0-9]|3[0-1])/(0?[1-9]|1[0-2])/([1-3][0-9]{3,3})$','\\3-\\2-\\1',$date_echeance);_ Mais j’évite d’utiliser les regex quand on peut faire simplement sans... Je ne suis pas certain que ce sois plus rapide (que le
str_replace()par exemple dans les cas simples), et par contre ils utilisent plus de ressources matérielles (processeur et mémoire) :-S_ Cependant, si on doit utiliser les regex PCRE/Perl, autant en profiter un max (code non teste) :
$date_echeance = preg_replace('$[\d{1,2}][\W]+[\d{1,2}][\W]+[\d{1.4}]$','\\5-\\3-\\1',$date_echeance);Pour la fonction PHP transformant les dates en « / » en timestamp, si tu as une piste je veux bien la noter dans un coin parce-que je ne connais que
strtotime()qui hélas n’accepte que les dates en anglais... (et 03/08/2002 par exemple, est le 8 mars en anglais, et le 3 aout en français...) :-( ou ISO... Dommage car, un coup de$date_echeance = date('Y-m-d',strtotime($date_echeance));et ça rouleraitPour la vérification, le plugin verifier dispose bien d’une fonction verifer_date_dist qui prend les date-fr et s’assure que le nombre de jours est compris entre 1 et 31 et le nombre du mois entre 1 et 12. (Il me semble aussi qu’il y avait une limitation sur l’année, mais elle n’avait de sens —a mon avis— que pour les dates de naissance...)
N’utilisant pas ce plugin, je décompose la date comme déjà mentionne et la passe a
checkdate()(qui fait les mêmes vérifications sans la limitation d’année, et en prime vérifie la concordance entre des fins de mois —du coup on a ure erreur pour le 30 février par exemple) :(c’est bien entendu une méthode parmi d’autres, et elle peut avoir des variantes comme utiliser trois variables chaine au lieu d’une variable tableau :
Le plugin Vérifier n’a aucune limitation d’année, et fait bien un checkdate : http://zone.spip.org/trac/spip-zone/browser/_plugins_/verifier/verifier/date.php
Pour le preg_replace c’était surtout pour la lisibilité, et comme c’est après avoir déjà vérifié que c’était le bon format, t’as pas à tester le format exact, etc, ya juste à changer l’ordre.
Ceci dit ça fait un certain temps qu’on réfléchit à ce que le plugin Vérifier sache aussi formater des données en sortie, après vérification. Exemple qu’on puisse vérifier la validité d’une date qui peut être dans plusieurs formats, mais par contre qu’en sortie on est toujours du ISO. Ou que pour un nom de famille tout soit mis en majuscule sans accent, si le système en a besoin, etc. Ce genre de transformation post-vérification.
Cool ça ; ça fait un bout de temps que j’avais pas retesté. En plus c’est un peu comme j’avais commencé à écrire ma fonction de vérification (sauf que j’avais listé les six combinaisons possibles —jma, jam, mja, maj, amj, ajm— et que j’étais iso par défaut)
Par contre, ce n’est pas une mauvaise chose de pouvoir poser des bornes sur les dates (par exemple site pour ados refusant donc plus d’un certain âge, ou site nécessitant un âge minimum, ou une combinaison des deux), à condition que cela reste optionnel...
Dans le cas présent (testé avant de poster hier), ça servirait à rien de renvoyer une sortie ISO : le champ date l’accepte, mais le reconverti au format FR ! :-( D’un autre côté, bien que l’idée de formatage soit séduisante, on s’éloigne de la simple vérification et on fait du traitement de présentation...
Je pense que c’est aux DatePicker de permettre de faire une saisie suivant le format local de l’usager (donc jj/mm/aaaa pour une interface en français, mais mm/jj/aaa pour une interface en anglais) mais de renvoyer la valeur dans un format standard (ici ISO), comme le prévoit HTML5 justement pour les nouveaux champs date, datetime, time.
À suivre...
Cédric, j’espère que tu ne l’as pas fait : un VARCHAR (un CHAR est mieux vu que la taille est fixe...) ne sera pas forcément plus économique en place occupée et ça ne change rien au problème puisqu’il faudra quand même que tu stocke au format ISO qui est justement indépendant (pratique pour l’internationalisation et la portabilité) et offre un certain nombre d’avantage (les algorithmes de comparaison et le tri sont plus simples, de plus on sait facilement les convertir vers d’autres formats que l’inverse)
Répondre à ce message
bonjour,
sur un site spip2.0.12 + ecran de secu
la mise à jour du plugin Interfaces de champs extra « Nécessite le plugin SAISIES en version [1.13.0 ;] minimum. »
Or en mettant à jour le plugin saisies ça plante le site (écran blanc en back et frontoffice). En enlevant le dossier du plugin par ftp le site se réaffiche normalement.
La version antérieure du plugin saisies 1.8.12 [43285] ne plante pas le site... mais ne permet pas d’installer Interfaces pour champs extra.
merci de votre aide,
Bonjour Audwill,
Un écran blanc est souvent le signe d’une erreur PHP non affichée (ce qui est par défaut le cas de PHP maintenant). Il serait bien, le temps de tester, de faire afficher les erreurs PHP de la sorte, en ajoutant ce code dans ton fichier config/mes_options.php :
Une fois fait, en remettant le plugin saisies et interfaces, devrait logiquement apparaître l’erreur bloquante que tu pourras nous transmettre ici, ce qui nous aidera à comprendre ce qui se passe.
Merci bien.
Salut,
et merci pour ta réponse !
J’ai copié le bout de code dans config/mes_options.php :
et réactivé le plugin saisies mais... j’ai toujours une page blanche sans affichage d’erreur php.
Je supprime ensuite le dossier du plugin via ftp pour que le site s’affiche à nouveau. et là en backoffice j’ai cette indication :
Erreur dans les plugins : plugins/auto/saisies/saisies_options.php, plugins/auto/saisies/balise/saisie.php, plugins/auto/saisies/inc/saisies.php, plugins/auto/saisies/saisies_pipelines.php (indication qui disparait quand je vide le cache à nouveau).
que puis-je faire d’autre pour vous donner plus d’infos ?
Répondre à ce message
Yo
spip.php ?page=saisie.css surcharge une de mes css coté site public. Voir ici le vilain cadre bleu sur la recherche en haut à gauche. J’ai trouvé saisies.css.html à la racine du répertoire du plugin, toutefois cette css ne comporte pas les class du formulaire de recherche. Comment cela fonctionne-t-il ? Comment retrouver ces class et y apporter des surcharges ?
Je ne sais absolument pas d’où ça sort. C’est pas dans une des inclusions du fichier ? Pfff, j’ai jamais voulu ça moi (cherchez le coupable).
Ouais voilà, ya quelqu’un qui a ajouté les styles PRIVÉS de bonux à cette CSS, pour utiliser le sélecteur d’articles/rubriques. Mais du coup ça style d’autres choses, aussi, c’est pourri.
Il faudrait ajouter ça seulement si on est dans la partie privée, mais c’est pas super non plus car on peut très bien vouloir ce sélecteur dans la partie publique aussi. Faudra demander à Yffic.
Oui, c’est effectivement ennuyeux. J’ai modifié mon css pour que celui de saisies soit surchargé. Nombreux sont les plugins à gonfler les pages avec des css ou des .js sans que l’on en ai systématiquement besoin. Sur un site comme celui là où prêt de 30 plugins sont couramment utilisés, ça fait vite beaucoup de poids pour rien.
Ben non ça fait pas beaucoup de poids puisque de toute façon toutes les CSS d’un même media=truc sont concaténées + compressées et donc envoyées en un seul fichier au client, qui ensuite l’aura en cache. Donc c’est pas le problème le plus chiant.
Là c’est surtout que ça ajoute des styles très « génériques » sans qu’on s’en aperçoivent, et qui en plus sont au départ réservés uniquement à la partie privée, et c’est vraiment n’importe quoi...
Répondre à ce message
J’ai un formulaire qui fonctionne bien en utilisant #GENERER_SAISIES.
Il est dans le répertoire formulaires d’un plugin et appelé dans un article par
Si j’essaye de mettre certains champs dans un ’fieldset’ le formulaire ne s’affiche plus, sans message d’erreur, ni log.
Pour tester en étant certain d’éliminer les typos, j’ai installé les fichiers film.html et film.php de cet article : http://www.spip-contrib.net/Un-formulaire-C-V-T-avec-Saisies-par-l-exemple dans le répertoire formulaires du plugin et j’appelle ce formulaire dans un article par
Même problème, qui disparait si je supprime le fieldset (en laissant les saisies du fieldset).
C’est déjà arrivé à quelqu’un ? Une idée ?
C’est tout le formulaire qui ne s’affiche pas ou juste les saisies contenues dans le fieldset ?
Tout le formulaire. Et ça semble stopper les calculs de spip :
Du coté public, ça affiche l’en-tête et le début (titre, auteur,...) mais pas de pied de page ni de colonne extra.
Coté privé la tentative d’édition de l’article du coté backend me renvoie ce code en tout et pour tout comme page html : (« formulaire ici », à la fin, est le texte de l’article avant le tag formulaire)
Si ça peut aider, c’est un SPIP 2.1.10 [17657] + images(1.0.1), msie_compat(1.0), porte_plume(1.7.8), safehtml(1.3.7), vertebres(1.0), verifier(0.1.9), cfg(1.16.0), crayons(1.9.4), skeleditor(2.5.3), spip_bonux(2.2.21), z(1.7.9), compositions(1.2.3), saisies(1.9.9), compresseur(1.0.1)
Chez-moi-ça-marche. ©
Si c’est tout le formulaire et même apparemment toute la page entière qui est bloquée, c’est forcément qu’il y a une erreur PHP quelque part qui arrête tout.
Mais sans code sous les yeux, je vais pas pouvoir aider.
Hélas, le code est celui de l’article d’exemple...
Il ne marche pas chez moi.
Les particularités par rapport à l’exemple :
- Les fichiers sont dans le répertoire formulaires d’un plugin.
- C’est un site qui fait partie d’une mutualisation.
Pas d’idée ?
J’ai reproduit en installant un spip neuf avec un spip_loader.php downloadé aujourd’hui et les plugins bonux vérifier et saisies à jour de svn ://zone.spip.org/spip-zone/_plugins_ :
Le code de l’exemple ne fonctionne pas. Le même en supprimant les fieldset fonctionne.
Ben je te dis que si tout s’arrête c’est qu’il y a une erreur PHP. Si tu fais un site en local, en mode « développement », tu DOIS activer l’affichage des erreurs PHP, sinon tu ne risques pas de pouvoir tester grand chose.
Le code que tu m’indiques à une parenthèse en trop à la fin... :)
RÉSOLU
Merci pour ton aide !
en ajoutant
ça m’a permis de voir que le problème était dû à l’absence du plugin YAML.
Une fois ce plugin installé tout fonctionne correctement (non, il n’y a pas de parenthèse en trop dans le code d’exemple)
Répondre à ce message
Hello
2 questions à propos de la fonction formulaires_montruc_saisies_dist() qui charge et vérifie :
- Si je veux pouvoir initialiser mes saisies avec quelque chose que je récupère en base, il faut aussi que je crée formulaires_montruc_charger_dist() ? ou y’a un truc plus simple.
- Je voudrais afficher un message général d’erreur en tête de formulaire si une des saisies ne passe pas la vérification... Là je ne vois pas trop comment faire
Merci
Pour le message général, le souci est que la fonction vérifier de saisies est appelée après celle de mon plugin. Donc même si je fais une fonction dans ce genre, la verif est effectuée 2 fois et comme la 2e c’est celle de saisies, ben rien n’est affiché :
Donc je ne vois pas d’autre solution que d’utiliser les fonctions classiques CVT... A moins que...?
Bonjour,
je coince aussi sur verifier ...
en fait, j’ai des champs afficher_si qui sont aussi « obligatoire_si »
ma fonction
formulaires_monCVT_verifier()fait le test et supprime bien les erreurs si elles sont inutiles... mais le Traitement ne se fait pas... les champs « obligatoire_si » sont marqués en erreurpas possible de squizer le verifier auto de Saisies ?
Je ne saurais dire : je n’ai jamais mis le nez dans le code des « afficher_si » et consorts. À priori c’est dans la vérification faite par Saisies qu’il faudrait gérer tout ça proprement.
Répondre à ce message
Bonjour,
Une petite question : une boucle est-elle possible à l’intérieur d’un array d’une balise saisie ? Je m’explique : je désire récupérer les valeurs d’une table externe dans #array pour afficher une liste sous forme de sélection comme ci-après.
Mais ça bug total…
Quelqu’un aurait-il une solution ?
Merci d’avance
Il faut faire ta boucle avant, et remplir le tableau avec
#SET{truc, #ARRAY{truc,truc}}. Après tu utilises|array_pushpar exemple ou si tu as Bonux directement#SET_PUSHpour ajouter une cellule au tableau.Pour être plus précis, et d’une façon générale, il est IMPOSSIBLE de mettre une boucle DANS une balise.
Il faut faire comme le dit Rasta’ ^^ Par contre ya une subtilité pour remplir ton tableau, si tu veux des clés numériques précises (pour gérer tes pays par ID, typiquement).
Tu remplis le tableau avec des SET en #VALEUR => #CLE et a la fin (dans la partie ) tu inverse le tableau avec un array_flip php ; par exemple :
Ensuite tu peux initialiser proprement ta SAISIE avec un :
Hope that helps...
Mojo
Pardon, il fallait bien entendu lire
Pas bien important, mais mieux vaut être précis ;)
Ceci dit... si c’est juste pour les pays et pas le détail de la France entière, et bien le plugin « Pays » fournit déjà une saisie « pays ». D’ailleurs le plugin Saisies en a une aussi, mais qui utilise la table du plugin Géographie.
Nickel ! Ça marche !
Merci à tous les deux.
Répondre à ce message
Bonjour,
Merci pour ce plugin très pratique, cependant il serait judicieux de spécifier le fait que le plugin yaml est nécessaire pour utiliser la balise très utile : #GENERER_SAISIES . Car on ne trouve pas beaucoup d’aide sur le fait que la fonction yaml_decode_file ne soit pas définie.
Et pour être plus précis voilà le lien pour télécharger et installer ce plugin : http://files.spip.org/spip-zone/yaml.zip
Une autre erreur s’est glissé dans l’exemple : ’saisie’ => ’radios’ ( ligne 40 de l’exemple complet ). Il n’existe pas de squelette « radios.html ». Par contre il existe un squelette « radio.html ».
Il suffit donc de modifier cette ligne en remplaçant « radios » par « radio » afin que tout fonctionne correctement.
Bonne journée
petite inversion de code spip dans le lien pour le plugin yaml : plugin Yaml
Merci, j’ai fait les deux modifications.
Hello
Je déterre... Il manque toujours à ce jour un necessite de yaml, non ?
Ben non, comme je l’avais déjà dit autre part, il y a plein de plugin qui utilisent Saisies uniquement dans les squelettes avec la balise
#SAISIEsimple, pour que les formulaire soient plus lisibles. Et donc ils n’utilisent pas du tout l’API, et donc ils n’ont aucunement besoin de YAML.Il me semblais bien avoir vu passer un truc la dessus, mais je ne retrouvais plus... Donc c’est au plugin utilisant des fonctions de saisies utilisant YAML de faire le necessite... Faudrait peut préciser ça dans la doc...
Euuuh... c’est déjà le cas depuis le 12 octobre 2010... C’est marqué en gras + séparé par des barres en plein milieu de l’article.
Pfff... Et pourtant j’ai relu l’article avant de poster !
Répondre à ce message
Bonsoir,
J’ai installé le plugin formidable et mes premiers tests sont satisfaisants. Merci pour ce beau travail.
Reste un problème : l’affichage des lettres accentuées.
par exemple le é devient é
J’utilise SPIP en codage iso-8859-1
Si le le passe en UTF-8 tout va bien pour le formulaire mais plus pour le site bien sur (les lettres accentuées sont remplacées par des ? dans des losanges)
Je ne me sens pas de passer le site (squelettes, base, ...) en UTF-8 de suite et j’aimerais savoir si on peut modifier une config de Formidable (ou d’un plugin associé) pour résoudre ce problème. Mais recherches et essais n’ont pas abouti.
Merci par avance
désolé de « squatter » ce forum consacré au plugin Saisie mais je n’ai pas trouvé l’équivalent pour Formidable, mais je suis preneur de tout lien ...
Bonjour
je confirme : avec la même config (site en iso-8859-1) les caractères accentués sont tous convertis en signes bizarres.
A une époque, j’avais un souci équivalent avec Porte Plume et Matthieu avait apporté un correctif (voir ici : http://zone.spip.org/trac/spip-zone/changeset/34471)
Je ne maîtrise pas assez le code pour savoir si cette piste est la bonne, et si oui, pour l’intégrer dans Saisies (ou Formidable d’ailleurs)
En tout cas merci à tous pour votre travail.
Aucune idée, je n’y connais rien en charset et je fais toujours tout en UTF-8... Donc je ne sais pas trop où se trouve le problème pour l’instant.
Si quelqu’un veut aider, il faudra aussi dire où se trouve vos bugs là, parce que pour l’instant on sait juste que vous avez tous les deux des caractères bizarres, mais on ne sait pas où : dans le constructeur ? dans l’affichage du formulaire sur les labels et autres infos configurées ? dans le mail ? où ?
Les caractères accentués sont remplacés par ces caractères étranges dès la construction du formulaire dans l’espace privé de Spip, que ce soit dans l’écriture des labels, explications, ... et restent ainsi après enregistrement et lors de l’appel du formulaire depuis un article ainsi qu’à l’envoi par mail.
Par contre si en saisissant ces caractères directement en codade iso - en saisissant é pour le é par exemple - tout va bien, mais ce n’est pas très simple.
Ce qui est curieux c’est que l’on peut saisir sans problème une texte accentué dans un bloc de texte sans avoir d’affichage « codé ».
La solution sera sans doute de passer tout le site en utf-8 mais ce n’est pas une opération si simple.
Merci pour vos réponses
Répondre à ce message
Bonjour,
Avec le plugin Formidable, j’ai eu un problème avec une case unique : je voulais qu’elle soit cochée par défaut et pas moyen.
Dans le plugin saisies, fichier saisies/case.html, j’ai modifié la ligne 14 :
J’ai donc remplacé le filtre
|is_nullpar|=={''}(est vide).Avec
is_null, la variable « valeur » était toujours vide et le[ (#GET{valeur}|oui)checked='checked']n’affichait jamais rien.Le problème c’est que cette saisie et « oui_non », renvoient soit « on » soit « » (chaine vide). Donc la chaine vide n’indique pas qu’il n’y a rien, mais indique le « non » ou le « pas coché ».
Du coup si là tu mets coché par défaut, si tu sélectionnes volontairement pas coché et que tu reviens sur le formulaire (parce qu’un autre champ a une erreur par exemple) et bien ça restera à ta valeur par défaut.
Le problème est donc plus complexe. Il vient surtout du fait que le mécanisme CVT de SPIP ne laisse pas la valeur « null » mais la remplace par la chaine vide. Et donc ça ne correspond plus à la réalité. Il faut que je revois ça avec Cédric, ou faire une remarque sur la liste mail « spip-dev ».
Désolé, j’ai répondu au mauvais fil. Cela concerne le fil du 23/2/11
Merci pour ces explications claires.
J’ai presque fini d’intégrer le plugin Pays. Il me reste la partie analyse.
Sur Saisies, j’ai une remarque : si je met une contrainte sur un champ, par exemple saisie d’une url, si le champ est vide, cela envoie un message d’erreur après validation du formulaire. Cela ne devrait pas être le cas à mon avis. Il y a la contrainte obligatoire pour forcer la saisie.
Sur Saisies ou sur Formidable pour le dernier point ?
Sur Formidable, mais je pense que cela vient de Saisies. Je précise que c’est lors de la validation d’un formulaire sur l’espace public, pas dans la partie création d’un formulaire de l’espace privé.
Non l’erreur était bien là mais dans le plugin Vérifier. Faut mettre à jour en version 0.1.9 pour tester. Normalement ça devrait être bon : si le champ est vraiment vide ça ne fait pas de test.
Si tu as SVN tu peux tester tout de suite. Sinon faut attendre une heure que le nouveau ZIP arrive.
Répondre à ce message
Bonjour,
Je ne sais pas si c’est l’endroit pour discuter de formidable, qui porte bien son nom.
Je n’ai pas compris comment ajouté des fieldset. Je suppose que c’est lié au groupe de champs.Je ne vois pas bien comment on insère des champs dans un groupe de champs.
Je voudrais aussi insérer la liste des pays qui vient du plugins pays, mais là aussi je bloque.
quelques éclaircissements seraient le bien venu.
Merci
Ce n’est pas trop l’endroit effectivement mais il n’y a pas encore de doc officielle pour Formidable puisqu’il n’est pas encore « stable ».
Pour insérer des champs dans un groupe de champs (y compris un autre groupe) il suffit d’utiliser le tout premier paramètre dans le form de configuration qui s’appelle « Position ». On place un champ devant un autre champ ou bien à la fin d’une liste. Il faut donc le placer « à la fin » de la sous-liste du groupe de champ. Normalement quand il y a une sous-liste c’est bien décalé sauf sous Safari ou Opera je crois.
Pour le pays et bien il faudrait que vous fassiez une saisie « saisies/pays.html » et sa description des options « saisies/pays.yaml » ainsi que « saisies-vues/pays.html » et « saisies-analyse/pays.html » pour la visualisation, dans le plugin du même nom. Et si ça marche bien demander à quelqu’un de l’intégrer ou demander un compte pour contribuer vous aussi !
Répondre à ce message
Bonjour
A ropos de Formidable, comment faire apparaitre mon formulaire dans la page publique d’un article dans le site ? Le formulaire fonctionne très bien dans la partie privée.
J’ai mis ce code dans le squelette de l’article concerné : #FORMULAIRE_FORMIDABLE(Contribution) mais sans résultat.
Pour info Contribution est le nom donné au formulaire.
Merci de votre aide
dans le squelettes de l’article (article.html) ou bien dans le texte de l’article ?
de plus c sur la page de formidable que tu aurais du la poser
Merci de la réponse
C’est dans la page article.html
PS : J’ai cherché mais n’ai pas trouvé la page de formidable. En tapant formidable dans « Rechercher sur ce site », rien n’est indiqué concernant ce plugin.
Voila http://www.spip-contrib.net/Formidable-le-generateur-de-formulaires
Ce qui me dit que tu faire ainsi
Merci de cette réponse.
Comme indiqué dans mon premier message c’est ce que j’ai fait et qui ne marche pas ....
C’est pourquoi je recherche plus d’explications qui semblent introuvables sur le net.
Encore Merci
et on peux voir le site ?
Bonjour
Tout à fait, le site est :http://www.minitub43.com je souhaite que les visiteurs puissent apporter leur contribution à ce site par leurs documents en cliquant sur le lien du menu de gauche intitulé contribution qui pointe actuellement vers une rubrique puis un article. Le code #FORMULAIRE_FORMIDABLEcontribution figure actuellement dans le squelette de la rubrique et de l’article mais rien apparait.
Merci du coup de pouce.
Philippe
Bonjour
Je souhaite tout simplement remercier Pierre KUHN pour avoir trouvé solution à ma recherche.
C’est parfait.
Bonne semaine
Philippe
C’est bien de dire que le problème a été résolu et c’est sympa de dire merci. Par contre ce n’est pas très sympa de garder pour toi la solution qu’on t’a donnée et de ne pas faire profiter les autres : elle pourrait pourtant rendre service à des personnes qui rencontrent la même difficulté que celle que tu as rencontrée !!!
Allez, zou, un peu d’altruisme !!!
Manu
Oui, enfait il utilise forms&table et du coup je passer par un modèle dans l’article
<form2>Voila pour la solution
Hum hum
Premièrement je n’aurais pas su décrire la solution c’est Patrick qui l’a trouvé, ensuite faut dire qu’il n’y a pas eu grosse bousculade pour me répondre ... Alors Manu SVP modérez vos remarques désobligeantes et hâtives avant de donner une leçon de courtoisie d’autant plus que j’ai eu la correction comme vous l’avez remarqué de remercier la seule personne qui a prit la peine de répondre, chose rare sur ce forum me semble t’i en parcourant les différents forumsl.
Les reproches ou réflexions apparemment pour certains sont plus rapides que les réponses.
Bien courtoisement à vous.
PS : J’allais oublier ! Merci pour cette leçon d’altruisme.
Répondre à ce message
Bonjour
j’ai créé un formulaire avec le plugin Formidable. Tout c’est bien passé. En test je reçois bien le mail de confirmation d’inscription d’une personne. Sur ce mail il apparaît le texte suivant « Vous pouvez gérer les réponses sur cette page ». Lorsque j’ouvre cette page, j’accéde à l’espace privé : quand je clique sur le bouton « Liste des réponses rien ne se passe », quand je clique sur le bouton « Analyse des réponse » il apparait des statistiques avec les valeurs pour les différents items du formulaire et le bouton exporter les réponses ne provoque aucune action d’export.
Je ne sais comment accéder à cette page des réponses du formulaire directement sans passer par le lien du mail !
Ai-je oublié un paramétrage particulier ?
Merci pour le coup de main
Cordialement
Chez-moi-ça-marche. © :)
Quand je suis sur l’aperçu d’un formulaire dans l’espace privé, et que j’ai activé l’enregistrement, et qu’il y a eu au moins une réponse, j’ai bien :
Bonjour
Une personne vient de s’inscrire et ça marche
Merci
Répondre à ce message
Hello
2 petites questions :
- si on veut qu’une saisie soit dispo dans formidable, il faut que le fichier yaml correspondant soit présent dans le dossier saisies. Je veux rajouter un champ de saisie d’URL, mais le fichier yaml est identique a celui de l’input avec juste en plus une vérification possible de l’url, y’a pas moyen de surcharger celui de l’input ou de faire un « include » ? Ou faut dupliquer ?
- SI je veux supprimer les espaces avant et après une saisie d’url, où dois faire ce traitement ? Dans Saisies (mais je ne vois pas comment) ? Dans Formidable ?
Merci
Répondre à ce message
Bonjour,
La fonction afficher_si ne fonctionne pas avec des checkbox (c’est la réponse de Joseph. Il propose de faire évoluer la fonction saisies_generer_js_afficher_si dans inc/saisies.php mais cela dépasse mes compétences actuelles et ce n’est pas faute d’avoir essayé !).
Est il possible de contourner ce problème avec un javascript (je dispose d’un code permettant d’afficher un champ input de type texte si une checkbox est cochée.)
J’ai placé le script dans le head de mon formulaire html mais je ne sais pas où placer l’évènement javascript onClick, mes saisies étant générées par la balise #GENERER_SAISIES.
Est ce que quelqu’un pourrait me conseiller ?
Merci par avance.
Répondre à ce message
Bonjour,
j’ai un problème dans l’utilisation de l’option afficher_si pour des checkbox. Je voudrais dans un formulaire CVT que le fait de cocher une case fasse apparaître d’autres cases à cocher (et bien sûr si la case n’est pas cochée les autres choix ne sont pas proposés). J’arrive bien à utiliser l’option avec des boutons radio mais pas avec des checkbox.
J’utilise bien la balise #GENERER_SAISIES dans le fichier html de mon formulaire.
Si quelqu’un a une solution je lui en serais très reconnaissant.
Merci.
C’est Joseph qui a ajouté ça et je n’ai encore jamais eu le temps de jeter un œil sur le code. Donc il faudrait plutôt lui demander, mais je ne sais pas s’il passe par ici. Sur la liste SPIP-Zone ça aurait plus de chance par contre. Enfin je le croise virtuellement, je lui demanderai.
Bonjour et merci d’avoir pris le temps de me répondre.
Est-il possible de contacter joseph par courriel ?
Sinon je suis toujours intéressé par la solution s’il vous la donne lors d’une rencontre virtuelle (j’ai pour l’ instant contourné le problème avec des boutons radio mais cela ne me satisfait pas vraiment.)
Répondre à ce message
La fonction saisie_autonome n’a pas pas l’air surchargeable.
Dés lors comment composer des saisies complexes ou des saisies qui ne passent pas par _base.html ? obligé de passer par fieldset ?
Je me répond :
1) mais si elle est surchargeable puisqu’elle appelle le pipeline du même nom
2) on peut aussi se contenter de surcharger _base.html pour étendre la liste des saisies ’autonomes’ puisqu’il n’y a que là pour l’instant que cette fonction est appelée.
A la place de
#SET{saisies_autonomes,#VAL|saisies_autonomes}faire#SET{saisies_autonomes,#ARRAY{{fieldset, hidden, destinataires, explication, cequonveutenplus}}On a pas dû lire le même code de la même fonction.
On peut difficilement plus propre qu’un pipeline pour surcharger, non ?
Répondre à ce message
Je suis tombé sur une erreur « undefd function » en utilisant GENERER_SAISIES avec un array (fieldset...). C’était une fonction définie dans le plugin yaml qui manquait. yaml devrait donc apparemment apparaître en ’necessite’ ou ’utilise’ dans plugin.xml
Non car on peut très bien utiliser Saisies sans utiliser les fonctions de l’API. Et utilise ne ferait rien dans ce cas. C’est juste que si a besoin de l’API là on a besoin de YAML. C’est donc au plugin qui utilise Saisies *avec* l’API qui lui doit nécessiter YAML.
Répondre à ce message
Sur la dernier SVN, j’ai l’impression que #GENERE_SAISIES est en panne.
en gros voici ma fonction charger :
dans le le fichier formulaires/tedeum.html
et voilà ce que ca produit
Je suis en 2.1
mais quand on est bête ! J’avais mis saisies d’en extensions mais pas repassé par la case plugin->il était pas activé.
dsl pour le bruit
Hello
Je cherche un exemple de la fonctionnalité « verifier »... J’ai un truc comme ca :
Je pensais que ca se branchait tout seul sur l’api de vérification, mais apparemment non... Donc comment faire ?
Tu as déjà posé la question sur la liste et je t’ai déjà répondu là-bas. :)
Déjà il n’y a pas d’API de vérification automatique, c’est toi qui doit appeler ci ou ça.
La plugin Saisies fournit dans son API, une fonction nommée
saisies_verifier(). À toi de l’utiliser.OK, mais à quoi sert le plugin « verifier » du coup ?
Ben a fournir l’API de vérification !
saisies_verifier()« lit » ta déclaration dont tu parles, et appelle l’API de Vérifier pour appliquer ce que tu as déclaré.OK, faut m’expliquer longtemps, c’est l’age...
Si j’ai bien compris, faut passer par
#GENERER_SAISIESplacer entres les ul du formulaire. Avec un tableau php créé dans la fonction charger du formulaire et utilisersaisies_verifier()dans la fonction de vérification du formulaire en lui passant $formulaire en paramètre.Mais est-ce sensé fonctionner aussi avec cfg ?
#GENERER_SAISIESn’affiche rien :config_plugintest_fonctions.php :
et dans config_plugintest.html :
Euh je ne connais pas
cfg_config_plugintest_charger. Dans tout formulaire CVT c’estformulaires_montruc_charger().Ben je ne l’ai pas inventé, j’ai vu ça dans un plugin de kent1 et j’ai fini par trouver la doc : http://www.spip-contrib.net/API-CFG...... Est-ce donc à cause de ce fonctionnement particulier de CFG que generer_saisies ne fonctionne pas ?
Ah oui c’est vrai qu’avec CFG, dès qu’il y a une des fonctions de CVT, ça ne marche plus justement. Ben je sais pas alors, je connais pas du tout l’API CFG. Si tu as aussi Bonux sur ton site, ya peut-être moyen d’essayer l’API de configuration mise en place par Cédric, qui fait pareil que CFG mais avec CVT.
OK, je vais voir... Mais il se trouve ou ce plugin ? ou plutot comment qu’il s’appelle ?
Ben c’est Bonux t’ai-je dit. Faut fouiller sur la liste dev je crois pour trouver la doc, ou bien dans le code de Bonux, dans le dossier
/configurer/.OK merci pour les infos
Répondre à ce message
Sujet : comment ajouter de nouveaux champs entrées item dans Formidable générateur de Formulaire
J’ai pu installer et faire fonctionner Formidable générateur de Formulaire sur squelette sarkaspip3.0.3
avec spip2.1 en local sur wamp1.7.0
Comment avec ce plugin très intéressant dont j’admire la réalisation :
on peut ajouter des champs supplémentaires en plus de ceux qui existent :
- je ne sais pas ou regarder
- c’est dans la partie fonctionnelle ?
- CVT j’ai du mal à comprendre
- par où commencer
- faut aller ajouter des scriptes dans un plugin , mais lequel et comment ?
Merci de votre aide, et excusez moi de mon ignorance, car je débute sur ce sujet
Vous voulez ajouter de nouveaux types de champs, si je comprends bien ?
Il faut donc tout simplement ajouter des Saisies, ainsi que leur description dans un fichier YAML du même nom.
Par exemple dans votre dossier squelettes/ ou dans votre plugin à vous, il faut créer un dossier
saisies/dans lequel vous mettrez des couples de fichiers HTML/YAML.Le fichier YAML permet de décrire le nom humain qu’aura la saisie dans Formidable, son icône ainsi surtout que toutes ses options.
Pour vous aider, il suffit de vous inspirer des fichiers YAML qui existent déjà dans le plugin Saisies. Vous en copiez un et vous partez de ça pour décrire vos propres options.
Répondre à ce message
Bonjour
J’aimerais pouvoir inserer un texte d’explication en intro d’un fieldset. Ce n’est pas possible apparemment, est-ce une evolution envisageable ?
N’est-ce pas pourtant le but de la saisie « explication » ? :)
Tout à fait, je ne voyais rien dans l’article des références... Je l’ai trouvée en fouillant dans le code...
Ah mince, il faut mettre à jour l’article.
Voilà l’article des références a été mis à jour.
Hello, b_b viens de me faire découvrir l’option « couleur » aussi qui n’est pas dans les références
Oui c’est parce qu’en fait les références sont construites automatiquement à partir des descriptions YAML des saisies. Or je n’ai décrit en YAML que les saisies qui avaient vocations à être utilisable dans Formidable par le commun des mortels.
C’est un peu bête, ouais. Sinon faut la décrire quand même, mais du coup cette saisie se retrouvera dans la liste des champs possibles de Formidable. C’est pas un drame hein, ça peut toujours servir.
Répondre à ce message
Salut
J’utilise SAISIES dans un formulaire de config de plugin. Je ne pige pas comment se fait l’initialisation de la valeur par defaut. Par exemple si je rajoute
valeur : #ENV{valeur}au debut du fichier saisies/oui_non.html, ca m’affiche « on » meme si je n’ai rien dans la table meta de mon plugin. Du coup le test suivant du même fichier#SET{valeur,#ENV{valeur}|is_null|?{#ENV{defaut},#ENV{valeur}}}ne prend jamais la valeur « defaut » que je defini dans le formulaire... Je ne pige pas bien ce fonctionnement et surtout d’où vient le « valeur » de l’environnement ? Si tu peux me donner une piste de recherche...Merci
Je comprends pas trop ce que tu dis...
Ça s’utilise comme ça le défaut il me semble :
Oui, pas facile d’être clair...
D’abord, si tu va voir le code http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/oui_non.html moi je comprend que ce qui est testé c’est oui ou non pour définir le bouton qui cheched :
[ (#GET{valeur}|oui)checked='checked']Effectivement toujours dans le même tag input, c’est l’attribut value qui vaut « on » ou rien. Donc a priori c’est « on » ou rien qui est enregistré dans la meta...
Mais admettons qu’on n’a pas de meta, d’où vient
#ENV{valeur}en début de ce fichier ? Si je lit bien cette ligne#SET{valeur,#ENV{valeur}|is_null|?{#ENV{defaut},#ENV{valeur}}}: si valeur n’est pas définie dans l’environnement, on crée la variable valeur en l’initialisant avec defaut définie dans l’environnement... Et ça, ça n’a pas l’air de fonctionner.c’est automatiquement calculé... #SAISIEx,y n’est qu’un raccourcis pour écrire (de mémoire) :
Merci Matthieu...
Tu as bonne mémoire. J’ai pigé : Pour « checker » un bouton radio, on peut mettre n’importe quoi dans « defaut » et pour le « unchecker », il ne faut rien mettre.
Répondre à ce message
Bonjour,
J’ai un problème avec le plugin FancyBox qui utilise Saisies pour être activé. Lorsque je vais sur la page publique (un article comportant des photos) utilisant ce plugin, il m’affiche une erreur :
Erreur : $(« li.fieldset.pliable ») is null
Fichier Source : http://www.myspherelife.com/plugins/auto/saisies/javascript/saisies.js
Ligne : 8
J’ai donc désactivé tous les plugins sauf Bonux (v 1.9.7) et Saisies (v 1.7.5) et l’erreur est toujours là. Je précise que je suis sous SPIP 2.1. Le cache est vide, idem pour celui de mon navigateur. Je suis sous FF 3.6 et j’ai testé sous IE 8, même problème.
J’ai désactivé mes scripts js persos présents sur la page. Du coup je vois plus trop ce que je peux faire et j’aurais voulu savoir ce que vous en pensiez.
Merci.
Je n’ai cette erreur sur aucun de mes sites où se trouve Saisies, donc je ne comprends pas. Surtout le code en question n’est pas bien complexe : si ça trouve des « li.fieldset.pliable » alors ça fait ceci-cela. S’il n’en trouve pas, ça ne doit tout simplement rien faire. Donc ce n’est pas normal que ça puisse générer une erreur lorsqu’il ne trouve rien, surtout s’il n’y a plus rien d’autre du tout que ce script.
Vraiment là, je ne comprends pas. :(
Je viens de faire de tests sur ta page et tu dois avoir une erreur de chargement de jQuery. C’est comme s’il ne trouvait pas du tout jQuery.
Sur ta page j’ai lancé des scripts basiques du genre :
$('div')pour que jQuery me liste toutes les balises div, et même là il me sort « null ». Donc il y a un problème plus en amont de le script de Saisies.Je viens de renvoyer via FTP tout SPIP 2.1, j’ai également vidé le répertoire /tmp, on sait jamais. Toujours l’erreur :-/
Je vais essayer de remonter dans la hiérarchie de SPIP pour voir du côté de jQuery. Merci pour l’aide :)
Répondre à ce message
comment faire pour empecher saisie.js d’etre chargé sur les pages publics ?
On ne peut pas pour l’instant. C’est pour quel besoin ?
c’est car je n’utilise pas le jquery natif et du coup j’ai une erreur js venant de saisie car il ne trouve pas onAjaxLoad
Les ajouts jQuery de Saisies sont utilisés par la saisie « fieldset » pour l’instant, et bientôt pour d’autres saisies pour différents besoins. Je ne vois pas trop comment détecter automatiquement tous les usages possibles et s’ils sont effectivement utilisés dans la partie publique à tel ou tel moment précis. Donc le javascript est toujours présent, vu le peu d’octets qu’il contient... Et effectivement il n’est pas pensé pour fonctionner sans les scripts ajoutés par SPIP (qui ne sont pas « jquery » d’ailleurs, mais des scripts ajoutés en plus à côté aussi).
Donc plusieurs solutions :
- est-ce que tu veux juste changer la version de jQuery ? Dans ce cas tu devrais faire en sorte que ça ne supprime pas les ajouts que fait SPIP (et qui sont bien dans des fichiers autres que celui du jQuery de base).
- sinon on peut aussi ajouter une constante qui permettrait de désactiver le chargement du js de Saisies dans la partie publiques.
En fait même si on fait la deuxième solution pour les cas extrêmes, cela n’empêche pas la première : en effet si toi tu enlèves carrément jQuery, là je comprends que ça ne puisse pas marcher ; mais si tu utilises juste un autre jQuery, pourquoi est-ce qu’il n’y a pas moyen de faire marcher avec les scripts supplémentaires de SPIP ?
c’est ce que propose porte_plume par exemple avec define(’PORTE_PLUME_PUBLIC’, false) ;
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 :
|
