Saisies

Published : 27 March 2010 – updated on 11 June 2025 – by Maïeul, RastaPopoulos – 777 commentaires

77 Votes

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

Introduction

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

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

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

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

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

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

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

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

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

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

Principe

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

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

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

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

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

Mise en œuvre

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

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

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

Déclaration de l’ensemble des saisies

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

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

Déclaration d’une saisie individuelle

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

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

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

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

Déclaration des saisies enfants

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

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

Appliquer des vérifications

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

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

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

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

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

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

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

Support du multilinguisme

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

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

Options globales

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

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

Option	Usage	Valeur possible	Valeur par défaut
Options de prévisualisation
`previsualisation_mode`	Type de prévisualisation	Texte : `''` (pas de prévisualisation), / `dessus` / `etape`	`''`
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`
`squelettes_boutons`	Squelette utilisé pour le bouton de validation, si envie de surcharger (déconseillé)	Chaîne de caractère	`'formulaires/inc-saisies-cvt-boutons'`
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 de balisage
`ajax`	Mettre le formulaire en ajax	`True\|False`	`False`
`conteneur_class`	Classe supplémentaire à ajouter sur le conteneur (`(div)`	Chaîne de caractère	`''`
`conteneur_id`	Identifiant html du conteneur (`(div)`	Chaîne de caractère	`''`
`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`
`prefixe_id`	Préfixe arbitraire à mettre devant tous les attributs `id` balisant les saisies individuelles. Un tiret-bas `_` sera automatiquement inséré après le préfixe.	Chaîne de caractère	`''`
Options liées à la soumission
`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`

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_etape_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_etape_post_saisies.

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

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

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

Dans ce cas :

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

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

Exemple d’utilisation :

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

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

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

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

Par ailleurs, on utilisera

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

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

pour les boutons de validation.

Méthode 2 : la balise `#SAISIE`

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

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

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

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

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

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

Voici quelques exemples d’utilisation.

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

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

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

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

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

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

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

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

Appendice 2 : enregistrer des tableaux

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

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

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

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

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

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

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

Appendice 3 : la balise `#VOIR_SAISIES`

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

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

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

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

Appendice 4 : problème avec Xdebug

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

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

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

Et hop, ça remarche.

Footnotes

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

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

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

Discussion

5 years 1 year 3 months Without limit

par date

186 discussions

Ricardo

1 month ago

Salut à tous !

Je dois à nouveau faire appel à votre expertise. Je crée un plugin pour un nouvel objet éditorial comportant plusieurs champs de date, avec une valeur de base de données de 0000-00-00. Cependant, le formulaire d’édition charge la valeur 30/11/1999 et non un champ vide (ou du moins avec la valeur 0000, comme dans la date_redac des articles). Je n’ai trouvé aucune solution sur les forums. Auriez-vous des idées ?

Reply to this message
4

Ricardo

1 month ago

Bonjour, j’ai besoin d’aide. Je développe un plugin pour un nouvel objet éditorial et je ne parviens pas à assembler une saisie case, qui doit interagir avec un champ booléen 0/1 de la base de données.

Dans l’espace privé, je peux charger la bonne valeur sur la page d’aperçu de l’objet, mais pas sur le formulaire d’édition.

Si je modifie la valeur sur le formulaire d’édition, elle n’est pas soumise. Tous les autres champs du formulaire fonctionnent correctement.

J’ai cherché partout un exemple utilisant la saisie case, sans succès.

Le code de la saisie généré par La Fabrique est le suivant :
[(#SAISIE{case, wa_1, label=<:associado:champ_wa_1_label:/>})

Y a-t-il une âme charitable qui pourrait m’éclairer sur la démarche
- Maïeul
  
  1 month ago
  
  Bonjour,
  
  par défaut la saisie case renvoi 'on' lorsqu’elle est coché et '' (chaine vide) lorsqu’elle n’est pas coché. Et non pas 1 ou 0. Mais si tu consulte les références de saisie, tu verra qu’il y deux options valeur_oui et valeur_non pour modifier cela.
- Ricardo
  
  1 month ago
  
  Salut Maïeul, merci beaucoup pour ta réponse rapide !
  
  J’ai modifié le champ dans la base de données en tinytext(2) et remplacé 1 par on. Je peux maintenant charger la valeur du champ depuis la base de données, aussi bien dans la page d’aperçu que dans le formulaire d’edition’. Cependant, si je modifie la valeur dans le formulaire, ni l’aperçu ni la base de données ne sont mis à jour.
- Maïeul
  
  1 month ago
  
  Il faudrait que tu m’exporte le code pour que je comprennne le pouruqoi du comment. Là c’est trop flou en terme de reproduction.
- Ricardo
  
  1 month ago
  
  Oups, ça marche bien! Il y avait une faute de frappe dans mon fichier base/[object].php. Super merci pour ton aide.
Reply to this message
3
keisersuze

17 January
Bonjour,

Je rencontre un problème après avoir mise à jours le plugin SAISIE sur l’élément choix grille.
Je peux plus utiliser des clés numériques tels que :
1|Un 2|Deux 3|Trois
Les données sont bien inscrites dans la base de donnée, mais elles n’apparaissent pas dans le backoffice. Dois-je adapté avec : choix1|Un, choix2|Deux, choix3|Trois ? (ce qui ne m’arrange pas)

Ou un fixe est-il prévu ?

Merci beaucoup !
- Maïeul
  
  17 January
  
  C’esz sans doute un bug. Choix grille a connu pas mal d’amélioration, mais avec parfois des bugs introduits (c’est une saisie très complexe). Je regarde.
- Maïeul
  
  17 January
  
  J’ai ouvert une PR avec modification du code.
  
  https://git.spip.net/spip-contrib-extensions/saisies/-/merge_requests/499
  
  1 Codev vient de valider
  
  Je sortirai dans le courant de la semaine prochaine une nouvelle version de saisie.
  
  En attendant tu peux installer manuellement le plugin corrigé avec ce zip
  
  https://git.spip.net/spip-contrib-extensions/saisies/-/archive/master/saisies-master.zip
- keisersuze
  
  17 January
  
  Merci beaucoup !
Reply to this message
3

JuL BLoBuL

8 January

Bonjour,
Est-ce qu’il existe dans un plugin une saisie de type horaire (sans date associée).
En attendant j’essai de créer la saisie moi-même mais je galère.
Le but étant de proposer uniquement deux selects heures et minutes comme avec datetime mais sans la date ;)
Si cela n’existe pas, j’aimerais comprendre la bonne méthode pour traiter et charger les données saisies.
- Maïeul
  
  8 January
  
  Non cela n’existe pas. Ca pourrait valoir la peine cependant.
  
  J’ai écrit un article long comme un bras sur comment créer des saisies.
  
  > Si cela n’existe pas, j’aimerais comprendre la bonne méthode pour traiter et charger les données saisies.
  
  c’est là où je pense qu’il y a une mecomprehension : saisies ne traite pas les données :)
- JuL BLoBuL
  
  8 January
  
  Merci Maieul,
  Oui j’ai lu l’article de bout en bout, merci d’ailleurs cela m’a bien guidé jusque la, mais certaines notions m’échappent pour être honnête.
  Tutoriel : créer des champs extras depuis un plugin
  J’ai mes fichiers (contrôleur, vue et constructeur), cela apparait bien dans iextra.
  J’imagine que je dois manipuler les données reçues en utilisant les pipelines formulaire_charger et traiter?
- Maïeul
  
  8 January
  
  J’ai l’impression (mais je me trompe peut être) que tu ne fais pas encore bien la distinction la saisie et le champ extra, Champ extra s’appuie certes sur saisies (pas parfaitement bien d’ailleurs), mais c’est un autre problème. C?est bien champ extra qui doit traiter ta saisie, et pas saisies.
  
  Tu pourrais très bien créer ta saisie pour une autre raison que pour faire des champs extras. Par exemple pour faire un formulaire formidable (mais d’autres usages possible : un formulaire de config, une formulaire perso, etc.).
  
  La difficulté je pense auquel tu est confronté c’est que ta saisie renvoie 2 valeurs (l’heure et les minutes) alors qu’un champ sql / extra par définition c’est une seule valeur.
  
  C’est là où intervient une autre chose, qui est la normalisation des valeurs recus. Et ca se gère (de manière un peu étrange mais c’est comme ca) via une fonction de vérification du plugin vérifie que tu associe à la saisie concrète lié à ton champ extra.
  
  Autrement dit
  
  - créer une vérification “heure”
  - cette vérification aura une normalisation “sql”
  - faire appelle à cette vérification/normalisation lors que tu déclare ta saisie comme champ extra.
  
  Cela étant j’aurais tendance à penser que ton besoin étant générique, il serait sans doute plus pertinent d’avoir une option dans la saisie “date” pour générer uniquement l’heure (et ensuite on pourra créer les vérfications/normalisation associée) Ouvre un ticket, pour voir l’avis d’autres personnes.
Reply to this message
4
Benitron

October 2024
Bonjour,
en SPIP 4.2.16, un bug apparaît sur la page d’édition du groupe de mots-clé en back-office.
Je ne sais pas si le souci est au niveau de de saisies ou de motus, je poste sur les deux pages.
2 Erreur(s) dans le squeletteNuméro Message squelette boucle Ligne 1 Filtre select= non défini ../plugins/auto/saisies/v5.8.1/saisies/selecteur.html / 6 2 Paramètre d’inclusion incorrect : {fond=formulaires/selecteur/generique, selected=#GET{val}, name=#ENV{nom}, afficher_langue=#ENV{afficher_langue,''}, select= ../plugins/auto/saisies/v5.8.1/saisies/selecteur.html / 6
Dans le cadre habituel où l’on rentre les rubriques à restreindre, on a :
Restreindre aux rubriques ? Pour restreindre à certaines rubriques (et leurs enfants), vous pouvez selectionner les rubriques souhaitées ici. fond=formulaires/selecteur/generique, selected=, name=rubriques_on, afficher_langue=, select=, whitelist=Array, blacklist=Array, racine=, objet=racine, id_objet=0, env} />
Merci !
- Maïeul
  
  October 2024
  
  Il me semble que c’est le bug corrigé pas plus tard que ce week-end avec saisies 5.8.2, cf https://git.spip.net/spip-contrib-extensions/saisies/-/blob/master/CHANGELOG.md?ref_type=heads.
  
  Donc une mise à jour du plugin devrait corriger l’affaire.
- Benitron
  
  October 2024
  
  Merci !
  Du coup, les groupes de mots créés avant n’ont plus la saisie disponible, mais en les recréant, c’est bon.
- Maïeul
  
  October 2024
  
  Ah, c’est étonnant ca. Un var_mode=recalcul ca le fait pas ?
- Benitron
  
  October 2024
  
  C’est marrant, j’avais fait un recalcul et un vidage de cache, c’était toujours pas présent.
  J’étais passé par la navigation privée au cas où, puis vidage de cache de firefox idem.
  Je pars 1 heure, je reviens et c’est bon.
  Depuis le passage à la 4.2.16, c’est la deuxième fois que ça m’arrive (la dernière fois avec des modifs de page et de CSS non prises en compte, puis 1h après c’est bon). Mais coïncidence n’est pas corrélation ;) Je ferais gaffe la prochaine fois si cela se reproduit.
  Bref, en conclusion, ça marche à présent.
Reply to this message
3
JuL BLoBuL

October 2024
Bonjour,

On me remonte un comportement inattendu et gênant.

Sur un champs extra (déclaré via un plugin) ou un champs extra ajouté via Iextras.
Que ce soit sur un article, événement ou infolettre...

Lorsqu’on ajoute dans le texte saisie un dollar ($) suivi d’un nombre, qu’on enregistre, et qu’on l’édite à nouveau, le dollar et le chiffre disparaisse (alors qu’ils sont présent en BDD et dans l’environnement)...
Par exemple :
$123456789 12346789$ $ABCD ABCD$
Donne :
3456789 12346789$ $ABCD ABCD$
Le même champs affiché via de l’html affiche bien tous le contenu...
- Maïeul
  
  October 2024
  
  Le même champs affiché via de l’html affiche bien tous le contenu...
  
  Ce n’est pas très clair... les choses sont forcément affichés via de l’HTML.
  
  Quelle code / balise spip utilise tu pour afficher avec le bug ?
- Maïeul
  
  October 2024
  
  Et encore une fois, les rapports de bug c’est plus simple lorsque ca passe directement en ticket.
- JuL BLoBuL
  
  October 2024
  
  Et voici le ticket
  https://git.spip.net/spip-contrib-extensions/saisies/-/issues/446
Reply to this message
2
JMarc_64

August 2024
Bonjour et merci pour ce plugin super pratique,

Je rencontre une petite anomalie d’affichage sur la page de configuration d’un plugin personnel. Le label d’un textarea est décalé sur la gauche dans la configuration:
- Saisies pour formulaires 5.5.1
- SPIP 4.3.1

Ce n’était pas le cas avec la même version de plugin mais en SPIP 4.2.14

Ma balise :
[(#SAISIE{textarea,texte,explication=<:banniere:explication_texte:>,label=<:banniere:label_texte:>,obligatoire=non,rows=5})]
Je pense que le nouveau spip/forms.css.html a évolué en 4.3 en ajoutant notamment
.formulaire_spip .editer > .editer-label
alors qu’auparavant en 4.2 c’était le style
.formulaire_spip .editer_texte labelqui était pris en compte pour le label du textearea.

Quelqu’un d’autre a t-il le même comportement ?
Merci.
- Maïeul
  
  August 2024
  
  Coucou,
  
  je t’invite à ouvrir un ticket sur l’espace des tickets, il y a des gens plus compétents que moi en css là bas qui pourront voir la meilleure solution.
- JMarc_64
  
  August 2024
  
  Hello,
  
  C’est bon, j’ai ouvert le ticket sur le plugin Saisies. A voir si c’est l’endroit le plus pertinent...
  
  Merci !
Reply to this message
1

Antoine LUCAS

July 2023

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.
- Maïeul
  
  July 2023
  
  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.
Reply to this message
5

JLuc

May 2023

Bonjour
Pour une saisie input déclarée avec la balise #SAISIE et dont on veut qu’elle ne saisisse qu’un entier, est-ce qu’on peut utiliser ’verifier’ ? et avec quelle formalisme alors ?
- RastaPopoulos
  
  May 2023
  
  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.
- JLuc
  
  May 2023
  
  Ah OK. Merci j’oubliais.
- RastaPopoulos
  
  May 2023
  
  https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies/input.html#L28
  
  L’option “type”
- JLuc
  
  May 2023
  
  J’avais cherché la doc de type et pas pigé : la doc principale de type semble être là : Référence des saisies mais ça indique Texte 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 ?
- Maïeul
  
  May 2023
  
  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.
Reply to this message
3

Christophe

April 2023

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 ?
- Maïeul
  
  April 2023
  
  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.
- Christophe
  
  April 2023
  
  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é.
- Maïeul
  
  April 2023
  
  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.
Reply to this message

« Previous 1 2 3 4 5 ... 19 Next »

Add a comment

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

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

Merci d’avance pour les personnes qui vous aideront !

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

Who are you?

Name [Log in]

Email (not published)

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

Text of your message

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Notify me of new comments to this discussion by email

Add a document

Authorized extensions: gif, jpg, png

Follow the comments: |

Saisies

Introduction

Table of contents

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

Principe

Mise en œuvre

Déclaration de l’ensemble des saisies

Déclaration d’une saisie individuelle

Déclaration des saisies enfants

Appliquer des vérifications

Support du multilinguisme

Options globales

Options de prévisualisation

Options pour le bouton de validation

Options pour la gestion des étapes multiples

Options de balisage

Options liées à la soumission

Pipeline

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

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

Méthode 2 : la balise `#SAISIE`

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

Appendice 2 : enregistrer des tableaux

Appendice 3 : la balise `#VOIR_SAISIES`

Appendice 4 : problème avec Xdebug

Discussion

Discussions by date of activity

Add a comment

Saisies

Introduction

Table of contents

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

Principe

Mise en œuvre

Déclaration de l’ensemble des saisies

Déclaration d’une saisie individuelle

Déclaration des saisies enfants

Appliquer des vérifications

Support du multilinguisme

Options globales

Options de prévisualisation

Options pour le bouton de validation

Options pour la gestion des étapes multiples

Options de balisage

Options liées à la soumission

Pipeline

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

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

Méthode 2 : la balise #SAISIE

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

Appendice 2 : enregistrer des tableaux

Appendice 3 : la balise #VOIR_SAISIES

Appendice 4 : problème avec Xdebug

Discussion

Discussions by date of activity

Add a comment

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

Méthode 2 : la balise `#SAISIE`

Appendice 3 : la balise `#VOIR_SAISIES`