Saisies

Published : 27 March 2010 – updated on 14 September 2022 – by Maïeul, RastaPopoulos – 702 commentaires

1
2
3
4
5
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 :

  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.

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.5.1 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 = array(…);
    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 = array(
    array(…), // une saisie
    array(…), // une saisie
    array(…), // 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 :

array(
    'saisie' => 'input',
    'options' => array(
        '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 = array(
    'saisie' => 'fieldset',
    'options' => array(
        'nom' => 'mon_groupe',
        'label' => 'Mon groupe de champ'
    ),
    'saisies' => array(
        array(…), // une autre saisie
        array(…), // une autre saisie
        array(…), // 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.

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

array(
	'saisie' => 'input',
	'options' => array(
		'nom' => 'slug',
		'label' => 'slug',
		'obligatoire' => 'oui',
	),
 
	'verifier' => array(
		array(
			'type' => 'taille',
			'options' => array('min' => 10)
		),
		array(
			'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 : 
array(
    'saisie' => 'input',
    'options' => array(
        'nom' => 'nom',
        'label' => 'nom',
        'obligatoire' => 'oui',
    ),
    'verifier' => array(
 
        'type' => 'entier',
        'options' => array(
            '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.

array(
    'saisie' => 'input',
    'options' => array(
        '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 = array(
    'options' => array(
        // Changer l'intitulé du bouton final de validation
        'texte_submit' => 'Valider c’est gagné',
        …
        '<option>' => '<valeur>' //Une autre option
    ),
    array(…), // une saisie
    array(…), // une saisie
    array(…), // 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.

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 l’appel au pipeline formulaire_verifier.

  1. Déclarez la dépendance à Saisies dans le fichier paquet.xml de votre plugin, afin que votre appel au pipeline passe systématiquement après celui de Saisies.
  2. Déclarez dans votre paquet.xml l’appel au pipeline formulaire_verifier (lire la documentation sur programmer.spip.net)
  3. Dans la fonction appelée, faites vos vérifications : 
    function <prefixeduplugin>_formulaire_verifier($flux) {
  if ($flux['args']['form'] == '<nomduformulaire>') {//Verification du formulaire <nomduformulaire> après que saisies ait vérifié
    $saisies =  saisies_chercher_formulaire($flux['args']['form'], $flux['args']['args'], true); // Trouver les saisies associées au formulaire, si besoin
    // Faire ses propres vérifications
    $flux['data']['<champ>'] = 'erreur' // Exemple pour ajouter une nouvelle erreur sur le champ <champ>
  }
  return $flux;
}

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 :

<form ....>
....
<div>
    #GENERER_SAISIES{#ENV{_saisies}}
</div>
....
</form>

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].

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 soit :

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 :

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

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

array(
    'saisie' => 'input',
    'options' => array(
        '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.

Footnotes

[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
Filter

166 discussions

  • 1
    Julien

    Avec SPIP 4.1.5 et tous les plugins à jour, le champ extra sélecteur d’article ne marche plus (alors que sélecteur article ou rubrique marche bien) (on peut bien sélectionner des articles, mais ils ne sont pas visibles dans la fiche article après enregistrement de l’article) : spip enregistre dans la base articles|25 et non article|25.
    Si, via phpmyadmin on supprime le S, alors tout marche bien.
    Je ne sais pas trop qui gère ce libellé : saisie ? Bonux ? Iextra ?

    Une idée de l’origine de ce s intempestif ?

    Merci de votre aide.
    Julien

    • JLuc

      Merci de pas poster la même question en différents endroits, ça multiplie le travail pour te répondre ... et d’autres personnes intéressées par le même sujet n’auront que des petits bouts de l’ensemble des réponses.
      En l’occurrence la réponse a été fait là : Bonux pour SPIP3

    Reply to this message

  • 6
    DD

    Je viens de mettre à jour ce plugin vers 4.5.0 sur 2 sites en SPIP 4.1.5 sur 2 serveurs différents

    et depuis impossible modifier les sites référencés :
    Page blanche sur /?exec=site_edit

    dans distant.log je vois :
    IP adresse IPV6        108151         Privé         erreur         Erreur connexion 0
    mais je ne sais pas si c’est lié.

    Merci

    • Stéphane Santon

      Bonjour,
      Pareil pour moi, voici l’erreur affichée :

      Fatal error: Uncaught Error: Call to undefined function test_formulaire_inclus_par_modele() in /home/lycee/emploi/ecrire/inc/editer.php:226
Stack trace:
#0 /home/lycee/emploi/plugins-dist/sites/formulaires/editer_site.php(59): formulaires_editer_objet_charger(‹ site ›, ‹ oui ›, ‹  ›, ‹  ›, ‹ http://emploi.p… ›, ‹ sites_edit_conf… ›, Array, ‹  ›)
#1 /home/lycee/emploi/plugins/auto/saisies/v4.5.0/inc/saisies_formulaire.php(28): formulaires_editer_site_charger_dist(‹ oui ›, ‹  ›, ‹ http://emploi.p… ›, ‹  ›)
#2 /home/lycee/emploi/plugins/auto/saisies/v4.5.0/saisies_pipelines.php(265): saisies_chercher_formulaire(‹ editer_site ›, Array, true)
#3 /home/lycee/emploi/ecrire/inc/utils.php(236): saisies_formulaire_verifier(Array)
#4 /home/lycee/emploi/tmp/cache/charger_pipelines.php(520): minipipe(‹ saisies_formula… ›, Array)
#5 /home/lycee/emploi/ecrire/inc/utils.php(303): execute_pipeline_formulaire_verifier(Array)
#6 /home/lycee/emploi/ecrire/public/aiguiller.php(255): pipeline(‹ formulaire_veri… ›, Array)
in /home/lycee/emploi/ecrire/inc/editer.php on line 226
    • RastaPopoulos

      Mais pourquoi vous mettez ça là, quel rapport avec Saisies pour le moment ? Le plugins-dist “Sites syndiqués” n’utilise évidemment pas Saisies et l’erreur collée indique très clairement un fichier *du noyau* ecrire/inc/editer.php:226

    • RastaPopoulos

      Bon bé si ya peut-être bien un problème plus profond, dû à un appel aux fonctions charger() de *tous* les formulaires (même ceux qui n’ont pas de saisies déclarées) à un moment où ya des choses pas chargées… c’est à la fois dû à une nouvelle inclusion de Saisies ET à un mauvais code du noyau qui n’inclue pas le bon fichier pour être sûr avant d’utiliser une fonction qui est ailleurs.

    • Maïeul

      Et donc v4.5.1/v3.56.4 corrigent cela

    • DD

      Oui merci Maïeul, la nouvelle version élimine le problème pour moi.

    Reply to this message

  • 7
    bob

    La mise à jour du plugin saisie vers sa version 3.56.3 empeche la modification des articles dans spip 3.2.16.

    Oups. Une erreur inattendue a empêché de soumettre le formulaire. Vous pouvez essayer à nouveau.

    Reply to this message

  • 6
    Jeff

    Bonjour
    je viens d’installer SPIP 4.1.2 avec le plugin Escal 4.5.52, saisies 4.4.1 j’utilise wampserver 3.2.6 avec php 7.4.26, mySQL 5.7.36

    et lorsque je vais dans la config du plugin Escal (dans tous les items mise en page, éléments, page d’accueil,...) j’ai le message ci dessous :

    Warning : array_merge() : Expected parameter 2 to be an array, null given in C :\Site\wamp64\www[mon site]\plugins\auto{saisies\v4.4.1\inc\saisies_lister_disponibles.php on line 45

    Avez vous une idée pour supprimer ce warning ?
    Merci
    bonne journée

    • Maïeul

      1. Deja normalement les warnings ne devraient pas apparaitre publiquement -> il faut configurer ton hebergement pour éviter cela.
      2. Dans tous les cas, active le plugin YAML, ca évitera de les déclencher (et je vais de ce pas signaler cela au contributeur d’Escal).

    • Manu

      Bonjour,

      Pour info je rencontre le même souci sur un site en 4.1.5.
      Le squelette n’est pas ESCAL mais Html5up Phantom.
      La version de PHP est la 8.1.0.
      Le message apparaît sur les pages de modifications des articles ou des pages (plugin Pages uniques).
      L’installation du plugin Yaml a fait disparaître le message.

    • Jean Christophe Villeneuve

      Pour info, on me signale le même souci sur un site avec Escal et php 8.1.
      De mon côté je n’ai aucun souci avec php 7.4.28 ou 7.4.30 sur plusieurs sites.

    • Maïeul

      Comme expliqué, il faut que YAML soit installé pour que la declaration de formulaire en full PHP marche. Du coup il faudrait qu’Escal le marque en “necessite” dans son paquet.xml et ce sera bon.

    • Jean Christophe Villeneuve

      Comme Escal utilise saisies, je vais le faire mais à mon avis, ce serait plutôt à Saisies de le faire non ?
      D’autant qu’avec php 7.4, même sans yaml, je n’ai pas de souci.

    • RastaPopoulos

      Non puisque Saisies peut parfaitement être utilisé sans PHP uniquement en squelette, donc sans YAML, donc ya pas à obliger YAML pour ceux qui n’utilisent pas l’API PHP. Donc c’est à ceux qui utilisent l’API PHP de nécessiter YAML.

      Je vois pas ce qu’il y a de bizarre à ce que ça marche avant et pas après : tout l’objet de PHP 8 est justement de passer à un truc mille fois plus strict sur toutes les erreurs, donc ya plein de choses qui étaient juste des notices ou des warnings et qui maintenant génèrent des erreurs bloquantes.

    Reply to this message

  • 1
    tcharlss

    Je crois qu’il y a une coquille là :

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

    C’est < 4.3.0 plutôt

    Reply to this message

  • yann45

    Testé en spip 4.1.1 sans problème en forçant la borne.

    Reply to this message

  • 4
    François

    Bonjour,
    Le plugin semble incompatible avec spip 4.0.1 (ce qui bloque du coup la m-à-j de nombreux autres plugins). Existerait-t-il un moyen de contourner cette incompatibilité ? J’ai mis à jour tous mes sites à la v4.0.1 (dernière en date) en croyant que “compatible avec spip 4.0” signifiait “compatible avec 4.0.*”

    • François

      Merci, RastaPopoulos
      J’ai pu installer mes plugins.
      Mais allez savoir pourquoi, lors de mes premières tentatives, mon spip me signalait que le plugin SAISIES n’était pas la bonne version.

    • Freedux

      Bonjour,

      Il m’était aussi indiqué comme incompatible ainsi que quelques autres pourtant compatibles. Pas de menu “mettre à jour”, j’ai été obligé de le supprimer puis de le réinstaller via l’archive zip car je ne le retrouvais pas dans “ajouter des plugins”. Bizarre, surement un bug qui traîne sur la partie Core de Spip :(

      A suivre...

      P.S. : le plugins “Vérifier la compatibilité de vos plugins” indiquait aussi des informations erronées.

    • Maïeul

      Oui il y a un bug lors du passage à SPIP 4 sur SVP (le service qui permet d’installer/mettre à jour les plugins). Il faut supprimer le depot distant et le recreer.

    Reply to this message

  • 4
    baloo

    pour info. Je viens juste d’installer la version saisie V4.03 dans le répertoire plugin a la place de la précédente.
    Immédiatement ... je ne vois plus dans configuration des plugins ( actif ou incaif) , les plugins non verrouillés par exemple inserer_modele il semble que cela soit ceux dont l’id est supérieur a celui de saisie dans la table plugin. Je vois ceux dont l’id est inférieur .

    ils sont toujours dans la table plugin et dans le cache. J’ai effacé local et tmp... idem

    • baloo

      j’ai remis la version V4.02 .... mais je ne vois toujours pas les plugins.
      heureusement j’ai fait le test en local

    • baloo

      les plugins qui étaient déjà actif fonctionnent mais ne sont plus visible au niveau de la gestion des plugins.

    • RastaPopoulos

      Ton SVP a l’air un peu en vrac on dirait : &var_mode=reinstaller_svp

    • baloo

      merci ... les plugins sont visibles et actifs

    Reply to this message

  • 7
    JuL BLoBuL

    Bonsoir,
    J’ai une question quant au format de texte (html ou brut) à utiliser dans les options (info_obligatoire) des saisies, car selon différent cas de figure j’obtiens différent résultat, je m’explique.
    Un de mes clients insiste pour avoir des astérisques rouges pour les champs obligatoires dans un formulaire. Pour des raisons de confort technique j’utilise deux méthodes pour générer les saisies.
    D’un coté j’utilise la syntaxe #SAISIE :

                [(#SAISIE{input, firstname, 
                        label=<:zblobul_hanaf:prenom:>, 
                        explication = '',
                        obligatoire= 'oui',
                        info_obligatoire= <:zblobul_hanaf:info_obligatoire_asterix:>,
                        defaut = #ENV{firstname},
                })]

    Dans mon fichier de langue :

    'info_obligatoire_asterix' => '<b style="color:red">*</b>',

    Jusque la tout a bien, côté utilisateur, j’obtiens un astérisque rouge.

    J’utilise également la syntaxe php suivante :
    $saisies[]= array(
    ’saisie’ => ’selection’,
    ’options’ => array(
    ’nom’ => ’levels’,
    ’label’ => _T(’choix_niveaux_cours’),
    ’obligatoire’ => ’oui’,
    ’info_obligatoire’ => _T(’info_obligatoire_asterix’),
    ’datas’ => $datas_levels,
    )
    );
    Par contre, coté utilisateur, j’obtiens le code html :

    <b style="color:red">*</b>

    Le fait que j’utilise une chaine de langue ne change rien à l’affaire, j’ai testé sans.

    Merci d’avance pour votre aide.

    Julien

    • Maïeul

      coté PHP, dans l’environnement, ton tableau de saisies il porte bien un nom préfixé par _ ? dans le cas contraire il y a un echappement de la part de SPIP.

      Mais sinon, vu que de toute facon`info_obligatoire` passe automatiquement par `_T_ou_typo`, bah pas la peine de passer par `_T` côté php, tu met juste la chaine de langue en syntaxe spip (avec les chevrons).

      Je t’invite à relire la doc d’introduction à saisies ;-). Ainsi que le très bonne article de romy sur le signalement des obligations http://romy.tetue.net/signaler-les-champs-obligatoires

    • JuL BLoBuL

      Merci de l’info, j’ignorer qu’on pouvait se passer de _T pour les chaines de langue en php.
      Je viens de faire un teste :

      'info_obligatoire' => <:zblobul_hanaf:info_obligatoire_asterix:>,

      Mais ca passe pas :
      Parse error: syntax error, unexpected ’<’

    • JuL BLoBuL

      En tout cas effectivement il fallait effectivement que je rajoute le _ au nom de mon tableau de saisies.
      Cette subtilité m’échappe parfois, je l’ai pourtant mise en place sur la majorité de mes formulaires... Je me demande si l’inverse ne serait pas plus intuitif, devoir mettre le _ pour que spip échappe.
      Merci encore.

    • RastaPopoulos

      Après quand tu fais en PHP, ya quasiment aucune raison de faire le squelette toi-même justement. Comme l’indique la doc tu devrais plutôt laisser le squelette totalement vide et laisser Saisies générer cela bien comme il faut, en déclarant ton tableau dans tonformulaire_saisies(). De cette façon tu seras sûr que ça se génère comme il faut :)

    • Maïeul

      il manque les guillemets dans ton code php autour de ta chaine de langue :p

      quand aux règles de SPIP, ce sont les régles de spip, et j’ai tendance à penser que la sécurité par défut est une bonne régle (car n’oublie pas que #ENV peut potentiellement venir d’un POST)

    • JuL BLoBuL

      Oui RastaPopoulos, j’ai prévu de le passer complétement en php, c’est le cas mes formulaires en générale, mais celui-ci est long et compliqué, je l’améliore étape par étape ;)
      Pour Maieul, j’ai testé la syntaxe avec des apostrophes, sans succès, j’avais pas testé les guillemets ;)

      Merci à vous deux de vos lumières.

    • Maïeul

      oui alors apostrophe ou guillemet, je parlais bien de ce qui est utilisé en php pour définir un string :)

      En gros : si tu déclare en PHP, il faut utiliser la syntaxe de PHP :P

      (il vaut mieux préférer en général les simple quotes aux doubles quotes, car ces dernières impliquent une analyse du contenu à la recheche d’éventuelle $, donc un peu plus lent).

    Reply to this message

  • 7
    Natacha Courcelles

    Bonjour
    ma question est un peu bête mais dans un formulaire j’ai besoin de sélectionner une brève
    j’ai testé avec saisies/selecteur mais que des rubriques/articles
    aucun des sélecteurs proposés ne concerne les brèves : normal ?
    et y a t’il une solution ?
    Merci
    Natacha

    • Maïeul

      effectivement on n’a pas prévu la saisie breve, car... c’est un objet spip plus trop utilisé.

      Il faudrait

      1. Créer votre propre saisie en vous inspirant de la saisie articles
      2. Idéalement nous la partager pour qu’on puisse l’intégrer au plugin

    • Natacha Courcelles

      Merci Maïeul
      ceci dit je ne vois vraiment pas comment faire :-)

    • Maïeul

      commence par lire ceci https://contrib.spip.net/Creer-ses-propres-saisies (tu peux deja pour commencer te contenter de la première partie + éventuellement de la partie sur les héritages)

      Comme visiblement il n’y a nul part dans SPIP le besoin de selectionner une breve, tu pourrais te baser sur la saisie “selection” par ex.

    • RastaPopoulos

      Je suis dubitatif, car ça dépend du nombre : si l’idée des brèves c’est “des petits articles” et qu’ils peuvent être donc en quantité très importantes, genre des centaines ou plus dans chaque secteur, bah non un select va pas trop le faire… :)

      Je vois plutôt ça comme les sélections d’articles et de rubriques donc, mais c’est plus complexe à mettre en œuvre.

    • Maïeul

      effectivement. pour ce genre de cas avec beaucoup de choix, j’ai fait dans le cadre d’une association un input avec datalist. Ca marche pas trop mal (900 personne), mais je sais qu’à partir d’un certains nombre ca foire. peut être qqchose à base de choosen/select 2 ?

    • RastaPopoulos

      La manière graphique de le présenter à l’écran n’est pas trop ce qui me préoccupait là : c’est que c’est généralement mal de garder dans le HTML des centaines voire milliers d’éléments, juste pour permettre d’en choisir (ce qui est le cas avec ton datalist, ou un select qui utiliserait chosen). C’est bien pour ça que les sélecteurs d’articles et de rubriques ne fonctionnent pas comme ça (mais nécessitent ajax… mais c’est un gros défi de savoir faire des saisies dynamiques qui fonctionnent aussi sans JS).

    • Maïeul

      mais justement choosen a pas un API pour chercher en json, donc sans tout charger d’un coup ?

    Reply to this message

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 / PostgreSQL
  • 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 apparait.

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?
[Log in]

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

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.

Add a document

Follow the comments: RSS 2.0 | Atom