Saisies

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

Introduction

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

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

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

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

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

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

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

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

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

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

Principe

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

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

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

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

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

Mise en œuvre

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

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

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

Déclaration de l’ensemble des saisies

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

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

Déclaration d’une saisie individuelle

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

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

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

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

Déclaration des saisies enfants

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

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

Appliquer des vérifications

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

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

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

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

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

Pour les versions du plugin < 4.3.0, il n’est possible de déclarer qu’une seule vérification par saisie, sous la forme :
[
    'saisie' => 'input',
    'options' => [
        'nom' => 'nom',
        'label' => 'nom',
        'obligatoire' => 'oui',
    ],
    'verifier' => [
            
        'type' => 'entier',
        'options' => [
            'min' => 100,
            'max' => 500
        ],
    ],
];

Support du multilinguisme

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

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

Options globales

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

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

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

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

Pipeline

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

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

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

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

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

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

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

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

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

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

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

Dans ce cas :

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

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

Exemple d’utilisation :

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

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

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

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

Par ailleurs, on utilisera

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

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

pour les boutons de validation.

Méthode 2 : la balise #SAISIE

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

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

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

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

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

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

Voici quelques exemples d’utilisation.

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

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

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

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

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

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

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

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

Appendice 2 : enregistrer des tableaux

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

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

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

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

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

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

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

Appendice 3 : la balise #VOIR_SAISIES

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

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

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

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

Appendice 4 : problème avec Xdebug

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

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

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

Et hop, ça remarche.

Notes

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

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

Discussion

179 discussions

  • 4
    Chourak

    Bonjour,

    Est-il voulu que sur une saisie de type radio et obligatoire (en html5) il n’y ait pas de required="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

      To avoid confusion as to whether a radio button group is required or not, authors are encouraged to specify the attribute on all the radio buttons in a group. Indeed, in general, authors are encouraged to avoid having radio button groups that do not have any initially checked controls in the first place, as this is a state that the user cannot return to, and is therefore generally considered a poor user interface.

    • 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

  • 1
    Alexandre

    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

  • 2

    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

  • 3

    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 :

      Edgard : la boule de cristal est en panne : on va avoir besoin d’une url pour voir ton site et comprendre le problème

      Parce que chezmoiçamarche © :p

    Répondre à ce message

  • 2

    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

  • 3

    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

  • 4

    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 balise li devant 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_formulaire que l’on retourne div, en dur, à la place de li pour 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

  • 1

    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

  • 6

    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 :

      error_reporting(E_ALL^E_NOTICE);
      ini_set ("display_errors", "On");
    • 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 <?php au 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 de inc/filtres_selecteur_generique.php avec la fonction SPIP include_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

Ajouter un commentaire

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

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

Merci d’avance pour les personnes qui vous aideront !

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

Qui êtes-vous ?
[Se connecter]

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

Ajoutez votre commentaire ici

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

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom