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.
[
'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>.htmlla 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.
Discussions par date d’activité
179 discussions
Bonjour,
et merci pour ce plugin qui simplifie bien les choses !
En évolution, sera t-il possible d’uploader un document, une image par exemple ? Ce serait génial !
Répondre à ce message
Bonjour,
J’aimerais savoir quelle format doit avoir la colonne d’une table sql qui reçoit les données de saisie ’checkbox’ ou cases à cocher ?
Spip 3.0.16 et Saisies pour formulaires 1.40.4 - stable...
Merci d’avance de votre aide !
Une table SQL ne reçoit pas le contenu d’une saisie HTML. C’est traité par CVT avant. Or les champs HTML checkbox, select multiple, et certains autres, génèrent au serveur (donc ici PHP) des tableaux (array PHP donc).
À chacun⋅e d’en faire ce qu’ille veut avant d’envoyer dans la base. Ça peut être dans une table dédié à ces choix (je sais pas, je ne connais pas le contexte moi), ou bien basiquement une sérialisation du tableau (
serialize()) donc une chaîne de caractère (donc un champ SQL « text » à priori).Merci de tes explications.
Je vais approfondir le sujet en me basant sont ta courte, mais ô combien utile, réponse.
Bien à toi !
Répondre à ce message
J’utilise plusieurs champs date dans mon formulaire à l’aide de saisie.
Cependant le code suivant ne me permet pas d’avoir le calendrier au clic sur l’icone :
car l’inclusion du « formulaires/dateur/inc-dateur » est double et empêche le bon affichage de celui-ci.
Pour que cela fonctionne, je dois faire :
Est-ce normal ?
Merci
Non ce n’est pas normal, mais il faudrait corriger le inc-dateur du noyau qui ne devrait pas insérer deux fois le même JS si on l’appelle plusieurs fois. Il faudrait un test avec une variable globale ou un truc comme ça pour savoir qu’il a déjà été appelé avant.
bonjour,
Comment faites vous pour utiliser le date_picker sur un champ date et enregistrer au format ’date’ ou ’datetime’ ?
le picker complete le champ en JJ/MM/AAAA et mysql veut du AAAA-MM-JJ
ya bien la solution
[(#SAISIEdate_jour_mois_annee, datet, obligatoire=oui,
label=<:date :>)]
mais si je veux un date_picker je ne comprends pas comment convertir automatiquement le format.
Est ce un réglage php ou une options dans saisies ?
Avec le plugin Vérifier, il faut utiliser la vérification « date » et activer la normalisation SQL.
Sans le plugin Vérifier, on peut faire la même chose à la mano dans la fonction verifier() de CVT.
Merci Beaucoup !
Va falloir que je me décide alors :|
Répondre à ce message
Bonjour,
je suis en train d’écrire un plugin qui crée un formulaire CVT.
Pour créer formulaire j’utilise le plugin saisies en initialisant le formulaire au sein d’un fonction _charger.
Ma fonction charger cree un tableau de valeur avec les valeurs par defaut une valeur [’mes_saisies’] contenant la liste des champs à la norme saisies.
Dans ma balise formulaire, le formulaire est généré par un appel #GENERER_SAISIES#ENVmes_saisies
Mon formulaire s’affiche correctement avec tout ses champs, mais j’ai dedans 2 champs avec un affichage conditionnel : afficher_si . Cette affichage conditionnel ne fonctionne pas !!
Pourtant le javascript gèrent cet affichage conditionnel semble être chargé dans la page.
Le formulaire en question est visible ici :http://chaps-a-chap.com/spip.php?article101. Je souhaite que si on choisit conducteur, le champs nb_passager soit masqué et si on choisit passager, le champ places dispo soit masqué.
Quelqu’un aurait une petite aide pour moi ????
Peut-être que ce commit corrige, mmh ?
http://zone.spip.org/trac/spip-zone/changeset/83524
Répondre à ce message
Bonjour,
Mon environnement : SPIP 3.0.16 [21266] | Sarka-SPIP 3.2.36 [77717] |
Je n’arrive pas à personnaliser mon « /squelettes/css/perso.css » de façon à ce que les différents éléments de type checkbox se trouvent sur la même ligne malgré les différents posts que j’ai lus :
Code de mon html :
code de mon php :
Le formulaire CVT fonctionne parfaitement mais j’obtiens une checkbox par ligne.
Je voudrais que les checkbox de la même balise Saisie s’affichent sur la même ligne.
C’était le cas sous Spip 2, je loupe sans doute quelque chose d’évident mais je ne vois pas quoi, une piste ?
Merci
Philippe
Ben ça c’est ton thème CSS qui fait ça (ou celui que tu utilises).
Il faut mettre les labels internes des saisies en « display:inline », en ciblant par exemple « .saisie_checkbox .choix label », un truc dans ce genre, je ne me rappelle plus du HTML par cœur.
Cela n’a pas suffit, je me suis rendu compte qu’il fallait que mon fichier de personnalisation des css se nomme « perso.css.html » et non pas« perso.css ».
Merci pour l’info
Répondre à ce message
Question plus simple cette fois (saisies ne me quitte plus), comment enchainer 2 trads quand on est en yaml ?
ex :
Merci encore
Je ne crois pas que ce soit possible. En PHP si, avec
_T()._T()Hello,
J’ai pas mal sué sur le YAML et les traductions.
En faite, tu dois dire à SPIP de foutre la paix a ton fichier YAML. Dans ta fonction fonction charger, quand tu passes le paramètre au formulaire :
Tu mes un « _ » devant le nom de ta variable, cela indique à SPIP de ne pas faire de traitement de sécurité.
Ensuite, tu balances tout dans #GENERER_SAISIES :
#GENERER_SAISIES{#ENV{_form_saisies}}Et normalement tes traductions fonctionnent.
Je baliserai aussi les traductions avec des ’ comme cela :
explication: '<:video:id_groupe_tags_explication:><:video:id_groupe_explication_archives:>'Voilà pour le YAML et les traductions !
Je ne saisis toujours pas l’intérêt de mettre ça dans un YAML, alors que Saisies contient une API spéciale pour les CVT, qui est de fournir une fonction
formulaires_truc_saisies_dist($args)qui renvoie un tableau de saisies.En plus ça fait faire des traitements supplémentaires (décoder du YAML).
Pour un formulaire de config classique (donc pas besoin de verifier() ni de traiter()), il y a juste à déclarer les champs et avoir un squelette vide.
Il suffit juste de :
formulaires_configurer_foundation_saisies_dist()Et c’est tout. Saisies s’occupe du reste.
Avoir un fichier très simple pour modifier un formulaire. Pour les formulaires très complexes, cela aide fortement. C’est un peu le but du YAML de renvoyer des tableaux.
Documenté nulle part sur cette page... Je ne savais même pas qu’une telle fonction était possible. Tu ne peux pas reprocher aux gens de ne pas utiliser des choses non documentées...
Dans le cas des formulaires d’admin, ce n’est pas trop grave. Dans le cas des formulaires publics, ce sera dans le cache de SPIP non ?
Ça à l’aire chouette, je fais le même reproche, pas de documentation...
Bref, tout cela à l’aire parfaitement faite et pensée, malheureusement, la documentation pour que tout le monde puisse s’en servir est absente, c’est dommage.
Dans la documentation ci-dessus il y a un bloc « Consultez également » avec un lien avec cet autre article de doc (sur le wiki pour l’instant car c’est un fourre-tout bordel) :
http://contrib.spip.net/Doc-Saisies-complementaire
Et notamment ce chapitre :
http://contrib.spip.net/Doc-Saisies-complementaire#autocvt
Bien sûr, avec moins de flemme, cela aurait vocation à être intégré dans cet article principal, ça c’est sûr. En tout cas au moins pour ce point-là.
Hello,
Merci, le pire c’est que je connais cette page, mais je n’y fais que des recherches précises.
Cela dit, cela ne résout pas vraiment le problème : on doit toujours écrire des tableaux PHP dans la syntaxe est vite rébarbative. Le YAML a justement vocation à être très lisible et facile à modifier/maintenir.
C’est juste une question de préférence cela dit...
Répondre à ce message
Bonjour,
Sur un SPIP 2.1.25 [21141] le plugin saisies Version : 1.38.6 [80094] donne une page blanche quand je veux l’activer. La version 1.14.0 [50422] elle s’installe bien.
dd
Chez-moi-ça-marche. ©
Pour tester, il faut bien entendu n’activer QUE ce plugin-là et rien d’autres. C’est ce que tu as fait ?
Répondre à ce message
Salut Marcimat,
Merci encore pour ce travail fantastique.
Dans tes exemples tu ne parles pas de lire_fichier, or j’ai réussis à faire marcher yaml_decode, uniquement grâce à cette fonction, sinon ca me renvoie l’url de mon yaml.
J’ai manqué un truc ?
Sinon merci encore
++
Charles
Mmmh es-tu sûr que tu postes dans le bon forum ? Parce que dans cet article il n’est a aucun moment question de yaml_decode(). :)
Salut Rastapopoulos
Je me suis en effet trompé de personne, j’ai lu trop vite et j’ai du croire que c’était Marcimat qui avait fait ce tuto (doc complémentaire).
Désolé.
J’ai relevé sur google un échange de mail que tu as eu avec plusieurs contributeurs et developpeurs dont mathieu, cedric, joseph. (le lien chez moi ne s’ouvre plus...???)
Tu proposes à un moment donné de generer les saisies en fnct de leur contexte aussi aurais tu des pistes qui vont en ce sens, je suis justement dans ce cas de figure ?
J’ai 5 yaml nommés Xstatut.yaml dans un dossier yaml d’un plugin, contenant - des champs communs mais à labels différents - et d’autres champs dédiés au statut.
Dans un pipeline declarer_champs_extra, je veille à ce que tous les champs de ces 5 fichiers soient présent en base, le cas échéant les créer grâce à l’option sql de la saisie manquante.
Mon CVT quant à lui est composé de 5 #SAISIEs de base et d’1 #GENERER_SAISIES#ENVmes_saisies.
Mes champs s’affichent bien et s’enregistrent.
MAIS : comme mes champs sont TOUS déclarer j’ai dans mon cvt tous les champs rédiger dans tous mes yaml.
Et c’est à partir de là que je m’arrache les cheveux. Je viens de comprendre déjà les pipelines, quelque chose doit m’échapper (intellectuellement) ...
Comment obtenir le #ENVmes_saisies contenant l’array du yaml correspondant au contexte de mon cvt et en l’occurence du statut d’un auteur ?
J’ai bien essayer de récupérer le statut en get, c’est sale, ca affiche du coup les bons champs des bons yaml relatifs aux statuts, mais le form n’enregistre plus.
Ma question est donc la suivante :
Comment passer à la fonction ci dessus - qui réside dans mon pipeline de déclaration des champs extra - le statut de l’auteur afin de disposer de 5 yaml parametrant un seul et même CVT ?
Bidouiller un second passage de variable à GENERER_SAISIES ? // Bof bof
N’utiliser qu’un yaml mais gérer des autorisations dans les descriptions des saisies // Je perd l’interet d’un yaml par statut or c’est l’enjeu.
Qu’en pensez vous chère communauté ?
Bien à vous
Charles
Vu avec marcimat sur irc, en fait le cache de la déclaration des champs extra ne permet pas trop ce genre de chose.
Je pense à la solution suivante :
Garder mes 5 yamls puis en rajouter un qui serait merger à tous
Et dans ma fonction foreach tester le fichier yaml et rajouter au tableau de saisies l’option de restriction qui va bien, le résultat est une seule declaration, bien cachée
Je ferais un retour d’experience ici même
En tout cas merci à Marcimat et Rastapopoulos
Bon, conclusion.
Ma solution révele que ce post n’est en effet pas au bon endroit
L’un étant lié à l’autre cependant j’ai solutionné mon problème en surchargeant autoriser_modifier_extra et en ajoutant un parametre d’option à mes champs dans mon yaml
Je dépose le code si quelqu’un pourrait être interessé :
++
Correction :
if ( ($autor !== $qui[’statut’] ) AND !( $autor == $statut[’statut’] ) )
Pas réussit à faire plus propre
Répondre à ce message
Aujourd’hui : Formidable -> Saisie et Mediaspip ?
J’avance comme je peux... Faute d’infos et de piste.
Une autre découverte (peut-être ?) serait la piste du plugin Saisie.
C’est dans le fichier plugins/auto/saisies/v1.34.1/javascript/saisies.js
a la ligne 8 il dit :
$ is not a function (erreur js)si je commente la ligne 2 & 3 tout se remet a marcher
Vous avez une piste pour me débloquer ?
Merci à tous.
Le 14 septembre 2013 10:25, Formidable et Mediaspip ?
Bonjour,
Je suis toujours dans l’embarras... Pas de réponse...
Je n’arrivais plus à faire fonctionner la lecture de médias avec Mediaspip. J’ai posé la question. La réponse est une erreur javascript
"Uncaught TypeError: Property '$' of object [object Object] is not a function saisies.js:8"J’ai désactivé Formidable et Mediaspip fonctionne à nouveau normalement.
J’imagine donc que cette erreur vient de Formidable, non ?
comment régler mon problème pour faire fonctionner Mediaspip ET Formidable ?
Un grand merci à vous tous...
Robert
Je ne vois pas comment « $ » pourrait ne pas être une fonction à la ligne 8 (= jquery pas chargé) MAIS être pourtant interprété correctement à la ligne 1...
T’as un problème avec jQuery en général non ? Ya un truc qui se charge pas bien on dirait.
OUi, sans doute... Mais j’aimerais vraiment trouvé ce qui coince...
Page exemple : http://malle-arts.org/spip.php?article10
Merci, merci...
Robert
Rappel pour tester si un plugin précis est à l’origine d’un bug, et déjà marqué dans le lien « Les choses à faire avant de poser une question » que l’on trouve au dessus du champ texte de ce forum :
Donc as-tu déjà désactivé TOUS les plugins non obligatoires pour tester Formidable/Saisies ?
J’ai eu le même genre de message (
function saisies_fieldset_pliable(){ // On cherche les groupes de champs pliables $('li.fieldset.pliable') ... TypeError: $ is not a functiondans la console firebug.En passant de la version 1.34.1 à la version 1.38.3 : plus de problème !
Répondre à ce message
Bonjour,
Dans un contexte de Spip mutualisé (plusieurs sites avec une seule installation de spip, en 3.0.11) et avec des dossiers plugins par site, donc dans un dossier sites/www.domaine.tld/plugins/auto correctement déclaré (voir http://www.spip.net/fr_article4865.html et http://www.spip.net/fr_article5296.html pour les variables _DIR_PLUGINS_SUPPL et _DIR_PLUGINS_AUTO) qui nous permet d’installer des plugins dans le bon dossier de site par les dépôts, avec le code dans mes_options :
Seul le plugin Saisies nous donne un souci avec l’erreur suivante :
On voit « auto » collé à _ROOT_PLUGINS_SUPPL comme si à cet endroit, _ROOT_PLUGINS_SUPPL n’était pas connu ni remplacé par sa valeur ....
Le traitement de _ROOT_PLUGINS_SUPPL se fait apparemment dans inc/utils.php (ligne 1546) selon ce changelog :
Le plugin s’installe mais ne fonctionne pas ...
Le traitement dans utils.php, c’est ça (j’ai tenté de le déplacer dans mes_options.php mais cela donne une autre erreur sur saisies.css)
Une idée géniale ?
Merci d’avance !
Pierre
On peut d’ailleurs aussi se poser la question du « ecrire/ » devant « _ROOT_PLUGINS_SUPPL » alors que cette constante (par ex placée dans mes_options) produit un chemin absolu depuis la racine de l’hébergement, donc avoir « ecrire » devant semble sans issue ...
Ceci dans l’erreur qui apparait déjà mentionnée dans mon premier post :
Toute aide bienvenue et appréciée ... je sais on est en août !
P.
A priori, il n’y a aucun rapport avec le plugin saisies.
Cela dit, il te faudrait par exemple ajouter un test là où _ROOT_PLUGINS_SUPPL est utilisé dans le code de SPIP et provoque une erreur.
Tu pourrais tester un
Tu pourras alors fournir la pile d’exécution des fonctions pour arriver à cette erreur. Ce qui peut aider à trouver dans quel contexte ça se produit.
Bjr,
Oui je l’ai mentionné au niveau du plugin mutualisation, je pense que Saisies le révèle mais n’est pas la cause.
Je vais tenter ce qui est suggéré et revenir ici.
P.
Bonjour
Je pense que saisies et commun à tout les sites non ? Le mettre dans le répertoire centrale serais pas une facilité ?
Oui d’accord mais on revient au problème que depuis la version 3, la mise à jour d’un plugin le dévalide dans tous les sites d’une ferme à spip, c’est pour ça que je suis en train d’envisager de faire un dossier plugin par site de la ferme.
La ferme me permettra de mettre à jour le core, ensuite je peux m’occuper site par site de la mise à jour des plugins via l’interface ... tâche que je dois faire de toutes façons (je veux dire aller sur chaque site vérifier que tout marche).
Voir http://contrib.spip.net/Ferme-a-SPIP#forum465002 ou vous intervenez, je viens justement de rajouter un mot sur ce sujet, il n’est pas encore aparru.
Une suggestion ou mettre ça car là je n’ai pas trop de résultat ... Ou alors je ne sais pas ou regarder.
PS : je crois qu’il y a une parenthèse fermante de trop au premier defined.
Une autre chose que je constate, c’est que dans utils.php (ligne 1546 pour 3.0.11) qui a été modifié assez récemment : http://core.spip.org/projects/spip/repository/revisions/20029 on a
Et à cet endroit, _DIR_PLUGINS_SUPPL est vide donc ce if n’est jamais éxécuté. Pourtant _DIR_PLUGINS_SUPPL marche puisque mon spip voit le dossier plugins/auto qui est dans le dossier spécifique de ce site dans la ferme. (j’ai pris soin de renommer le dossier plugins central qui ne peut donc être utilisé).
J’ai l’impression qu’une réponse sur 2 est zappée et à chaque fois j’ai un message qui me dit que je suis soupçonné de spam, donc je sais plus trop ou j’en suis sur ce fil ... J’ai fait 2 réponses qui ne sont pas apparues (à Pierre et Mathieu), ... j’attends pour voir si c’est un souci de modération mais en général les messages apparaissent rapidement ...
C’est quand une réponse contient beaucoup de liens. Tes messages étaient en « proposés ». Je les ai validés.
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 :
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.
Suivre les commentaires :
|
