Formulaire de participation à un évènement avec Formidable

Formulaire de participation permet d’indiquer lors des traitements d’un formulaire construit avec le plugin Formidable si l’on doit traiter une inscription d’une participante à un évènement.

Installation

Ce plugin nécessite le plugin Formidable et s’installe comme tous les plugins de SPIP, voir http://www.spip.net/fr_article3396.html. Il utilise également le plugin Agenda.

Fonctionnalités

  • Lors de la réponse à un formulaire, il est possible de créer une participation à un évènement. Cette participation peut être
    • automatique, quelque soit la réponse apportée
    • Ou bien dépendre d’un champ du formulaire
  • L’évènement auquel une participation est ajouté sera :

Utilisation

1- Créer un évènement (ecrire/?exec=evenements) et relever son identifiant

Trouver le numéro de l’évènement

2- Créer un formulaire Formidable (ecrire/?exec=formulaires) avec au moins un champ email.

-  Si la participation n’est pas automatisée, mais dépend de la réponse à un champ, créer le champ en question. Typiquement, il peut s’agir d’un champ de type « Bouton radios » ayant
deux valeurs possibles : l’une pour la participation, l’autre pour la
non participation ou la désinscription.

Champ de participation à un évènement


-  Si l’évènement n’est pas fixe, il faut ajouter une saisie de type "Sélecteur d’événements". Vous pouvez configurer pour afficher cette saisie sous forme de cases à cocher : dans ce cas il est possible de s’inscrire à plusieurs évènements d’un seul coup.

3- Dans le formulaire, en colonne de gauche, choisir « Configurer les traitements » (/ecrire/?exec=formulaire_edit&id_formulaire=1&configurer=traitements).

Configurer les traitements formidable

Cocher l’option « Inscription à un évènement ». Le formulaire de configuration de ce traitement se déplie.

Activer le traitement « Inscrire à un événement »

Voici le détail des différents réglages.

La participation est-elle automatique ou dépend-t-elle de la valeur d’un champ du formulaire ?

Dans la seconde option, indiquez le champ permettant de participer et la valeur qui enclenchera la participation à un évènement.

Inscription à un évènement selon la valeur d’un champ de formulaire

Identité de la personne qui participe à l’évènement

Qui participe à l’évènement ?

À quel évènement faut-il ajouter une participation ?

Il y a deux possibilités :
a. L’évènement proposé est fixe, dans ce cas, préciser l’identifiant (numéro) de l’évènement

Inscription à un évènement fixe

b. L’évènement varie d’une réponse à l’autre, dans ce cas, préciser le champ renvoyant l’évènement.

Inscription à un évènement selon un champ

Inscription multiple

Il est possible, depuis la version 1.4.0, de faire que la soumission d’un formulaire inscrive plusieurs fois la personne à un évènement. Par exemple, si la personne s’inscrit avec sa famille, elle peut indiquer dans un champ le nombre de personne total. Il y aura donc plusieurs inscriptions à l’évènement sous le nom de la même personne, associé à la même réponse.

Inscrire plusieurs fois une personne

4- Dans le formulaire formidable, relever le N° identifiant (18) et l’insérer à la rédaction d’un article ou d’un évènement comme ceci <formulaire|formidable|id_formulaire=18> pour l’activer.

Insertion du formulaire

5- Vos visiteureuses peuvent s’inscrire ou se désinscrire (si le même email est entré) sur la page dans lequel le formulaire a été inséré.

Exemple de formulaire de participation

6- Pour gérer/exporter la liste des personnes inscrites à un évènement, utiliser les réponses du formulaire formidable.

Désinscription d’un évènement

Depuis la version 1.2.0, lorsqu’une réponse d’un formulaire Formidable est dépubliée, l’inscription à l’évènement est annulée (basculement en non), et réciproquement. Mais attention, cela ne fonctionne que pour les réponses enregistrées après la mise à jour du plugin vers la version 1.2.0.

Pour aller plus loin

Actualisation du champ maj de la table spip_evenements

Dans quelque cas très spécifique, on peut considérer que l’ajout / la suppression d’une inscription à un évènement est un type de modification de l’évènement.

Si la constante PHP _FORMIDABLE_PARTICIPATION_ACTUALISE_MAJ est égale à true, alors l’ajout/la suppresion d’une inscription via formidable actualise le champ ’MAJ’ de l’évènement.

Cela peut être utile par exemple lorsqu’on veut synchroniser entre plusieurs sites des évènements avec le plugin Import ICS.

Pipeline

Ce plugin propose de créer un pipeline qui renvoie les champs qui sont intéressants à récupérer dans un formulaire de participation : Nom, Prénom, Email, Organisation, Réponse etc

Le pipeline se nomme traiter_formidableparticipation et est visible sur https://git.spip.net/spip-contrib-extensions/formidable_participation/src/branch/master/traiter/participation.php#L93

Il est donc utilisable par tout autre plugin pour d’autres types de traitements récupérant ces résultats.

Liste d’attente

Voir le tutoriel "Tutoriel : utiliser Agenda, Formidable et Formulaire de participation pour gérer des inscriptions et des listes d’attente".

Discussion

4 discussions

  • 11

    Bonjour,

    J’ai une question quant à la récupération des inscrits.
    Est-ce que c’est avec Formidable Tablesorter — afficher, trier et filtrer vos réponses qu’on fait ça ?
    Ou est-ce qu’il y a quelque chose de plus convivial ? (je cherche à remplacer le plugin https://git.spip.net/spip-contrib-extensions/reservation_evenement).

    Merci

    • Agenda propsoe un minima, ensuite bah oui formidable table sorter permet d’aller plus loin. On peut difficilement faire convivial sur un truc qui releve du tableau excel.

    • Je n’arrive pas trop à comprendre pourquoi tous ces énormes trucs compliqués, alors que si le but c’est de bloquer à un truc déjà prévu en avance par le squelette, il suffit que l’événement soit… dans un champ Hidden… hidden_1 => #ID_EVENEMENT.

      Dans la config du form ajouté par le plugin, il suffit juste que le plugin accepte aussi que l’id_evenement puisse venir d’un champ hidden, et non pas que d’une saisie événement.

      Et basta, rien à coder, aucun PHP…

    • Tout simplement parce que si tu lis l’autre fil de discussion, la saisie Événements présente dans le plugin Agenda gère en plus l’affichage (et le paramétrage) d’une notion de liste d’attente.

    • On parle bien d’une saisie, donc d’un truc… que tu configures en amont en tout premier lieu dans la création des champs de ton formulaire Formidable ? Donc… pourquoi ya pas juste une option « disable mais posté » à la saisie (comme PLEIN d’autres saisies), qui permet d’avoir une valeur par défaut déjà rempli (y compris par le squelette donc) MAIS de pas pouvoir la modifier ensuite ?

      Pareil, 0 PHP à coder, juste une option dans le squelette + le YAML de la saisie.

    • Parce que la saisie Événements affiche dans la liste déroulante le rang dans la file d’attente. Et comporte un JS qui provoque l’affichage de la case à cocher supplémentaire décrite dans Tutoriel : utiliser Agenda, Formidable et Formulaire de participation pour gérer des inscriptions et des listes d’attente

      Et qu’avec la PR : https://git.spip.net/spip-contrib-extensions/agenda/pulls/80 un squelette peut passer en paramètre l’id du seul événement qu’on veut afficher dans la liste, en bénéficiant du reste de la mécanique de gestion de la liste d’attente sans avoir à la recoder.

      PS : et oui, j’ai déjà posé la question de qu’est-ce que ce code spécifique à Formidable participation faisait dans le plugin Agenda, mais c’est une autre question...

    • Ma réponse précédente parle bien d’utiliser la saisie Événement existante telle quelle. Juste de lui ajouter une option pour pas pouvoir l’éditer, donc ne pas générer de liste déroulante. Donc bien la bloquer sur un unique évnément déjà passé par défaut (peu importe que ce défaut vienne de la config interface du formulaire, ou depuis le squelette). Donc bien avec la config « événement fixe » puisqu’il ne faut justement pas générer de liste déroulante si le but c’est d’avoir qu’un seul événement unique forcé.

      La seule différence c’est qu’il faut juste pouvoir passer l’id en param squelette, et non pas juste depuis la config du constructeur. Mais sinon cest bien la même chose : n’avoir qu’un seul événement.

    • Ah au fait : ma première réponse à ce fil a parfaitement été fait dans un form ouvert dans l’AUTRE fil qui était bien en rapport. Donc je sais pas ce que SPIP ou Comments a branlé… mais ya eu un problème (je viens seulement de voir que c’était pas dans le bon fil, et c’est point de ma faute).

    • Mais c’est bien l’objet de ma PR : pouvoir passer en paramètre une option du formulaire (ce qui n’est pas nativement prévu dans formidable : c’est sûr que ce serait encore plus générique si ça n’était pas que cette option spécifique, mais un moyen générique de passer en paramètre une option ou un tableau d’options à un formulaire via squelette).

    • Je comprends toujours pas. Ya rien à passer depuis le squelette autre que l’id_evenement, et ça ya déjà une option du form pour ça.

      Le fait de configurer la saisie… bah c’est dans la config de la saisie, quand on construit le formulaire.

    • J’ai vraiment besoin de paramétrer un formulaire d’inscription générique sur un événement particulier correspondant à l’article affiché présentement.

      Donc, je ne peux pas le faire à la création du formulaire, mais seulement à son appel.

    • Je ne comprends toujours pas lol… Je parle bien DE PASSER DYNAMIQUEMENT l’événement par le squelette, donc bien d’un truc générique…

      Quelque soit la config général ya bien une saisie Événement dans le formulaire.

      Mais la CONFIG de la saisie Événements et du formulaire doivent permettre de dire qu’on veut un événement fixe ET non modifiable ET que ce qui est passé en param des champs par défaut, ça prenne le pas sur le numéro mis en dur dans la config.

      Donc j’ai toujours bien l’impression que c’est que un problème de YAML et de squelette de la saisie, je vois pas du tout pourquoi yorait besoin de pipeline, de PHP etc pour faire ça. Faut améliorer la saisie existant et possiblement la config générale ajoutée par ce plugin-ci.

    Répondre à ce message

  • 15

    Bonjour,

    J’ai une question sur la notion de liste d’attente.
    C’est géré dans une option de la saisie Événements.
    Au lieu d’être une option du traitement.

    Quelques suggestions/idées à débattre :

    • est-ce que le statut des réponses pourrait dépendre de ce que c’est une inscription alors qu’il reste des places ou non :
      • Statut proposé si validation de l’inscription manuelle
      • Statut validé si inscription automatique et reste des places
      • Statut Refusé si liste d’attente
      • Statut Poubelle si inscription annulée
    • Une saisie informative donnant le titre de l’événement, sa date, son lieu, et le nombre de places + statut liste d’attente ou complet serait-elle pertinente ?
    • Compliqué, car on peut vouloir refuser après coup une inscription, sans vouloir pour autant mettre à la poubelle.

      APlanète Sciences refusé = annulé, poubelle = detruite car c’était des tests.

    • AH il y a un très bonne raison pour que les gens sur liste d’attente soient malgrès tout décomptés : ca permet de savoir la place restante sur liste d’attente.

    • Je vais préciser ma question alors : actuellement, je ne vois aucune différence entre une inscription faite alors qu’il restait encore des places, et une inscription après épuisement des places.

      Alors, évidement, on peut faire ça en dehors de SPIP dans le tableur.
      Mais avpir une indication de cette information dans la table spip_evenements_participants et dans la page de visualisation d’une réponse (?exec=formulaires_reponse&id_formulaires_reponse=65), ça serait pratique.

      Quant à la place restante en liste d’attente, je ne comprends pas de quoi tu parles. En effet, dans l’interface d’un événement, je ne vois que nombre de places, mais aucune notion de liste d’attente.

    • Je t’invite à lire le tutoriel sur les listes d’attentes : si tu implemente comme il y est expliqué le fait de cocher explicitement que tu es sur liste d’attente, bah tu vois les gens qui font inscription avec liste d’attente. Et les gens peuvent savoir combien il y a de personnes avant elles à l’inscription.

      Quant à présentation sur la page d’un evenement : si tu as 3 places et 5 personnes inscrites, c’est bien qu’il y a 2 sur liste d’attentes.

    • Effectivement, ça marche bien avec la saisie Événements et ça enregistre l’information de la case liste d’attente.

      Mais, dans ce cas, ce dont j’aurais besoin, c’est de pouvoir contraindre par le squelette la liste des événements à un seul.
      Mais ce code ne fait que présélectionner l’événement, pas limiter la liste à ce seul événement :

      #FORMULAIRE_FORMIDABLE{inscriptionevenement, #ARRAY{input_1, #SESSION{email},input_2, #SESSION{nom}, evenements_1, #ID_EVENEMENT}}
    • Si tu avais explicité tes problématiques depuis le début, à savoir vouloir à la fois un evenement determiné par squelette et un affichage des places restantes, on aurait peut être pu penser autrement les choses et réflechir plus posément.

      Bon là j’aipas de solution toute faite, c’est un cas qui ne s’était pas posé encore.

    • Là comme cela je pense que le plus simple dans ce cadre serait d’utiliser le pipeline formulaire_charger pour modifier le contenu de _saisies dynamiquement (avec la fonction saisies_modifier)

    • Est-ce que tu as un exemple quelque part dont je pourrais m’inspirer ?

      Parce que là, à froid, j’ignore où commencer.

      Le besoin précis, c’est :

      1. je suis dans un article quelconque dans le site
      2. dans le squelette de l’article je veux appeler le formulaire d’inscription
      3. qui soit paramétré par l’événement rattaché à l’article pour ne proposer que celui-ci à l’inscription

      J’ai donc bien #ID_EVENEMENT au moment où le squelette appelle le formulaire. Mais j’ignore comment coder ce que tu suggère.

    • Par ailleurs, je dois avouer que je suis surpris du découpage entre :

      Est-ce que la notion d’héritage de saisies n’aurait pas permis un découpage différent ?

      Ou, peut-être mieux encore, est-ce qu’une saisie « Liste d’attente » ne serait pas plus pertinente ?(qui serait une cas à cocher, dépendante d’un champ à désigner contenant l’id de l’événement choisi, et affichant dans son la zo,ne d’information la position dans la liste d’attente (au lieu de l’afficher dans la saisie Événement qui n’aurait plus besoin d’avoir cette surcharge)

      Qu’en dis-tu ?

    • Par ailleurs, je dois avouer que je suis surpris du découpage entre :

      La tu melange deux choses : le découpage du code et le découpage de la doc. Au niveau du decoupage de la doc, le fait d’avoir parlé des listes d’attentes dans un article à part (mais qui je le reconnais devrait plutot être dans cette rubrique plutot que dans agenda), vise simplement à alléger le présent article, pour ne pas parler d’un besoin marginal.

      La raison du découpage du code est assez claire :
      -  les saisies sont toujours dans les plugins qui fournissent l’objet (car on peut avoir besoin d’une saisie evenement autrement que pour un formulaire de participation, par ex pour des formulairs bilan, des champs extra etc).
      -  la pseudo saisie liste d’attente ne peut pas être une saisie « case à cocher » car
      a. Il faut pouvoir faire des tests conditionnels sur le fait que l’evenement choisi est ou pas sur liste d’attente, par exemple pour poser des questions uniquement si on n’est pas sur liste d’attente
      b. Pourquoi la forme case à cocher plutoque oui / non, selection etc ?
      Le fait d’avoir une pseudo saisie dynamique @evenements_xxx_liste_attente@ permet de la souplesse.

      et aucune prise en compte de la notion de liste d’attente dans ce plugin Formidable Participation (alors que c’est là que tout ce qui concerne les listes d’attente aurait logiquement eu sa place, séparément de la saisie utilisée pour choisir l’événement)

      Par ce que formidable participation n’a pas pour vocation de gérer tous les problèmes, mais de permettre de rassembler des briques. On peut très bien imaginer gérer les listes d’attentes par d’autres biais.

      Est-ce que la notion d’héritage de saisies n’aurait pas permis un découpage différent ?

      heu ???

      au lieu de l’afficher dans la saisie Événement qui n’aurait plus besoin d’avoir cette surcharge)

      Il n’y a aucun surcharge pour le coup (même si si tu veux tu peux surcharger !). Mais non ca peut diffilement être dans une saisie à part, puisque le statut liste d’attente/nombre de place restante dépend de l’evenement qu’on choisit. Ou alors il aurait fallut un mecanisme de chargement en ajax... pas forcément plus simple en terme de maintenance.

      Pour revenir sur le fond.

      qui soit paramétré par l’événement rattaché à l’article pour ne proposer que celui-ci à l’inscription

      et le jour où tu a plusieurs evenements, tu fais quoi ?

      Bon et sinon je t’ai donné toutes les pistes : le nom du pipeline (mais entre temps je me suis rendu compte qu’il y en avait un plus pertinent), le contenu à modifier et même la fonction pour modifier. Mais allons plus loin.

      1. creer le formulaire comme si le chargement de l’id_evenement n’était pas dynamique
      2. appeler le formulaire dans ton squelette en lui passant en troisième paramètres des paramètres supplémentaires
      #FORMULAIRE_FORMIDABLE{<id_du_formulaire>,<valeur_par_defaut_des_champs>,#ARRAY{id_evenement,#ID_EVENEMENT}}
      3. Declarer l’appel au pipeline formulaire_saisies (en s’assurant de passer après saisies, donc en déclarant un dépendance à saisies) et modifier les paramètres de la saisie evenements_1 : (code écrit sur le tas, pas testé).

      ```
      function prefixe_formulaires_saisies(array $flux) : $flux
      $form = $flux[’args’][’form’] ;
      $args_du_form = $flux[’args’][’args’] ;
      $id_evenement = $args_du_form[2][’id_evenement’] ; // Ce qui a été passé en troisième argument du formulaire

      if ($form === ’formidable’ and $args_du_form[0] == )
      $flux[’data’] = saisies_modifier($flux[’data’], ’evenements_1’, [’options’ => [’id_evenement’ => $id_evenement]], true) ;// Ajouter un id_evenement constant sur la saisie evenement

      return $flux ;

    • YES !

      Ça marche avec :

      function formidableparticipation_formulaire_saisies(array $flux) {
      	$form = $flux['args']['form'];
      	if ($form === 'formidable') {
      		$args_du_form = $flux['args']['args'];
      
      		if (isset($args_du_form[2]['id_evenement']) && isset($args_du_form[2]['champevenement']))
      			$id_evenement = $args_du_form[2]['id_evenement']; // Ce qui a été passé en troisième argument du formulaire
      			$champevenement = $args_du_form[2]['champevenement']; // Ce qui a été passé en troisième argument du formulaire
      
      			$flux['data'] = saisies_modifier($flux['data'], $champevenement, ['options' => ['id_evenement' => $id_evenement]], true) ;// Ajouter un id_evenement constant sur la saisie evenement
      	}
      
      	return $flux ;
      }

      Et comme appel :

      #FORMULAIRE_FORMIDABLE{inscriptionevenement, #ARRAY{input_1, #SESSION{email},input_2, #SESSION{nom}, evenements_1, #ID_EVENEMENT}, #ARRAY{id_evenement, #ID_EVENEMENT, champevenement, evenements_1}}

      En passant en paramètre et le champ concerné,, et l’id de l’événement, ça me semble suffisamment générique.

      Je fait une PR ?

    • Bof... encore une fois ce n’est pas lié a ce plugin en soit le fait de limiter la saisie evenement en lui passant dynamiquement des paramètres....

    • Ce serait mieux de le mettre sur le plugin Agenda ?
      Dans la mesure où il :

      <utilise nom="saisies" compatibilite="[3.49.0;[" />

      ça marcherait aussi.

    • Ni l’un ni l’autre, à mon avis c’est un problématique à part qui nécessite un plugin à part. Mais touti a sans doute aussi un avis sur le sujet.

    • Dans la mesure ou ça concerne un paramétrage de la saisie se trouvant dans le plugin Agenda, plugin et que ça correspond au besoin d’afficher le formulaire d’inscription avec seulement l’événement/les événements associé(s) un article donné :

      1. c’est un besoin assez générique, surtout dans le cadre d’une migration depuis Réservation d’événements
      2. et que faire un plugin juste pour ça, c’est quand même un gros marteau pour ça

    Répondre à ce message

  • 3

    Bonjour,

    Je voudrais utiliser ce formulaire dans un squelette en passant en paramètre l’id de l’événement concerné.

    #FORMULAIRE_FORMIDABLE{even_test1, #ARRAY{input_1, #SESSION{email},input_2, #SESSION{nom}, evenements_1, #ID_EVENEMENT}}

    Ça marche bien avec une liste déroulante.
    Mais justement, je n’en veux pas : je veux juste un champ caché contenant l’id.
    Sauf que le constructeur ne permet pas de sélectionner un champ caché comme source de l’id.

    Est-ce que je m’y prend mal ? Comment faire ?

    • Oui c’est vrai que pour des raisons d’ergonomie, on a limité le choix du champ de l’evenement à une saisie evenement.

      Je suis partagé sur la meilleur solution :
      -  soit effectivement ouvrir au champ caché, mais ca alourdit un peu l’ergonomie et de toute facon ca passe par un squelette
      -  soit ajouter une option passable à l’appel du formulaire traiter_participation_id_evenement (comme on a traiter_email_destinataire. Mais bon, ca voudrait dire aussi autoriser de ne pas choisir explicitement l’id_evenement, donc à ce compte là.

      Donc peut être la première solution, celle à laquelle tu pensais, est la meilleure. Auquel cas il faut simplement modifier les options forcer_type dans le fichier .yaml. Je te laisse faire une PR ?

    • J’ai fait une PR, merci pour la piste.

    Répondre à ce message

  • 9

    Bonjour,

    bravo pour ce travail,

    dans mon cas, je souhaiterais l’utiliser pour des réservations, ce qui me plairait c’est d’avoir une case pour le nombre de places.

    Exemple : pour une personne inscrite avec sa femme et ses 2 enfants, elle ne va pas remplir quatre fois le formulaire avec quatre adresses mails différentes ! si ?

    Je suis juste intervenu pour faire avancer le travail, sinon je sors ;-)

    Cordialement
    Alain

    • Effectivement, merci, ça peut être une idée de développement futur.

    • Bonjour, ce plugin me semble très utile pour notre fédération sportive. Est-ce que maintenant, le plugin permet l’inscription multiple, c’est-à-dire, par exemple, un coach qui vient avec 8 enfants ?....

      Merci.

    • malheureusement pour le moment pas. Il faudrait implémenter d’abord dans formidable un système pour avoir un même champ répétable plusieurs fois pour une même réponse...

    • Bonjour Maïeul,
      Merci pour la réactivité !!... Il ne s’agit pas de créer un enregistrement pour chaque enfants... mais uniquement de prendre en compte le nombre total à décrémenter sur le nombre de participations

    • Oui, mais du coup quand la personne rempli le formulaire, elle donne juste le nombre de personne ou bien elle donne des détails sur les personnes ?

    • Bonjour Maïeul,
      Il s’agit de groupes d’enfants accompagnés d’un coach. Donc, les renseignements dont j’ai besoin...
      Ce sont les coordonnées du coach (tél, e-mail, école, adresse école), le nombre d’enfants participants, la classe ou la catégorie du groupe et c’est tout, le reste est renseigné par l’événement en lui-même.

    • Bonjour Maïeul,

      Je reviens vers toi pour répondre au fil

      Je disais donc qu’il me faut donc uniquement un seul enregistrement par inscription, je n’ai pas besoin de connaître le détail pour chaque participants mais le nombre de participant total pour une inscription.

      J’espère que ma réponse est plus claire que la précédente.

      Encore merci d’avance pour la réactivité.

    • Bonjour,

      oui c’est très clair. Cela étant, les inscriptions avec Agenda sont individuel. Donc le présent plugin devrait faire des inscriptions virtuelle. Pas impossible à faire mais demande du temps de dev (que je n’ai pas).

    • Voilà et encore merci pour le développement pour ce plugin... Après avoir patiemment attendu, la récompense est de taille ! Tout fonctionne parfaitement sous Spip 4.1 !

    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