Saisies

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

75 votes

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

Introduction

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

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

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

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

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

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.

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 pour le bouton de validation
`texte_submit`	Texte du bouton de validation	Texte, passe par `_T_ou_typo()`	`<:bouton_enregistrer:>`
`afficher_si_submit`	Condition pour afficher le bouton de validation	Voir « Affichage conditionnel des saisies : syntaxe des tests »	`null`
Options pour la gestion des étapes multiples
`etapes_activer`	Activer la gestion multi-étapes, chaque `fieldset` de premier niveau devient une étape	`True\|False`	`False`
`etapes_presentation`	Mode de présentation des étapes en haut du formulaire	`'defaut'\|'courante'`, il est possible de créer son propre mode en créant un squelette `formulaires/inc-saisies-cvt-etapes-<presentation>.html`	`defaut`
`etapes_suivant`	Texte du bouton pour aller à l’étape suivante	Texte, passe par `_T_ou_typo()`	`<:bouton_suivant:>`
`etapes_precedent`	Texte du bouton pour revenir à l’étape précédente	Texte, passe par `_T_ou_typo()`	`<:precedent\|ucfirst:>`
`etapes_precedent_suivant_titrer`	Permet d’ajouter le titre des étapes dans les boutons « précédent » et « suivant »	`True\|False`	`False`
`etapes_ignorer_recapitulatif`	Permet de ne pas insérer de récapitulatif avant la validation finale	`True\|False`	`False`
Options techniques
`verifier_valeurs_acceptables`	Permet de s’assurer que les valeurs reçues figurent bien parmi les valeurs proposées lors de la saisie du formulaire	`True\|False`	`False`
`afficher_si_avec_post`	Permet que les saisies masquées par affichage conditionnel soient tout de même postées	`True\|False`	`False`
`inserer_debut`	Contenu arbitraire à insérer au début du formulaire, par exemple pour appeler un script Javascript	Chaîne de caractères	`null`
`inserer_fin`	Contenu arbitraire à insérer à la fin du formulaire, par exemple pour appeler un script Javascript	Chaîne de caractère	`null`

Si un texte passe par _T_ou_typo(), cela peut être :

un texte directement écrit dans la langue du site ;
un appel à une chaîne de langue sous la forme <:fichier_de_langue:chaine:> ;
un texte utilisant la balise <multi> pour gérer l’internationalisation.

Pipeline

Lors du chargement des saisies déclarées via une fonction formulaires_<nom_du_formulaire>_saisies(), les saisies sont passés à un pipeline formulaire_saisies. Le tableau $flux passé à ce pipeline à la structure suivante :

- $flux['args']['form'] : le nom du formulaire ;
- $flux['args']['args'] : les différents arguments passés ;
- $flux['data'] : les saisies.

Il est donc possible à un plugin de modifier dynamiquement les saisies d’un formulaire en utilisant les différentes fonctions de l’API de saisies.

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

Parfois il est nécessaire d’avoir des vérifications supplémentaires sur les saisies. Pour ce faire, vous devez déclarer votre propre fonction formulaires_<nomduformulaire>_verifier().

Dans ce cas, vous ne perdrez pas le bénéfice d’une déclaration des vérifications de base dans votre tableau de saisies : celles-ci sont alors automatiquement effectuées après vos propres vérifications.

Toutefois, il est parfois nécessaire de faire en sorte que les vérifications « par déclaration » se fassent avant vos propres vérifications. Dans ce cas, la méthode la plus propre est de déclarer ses vérifications non pas sous forme d’une fonction formulaires_<nomduformulaire>_verifier(), mais par la création d’une fonction formulaires_<nomduformulaire>_verifier_post_saisie(), ou sa variante verifier_etapes_post_saisies() dans le cadre du multiétape.

À noter qu’il existe deux pipelines pour ajouter des vérifications à un formulaire existant : formulaire_verifier_post_saisies et formulaire_verifier_etapes_post_saisies.

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

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

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

Dans ce cas :

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

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

Exemple d’utilisation :

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

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

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

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

Par ailleurs, on utilisera

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

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

pour les boutons de validation.

Méthode 2 : la balise `#SAISIE`

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

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

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

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

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

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

Voici quelques exemples d’utilisation.

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

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

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

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

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

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

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

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

Appendice 2 : enregistrer des tableaux

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

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

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

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

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

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

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

Appendice 3 : la balise `#VOIR_SAISIES`

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

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

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

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

Appendice 4 : problème avec Xdebug

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

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

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

Et hop, ça remarche.

Notes

[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 ans 1 an 3 mois Sans limite

par date

179 discussions

5

Stéphane Santon

Mai 2020

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
- Maïeul
  
  Mai 2020
  
  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.
- Stéphane Santon
  
  Mai 2020
  
  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
- Maïeul
  
  Mai 2020
  
  Il faut mettre _saisies parce que c’est conventionnel ET parce que c’est ce que renvoie la detection automatique des saisies définie par formulaires_monformulaire_saisies_dist
- RastaPopoulos
  
  Mai 2020
  Bah ça dépend ce que tu fais, si tu fais tout tout seul tu fais bien ce que tu veux.
  
  Mais
  
  si tu personnalises le squelette en utilisant la déclaration magique des saisies en PHP, bah t’es bien obligé d’utiliser cette variable puisque c’est ça qui est remplis dans charger() par l’automatisme
  si inversement tu gères le charger toi-même mais que tu utilises le squelette par défaut, t’es bien obligé de renvoyer cette variable là dans charger puisque c’est ça qu’attend le squelette générque
  
  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.
- Stéphane Santon
  
  Mai 2020
  
  OK c’est clair.
  Peut-être à préciser dans l’article.
  
  Merci à tous les deux.
Répondre à ce message
1

Stéphane Santon

Mai 2020

Bonjour,
Dans l’exemple
formulaires_monformulaire_saisies_dist(…) {
Qu’il y-a-t-il dans les “…” entre les parenthèses ?

Merci
- Maïeul
  
  Mai 2020
  
  Normalement les mêmes choses que dans les fonctions _charger(), _traiter(), etc. Je précise la doc.
Répondre à ce message
1

EtienneJ

Avril 2020

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 :-)
- RastaPopoulos
  
  Avril 2020
  
  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
5

guilaind

Avril 2020

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
- RastaPopoulos
  
  Avril 2020
  
  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.
- guilaind
  
  Avril 2020
  
  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
- Maïeul
  
  Avril 2020
  
  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)
- guilaind
  
  Avril 2020
  
  Merci
  Je vérifierai ce soir ou demain
- guilaind
  
  Avril 2020
  
  J’ai du supprimer et ajouter les dépôts pour corriger le problème
  Merci
Répondre à ce message
5

Michel du lac de Créteil

Février 2020

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.
- Maïeul
  
  Février 2020
  
  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...
- Rpnpif
  
  Février 2020
  
  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.
- Rpnpif
  
  Février 2020
  
  Ça n’empêche que ce bug est étonnant et je ne l’explique pas.
- Rpnpif
  
  Février 2020
  
  @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.
- Maïeul
  
  Février 2020
  
  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
Michel du lac de Créteil

Février 2020

C’est OK maintenant !
Merci !
Michel

Répondre à ce message
11

guilaind

Février 2020

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.
- RastaPopoulos
  
  Février 2020
  
  Quelle màj ? En passant de quelle version à quelle version ?
- guilaind
  
  Février 2020
  En version 3.31.3 de SAISIES ça fonctionne. Sur /ecrire/ ?exec=admin_plugin j’ai un message
  
  Saisies pour formulaires 3.31.3 - stable version obsolète
  
  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.
- RastaPopoulos
  
  Février 2020
  
  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.
- guilaind
  
  Février 2020
  
  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
- RastaPopoulos
  
  Février 2020
  
  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é…
- guilaind
  
  Février 2020
  
  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.
- RastaPopoulos
  
  Février 2020
  
  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.
- Maïeul
  
  Février 2020
  
  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
- RastaPopoulos
  
  Février 2020
  
  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.
- guilaind
  
  Février 2020
  
  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
- guilaind
  
  Février 2020
  
  @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
1

Florence HENRY

Février 2020

(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 ?
- Maïeul
  
  Février 2020
  
  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
2

Arcocide

Janvier 2020

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
- Maïeul
  
  Janvier 2020
  
  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.
- Arcocide
  
  Janvier 2020
  
  super merci :)
Répondre à ce message
3

DD

Septembre 2019

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 1^e erreur concerne : SPIP Bonux 3.4.6 - stable (désactivé de facto)
- Maïeul
  
  Septembre 2019
  
  met a jour aussi bonux vers 3.5.0
- Michel
  
  Septembre 2019
  
  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
- Maïeul
  
  Septembre 2019
  
  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

« Précédent 1 ... 2 3 4 5 6 ... 18 Suivant »

Ajouter un commentaire

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

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

Merci d’avance pour les personnes qui vous aideront !

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

Qui êtes-vous ?

Nom [Se connecter]

Courriel (non publié)

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Texte de votre message

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Prévenez-moi de tous les nouveaux commentaires de cette discussion par email

Ajouter un document

Extensions autorisées : gif, jpg, png

Suivre les commentaires : |

Saisies

Introduction

Sommaire

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 pour le bouton de validation

Options pour la gestion des étapes multiples

Options techniques

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 par date d’activité

Ajouter un commentaire

Saisies

Introduction

Sommaire

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 pour le bouton de validation

Options pour la gestion des étapes multiples

Options techniques

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 par date d’activité

Ajouter un commentaire

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`