Champs Extras 3

Ce plugin permet de créer et/ou de gérer des champs supplémentaires dans les objets éditoriaux de SPIP. Il permet donc de prendre en compte et d’afficher de nouveaux éléments dans n’importe quel objet éditorial de SPIP.

Screencast

Vous n’aimez pas lire ? Écoutez pendant 20mn !

Cette capture présente Champs Extras 3 avec son interface graphique [1]. Elle est présente sur medias.spip.net où vous pourrez voir la vidéo en plus grand format.

Introduction

Ce plugin est plus qu’une adaptation pour SPIP 3 du plugin «Champs Extras 2». Les nouveaux champs sont toujours stockés dans de nouvelles colonnes SQL sur les objets éditoriaux correspondants, mais l’interface et le fonctionnement technique sous-jacent a été en grande partie modifié pour deux raisons essentielles :

  • SPIP 3 offrant une méthodologie pour déclarer des objets éditoriaux, ce plugin s’appuie donc dessus pour connaître la liste des objets sur lesquels il peut intervenir et créer de nouveaux champs. Ainsi, il est possible à l’aide de EXTRA3 d’ajouter des champs à tous les objets éditoriaux (et éditables) déclarés par SPIP3 ou par des plugins. (Avec EXTRA2, il était nécessaire que le plugin à l’origine de l’objet éditorial le déclare comme extensible).
  • Le plugin «Saisies» dispose d’un générateur de formulaire, à l’origine créée pour le plugin «Formidable, le générateur de formulaires» et d’un nombre de saisies possibles grandement supérieur à ce que proposait la version 2. Mutualiser ce code entre plusieurs plugins permet une meilleure maintenance, une interface plus complète et une aussi grande extensibilité.

L’ensemble est donc à la fois plus fonctionnel, plus extensible, le tout en utilisant bien moins de code.

Séparation de l’API et de l’interface graphique

Ce plugin est séparé en deux éléments indépendants :

  • le premier, «Champs Extras» (lire «Champs Extras 3 - API et créations») donne accès aux fonctions de création, de gestion et d’affichage des champs, mais pour d’autres plugins. Il nécessite le plugin «Saisies». Un exemple (Titre Court sur les rubriques) dans le dossier extensions montre comment créer un plugin offrant des champs prédéfinis.
  • le second, «Champs Extras (Interface)» profite des points d’entrées et des fonctions du plugin «API» pour proposer une interface graphique de gestion et de création de ces champs supplémentaires. Ce plugin nécessite quand à lui évidemment «Champs Extras (API)» et «Saisies», mais également «Le plugin YAML» et «Vérifier».

Présentation de l’interface

Lorsque le plugin d’interface est activé, le menu de configuration permet d’aller sur la page de configuration des Champs Extras (?exec=champs_extras).

Cette page présente :

  • la liste des objets sur lesquels on peut insérer des champs extras, indiquant pour chaque objet le nombre de champs extras présents,
  • puis, si c’est le cas, un cadre se trouve dessous indiquant pour certains objets que certaines colonnes SQL ne sont gérées ni par SPIP ni par un plugin, et que Champs Extra peut éventuellement les gérer.
Liste des objets éditoriaux exploitables
Liste des objets éditoriaux exploitables

On le remarque sur l’image, ici seul l’objet Articles a 1 Champs Extra. De plus, dans le second cadre, on voit que le champ «openid» peut être géré. Ce champ provient du plugin «OpenId» qui avait du être installé mais n’est actuellement pas actif sur le site. Comme il n’avait pas été désinstallé (mais seulement désactivé), le champ est resté dans la table SQL des auteurs.

Créer un nouveau champ via l’interface

Seuls les webmestres du site ont accès à ce panneau de configuration.

Pour ajouter un élément dans un des objets, il faut cliquer sur le nom de l’objet souhaité.
Nous allons créer un champ dans la table des articles, nous cliquons donc sur leur nom.

Cela nous amène sur une autre page (du même fonctionnement donc que le plugin Formidable), qui présente :

  • les Champs Extras présents sur l’objet (que l’on peut déplacer, modifier, dupliquer ou supprimer),
  • puis la liste des types de champs que l’on peut ajouter.
Présentation du formulaire d'édition d'un objet
Présentation du formulaire d’édition d’un objet

Il suffit de cliquer un des types de champs pour ajouter cet élément dans la liste des champs présents. Cet élément se placera automatiquement en fin de liste. Nous ajoutons ici des cases à cocher.

On peut le voir sur l’image suivante, un message indique alors que le formulaire est modifié par rapport à son état normal. On a trois possibilités offertes :

  • Continuer nos modifications, autant qu’on en souhaite,
  • Annuler toutes nos modifications en «Réinitialisant le formulaire»
  • Valider nos modifications en «Enregistrant le formulaire» en bas de page.
Des champs de type Cases ajoutés aux articles
Des champs de type Cases ajoutés aux articles

Nous allons déplacer les cases ajoutées en premier, pour cela, on survole les «cases à cocher», clique en gardant enfoncé notre bouton l’icône de déplacement (la première, des flèches bleues), et on monte la souris vers le haut, au dessus du premier champ. Un cadre jaune apparaît à l’endroit ou se placera le champ déplacé. On peut alors relâcher le bouton de la souris. Si la manœuvre vous paraît périlleuse, n’ayez crainte : cette façon de faire n’est qu’un raccourcis. On peut également définir l’emplacement du champs extra en le modifiant.

C’est d’ailleurs modifier le Champ Extras des cases que nous allons faire maintenant. Pour cela, on clique la seconde icône. Un formulaire détaillé apparaît alors :

Édition de cases à cocher
Édition de cases à cocher

On peut observer que les options sont nombreuses et divisées en onglets pour plus de clarté. Décrivons sommairement ce que sont ces onglets :

  • Description : concerne essentiellement les textes qui seront affichés ainsi que le nom technique du champ (le nom de la colonne SQL)
  • Utilisation : concerne des options sur le type de code HTML généré
  • Affichage : permet de compléter les descriptions du champ, par exemple par un message d’avertissement
  • Validation : indique le type de vérification à effectuer sur le contenu saisi
  • Restriction : permet de limiter l’affichage des champs à certaines personnes ou parties du site.
  • Technique : représente la liste des options liées à SPIP, à la base de données. Il permet également de modifier de type de saisie (pour passer de cases à radio par exemple).

À noter que les éléments affichés dans chaque onglet peuvent différer d’un type de saisie à une autre. Un champ «Ligne de texte» n’affiche pas les mêmes possibilités de configuration qu’un champ «Cases à cocher».

On comprend vite ainsi que lorsqu’on crée un nouveau champs extra, la première chose à faire est de changer les informations présentes dans l’onglet «Description» et en particulier son nom technique, le «nom du champ». Effectivement, cela nous évitera d’appeler le champ #CHECKBOX_1 dans un squelette, qui ne reflète pas une information sémantique, mais technique. On peut par exemple modifier le champ en le nommant «hobbies» (ce qui permettra d’utiliser #HOBBIES), et modifier son libellé et valeurs. Cela donnerait ensuite, après validation du formulaire de configuration de la case à cocher, la prévisualisation suivante :

Cases à cocher modifiées
Cases à cocher modifiées

Pour valider nos changements, il faut alors enregistrer le formulaire de champs extras. Ceci fait, on peut ensuite se rendre sur un article, nous être satisfait de voir nos deux champs présents, à la fois sur le formulaire d’édition et sur la vue du texte. Voici dans le formulaire des articles ce que cela donne :

Deux champs en plus sur les articles
Deux champs en plus sur les articles

Utiliser les champs dans les squelettes

Valeur d’un champ

Les champs extras sont comme les autres champs d’une table SQL, interrogeables en utilisant #NOM_DU_CHAMP.

Pour afficher donc le résultat d’un champ il suffit d’utiliser son nom. Le champ est d’autre part éditable avec la classe CSS #EDIT{nom_du_champ} si vous avez le plugin Crayons :

<p class='#EDIT{documentation}'>#DOCUMENTATION</p>

Valeur d’un champ multiple (cases à cocher, boutons radios,...))

Pour afficher la liste des valeurs de cases à cocher saisies par l’utilisateur, vous pouvez utiliser la balise #LISTER_VALEURS{nom_du_champ} :

#LISTER_VALEURS{hobbies} : Musique, Danse, ...
#LISTER_VALEURS{hobbies, ' / '} : Musique / Danse / ...
#LISTER_VALEURS**{hobbies} : tableau des résultat à exploiter par exemple avec une boucle POUR

Les valeurs affichées sont les valeurs lisibles par les humains, et non pas les valeurs informatiques brutes.

Pour afficher la liste des possibilités qu’il y avait de saisies, vous pouvez utiliser de la même manière #LISTER_CHOIX{nom_du_champ}

#LISTER_CHOIX{hobbies} : Musique, Danse, ...
#LISTER_CHOIX{hobbies, ' / '} : Musique / Danse / ...
#LISTER_CHOIX**{hobbies} : tableau des résultat à exploiter par exemple avec une boucle POUR

Informations d’une saisies

Enfin, vous pouvez récupérer n’importe quelle information sur la saisie en utilisant la balise #CHAMP_EXTRA{nom_du_champ}. Elle récupère tout le tableau d’information connue sur le champ extra. Cependant, elle est surtout utile pour afficher un des éléments #CHAMP_EXTRA{nom_du_champ, element} tel que le label :

#CHAMP_EXTRA{documentation,label}
#CHAMP_EXTRA{hobbies,label}
#CHAMP_EXTRA{hobbies,explication}

Créer de nouveaux types de saisies

Si les saisies présentes ne sont pas suffisantes pour votre utilisation, vous pouvez en créer de nouvelles dans votre répertoire squelettes ou votre plugin en créant :

  • saisies/ma_saisie.html,
  • saisies/ma_saisie.yaml et
  • saisies-vues/ma_saisie.html

Reportez vous à la documentation du plugin «Saisies» ou aux fichiers de saisies du même plugin pour vous en inspirer.

Nesting Level et XDebug

Si vous rencontrez cette erreur : Fatal error : Maximum function nesting level of ’100’ reached c’est que xdebug est actif. Il faut augmenter sa profondeur d’exécution. Par exemple en mettant dans votre config/mes_options.php l’instruction suivante (pensez à ouvrir <?php sur la première ligne et caractère du fichier si ce n’est pas fait, et pas la peine de le fermer)

<?php
ini_set('xdebug.max_nesting_level', 200);

Footnotes

[1Cette interface a évolué depuis la prise de cette vidéo ; cependant le fonctionnement est relativement identique

updated on 2 May 2020

Discussion

244 discussions

  • 3

    Bonjour,

    Dès que j’édite ou modifier ou importe un champ extra j’ai le message d’erreur suivant : “Site en travaux : Attention : un problème technique (serveur SQL) empêche l’accès à cette partie du site. Merci de votre compréhension.”
    L’import se passe bien. Au moment d’éditer une rubrique qui contient ce champ extra, ca plante.

    Je dois sois relancer SQL soit vider tmp.

    Dans les logs de SPIP : un fichier se crée mysql.74fa9889.out avec rien dedans

    Au niveau des logs SQL j’ai le message d’erreur suivant :

    2020-06-11T21:32:21.158304Z 0 [Warning] File Descriptor 1272 exceeded FD_SETSIZE=1024

    J’ai un fichier meta_cache.php qui se crée dans tmp/log où je vois bien la création des mes champs extra.

    Une fois que j’ai vidé mes caches et/ou redémarrer SQL tout rentre dans la normal.

    Puis-je faire un réglage spécifique pour éviter cette erreur. Je voudrais m’assurer que je ne vais pas faire planter la prod quand je vais importer mes champs extra.

    Avec mes remerciement

    • J’ai trouvé ca https://bugs.mysql.com/bug.php?id=79125 mais je sais pas trop quoi en faire.

    • A priori mon ami Google dit que ma version SQL est trop ancienne
      5.7.25 et que je dois pouvoir jouer sur ces paramètres

      -  table_open_cache=100
      -  table_definition_cache=100 to prevent MySQL from using all the file descriptors on caching tables and therefore leave some for connections.

      Je vais tester et je vous dis, mais si vous avez une autre solution je prend.

      Merci

    • Avec My SQL 5.7.26 ca passe tout bien. Plus d’erreur.

    Reply to this message

  • 11

    Bonjour à tous,

    Je n’ai pas trouvé comment faire avec les CHECKBOX data clé / valeur
    Je cherches l’équivalent des INPUT Pour les CHECKBOX avec plusieurs choix
    TYPE OUI/NON
    (#NOM_DU_CHAMP
    TYPE INPUT
    [(#CHAMP|==vert|oui) ce que l’on veut afficher ]

    J’ai tenté
    [(#CHOIX|==choix1|oui) ce que l’on veut afficher ]
    Mais ca ne marche pas

    Merci beaucoup

    • J’ai beau relire, je ne comprend ni ce que tu veux, ni ce que tu as deja fait.... peux tu reformuler?

    • Merci beaucoup Maïeul
      En fait j’ai besoin de mettre une classe CSS sur chaque items

      [<span>(#LISTER_CHOIX{prerequis_checkbox_1})</span>]

      Je voudrais pouvoir isoler chaque élément un 1 à 1 d’une checkbox avec plusieurs choix possible
      Comme je fais sur mes input type text

      [(#CHAMP|=={vert}|oui) ce que l'on veut afficher ]
    • Tu peux utiliser une boucle (POUR) sur #LISTER_CHOIX** (avec les deux **).

      Pour un exemple de boucle (POUR) https://contrib.spip.net/SPIP-Bonux#Une-boucle (la doc est concerne Bonux mais en fait c’est désormais livré avec SPIP).

      Comme cela tu itère sur chaque valeur, et tu peux faire tes tests dedans.

    • Merci beaucoup Maieul
      #LISTER_CHOIX** ne me retourne rien du tout
      #LISTER_CHOIX* me retourne la bonne valeur, mais pas la bonne clé. Il incrémente la clé à partir de 0 mais pas celle que j’ai rentrée

      [(#REM)Récupérer les valeurs de la checkbox - tableau clé valeur - dégagez la virgule et obtenir une class]
      
      <B_liste1>
      <div class="choice-link">
      <div class="tags">
      <BOUCLE_liste1(POUR){tableau #LISTER_CHOIX{prerequis_checkbox_1}|explode{','}}>
      [<span class="tagcle [tag_(#CLE)]">(#VALEUR)</span>]
      </BOUCLE_liste1>
       </div><!-- choice-link -->   
      </div><!-- tags -->
      </B_liste1>
      <span class="tag_0">lorem</span>
      <span class="tag_1">ipsum</span>
      <span class="tag_2"> sic</span>

      Merci encore pour ton aide précieuse. Comment puis-je récupérer la bonne clé tel que saisie dans mon champ extra ?

    • J’ai l’impression que ce que tu cherches est plus de l’ordre de `#LISTER_VALEURS` déjà (les valeurs que tu as cochées). `#LISTER_CHOIX` sont les valeurs que tu peux cocher.

      Ensuite, si tu cherches la “clé” de ces valeurs justement… elle se trouve en clé du tableau retourné par `#LISTER_VALEUR**champ` lorsque quelque chose avait été coché.

      Du coup, tu devrais pouvoir utiliser une instruction tel que :

      [(#LISTER_VALEUR**{champ}|array_keys|array_intersect{#LISTE{vert,bleu}}|oui)
      J’ai coché vert ou bleu
      ]

      Comme c’est assez moche, tu aurais tout intérêt à faire un filtre (dans mes_fonctions.php par exemple)

      [(#LISTER_VALEUR**{champ}|checkbox_contient_cle{bleu}|oui) ... ]
      [(#LISTER_VALEUR**{champ}|checkbox_contient_cle{#LISTE{bleu,vert}}|oui) ... ]
      function checkbox_contient_cle($champ_extras_valeurs, $cles_a_verifier) {
          $cles_cochees = array_keys($champ_extras_valeurs);
          $cles = is_array($cles_a_verifier) ? $cles_a_verifier : array($cles_a_verifier);
          return (bool) array_intersect($cles_cochees, $cles);
      }

      Enfin ce genre de chose par exemple...

    • Merci beaucoup Matthieu Marcillaud
      Je vais regarder tout ca. Et merci Maïeul.

    • @Matthieu Marcillaud, @Maieul

      Je comprend pas pourquoi #LISTER_VALEURS me retourne quelque chose mais #LISTER_VALEURS** me retourne rien du tout

      Comment puis-je faire pour alimenter mon tableau de clé / valeur

      #LISTER_VALEURS{prerequis_checkbox_1} 
      ->tag1 ,  tag2, tag 3
      
      #LISTER_VALEURS**{prerequis_checkbox_1} 
      ->Array      

      Avec mes remerciements

    • «Array» c’est quelque chose…

      <pre>[(#LISTER_VALEURS**{prerequis_checkbox_1}|print_r{1})]</pre>
       
      <BOUCLE_prerequis(DATA){source tableau, #LISTER_VALEURS**{prerequis_checkbox_1}}>
      #CLE : #VALEUR</br>
      </BOUCLE_prerequis>

      Cela dit, contrairement à ce que dit Maieul, #LISTER_VALEURS** retourne aussi le label applati ! (Ah c’est dans un autre thread !)

    • Super j’ai ma liste avec les class qui vont bien.
      Encore merci pour votre aide précieuse

          <B_prerequis>
          <ul>
              <BOUCLE_prerequis(DATA){source tableau, #LISTER_VALEURS**{prerequis_checkbox_1}}>
              [<li class="[(#CLE)]"><a href="#">(#VALEUR)</a></li> ]
              </BOUCLE_prerequis>       
          </ul>
          </B_prerequis>
          <ul>
          <li class="rouge_oc"><a href="#">lorem1</a></li> 
          <li class="vertmss"><a href="#">lorem2</a></li> 
          <li class="orange_dmp"><a href="#">lorem3</a></li> 
          <ul>

      J’ai encore une petite question
      Maintenant si je veux faire un filtre de test sur la clé (ou sur la valeur peut m’importe) d’un seul élément, je fais comment ?

      J’ai besoin de refaire une boucle data ou ca peut etre hors contexte ?

      [(#LISTER_VALEURS**{prerequis_checkbox_1}|checkbox_contient_cle{rouge_oc}|oui) fais ceci ]
      [(#LISTER_VALEURS**{prerequis_checkbox_1}|checkbox_contient_cle{vertmss}|oui) fais cela ]

      Merci encore

    • j’ai l’impression que ca fonctionne hors boucle
      Terrible ! Merci pour la syntaxe Matthieu

      [(#LISTER_VALEURS**{prerequis_checkbox_1}|array_keys|array_intersect{#LISTE{rouge_oc,vertmss}}|oui)
       ce que je veux
       ]
    • Bonjour,

      ca fait plusieurs fois que lorsque j’édite mes champs extra depuis l’interface, ma base SQL plante et je dois la relancer en local sur serveur LAMP.
      Y a t-il un réglage spécifique à faire au niveau de la conf SQL ?
      Je n’ai rien vu de particulier dans les logs. Je voudrais éviter que cela m’arrive en production ?
      Est-ce un problème connu ?
      Sinon grâce à Matthieu et Maieul je suis parvenu à faire ce que je voulais.

      Merci encore à vous deux et bonne journée.

    Reply to this message

  • 21

    Bonjour à tous,
    J’ai une question concernant la balise #LISTER_VALEURS

    J’utilise le plugin depuis plusieurs années et je constate une évolution dans son utilisation, je m’explique.
    Dans le cas d’un select utilisant des optgroup, la balise #LISTER_VALEURS renvoyée uniquement la valeur sélectionnée.
    Depuis quelques semaines, le résultat renvoyée par la balise contient également le label de l’optgroup.

    Il y a t’il une nouvelle syntaxe pour récupérer que la valeur ?

    En vous remerciant.
    JuL

    • Hum. Il va nous falloir du contexte, un exemple, car je ne me rappelle plus trop, ni ne suis pas certain de savoir de quoi tu parles :)

      Pourrais tu indiquer si tu déclares :
      -  via champs_extras_core (et si oui le code de ta saisie)
      -  via champs extras_interface (et si oui le type de saisie et sa config data)

      Et indiquer le résultat avant / après ? Tu parles de #LISTER_VALEURS{x} ou #LISTER_VALEURS**{x} ?

      On est d’accord que tu parles d’une utilisation dans un squelette à toi, et pas de l’affichage dans l’espace privé «normal» via le squelettes/saisies-vue utilisé ?

    • Moi je sais à quoi ca fait allusion https://git.spip.net/spip-contrib-extensions/saisies/pulls/1

      il faut effectivement prévoir une syntax derogationnel. La question est : dans quel sens ?

    • a moins qu’il faille mettre cela en option de la saisie en question ? sans doute plus simple, et aussi plus facilement automatisable je pense....

    • Après discussion avec Rastapopoulos, le co-auteur de saisies, il nous semble que les cas où il ne faut PAS afficher l’optgroup sont rares, et donc nous avons opté pour ne pas mettre d’option.

      Cela étant, tu peux ne pas afficher l’optgroup en surchargeant :
      -  soit le fichier saisies-vues/selection.html en passant à saisies_aplatir_tableau le paramètre {#EVAL{false} : |saisies_aplatir_tableau{#EVAL{false}} ;
      -  soit la chaîne de langue saisies:saisies_aplatir_tableau_montrer_groupe pour ne pas mettre le groupe.

      La seconde option est moins propre sémantiquement, mais elle offre l’avantage de permettre de profiter des éventuelles futures corrections sur la vue de cette saisie (qui devraient être rares cependant).

      Pour les détails du changement

      https://git.spip.net/spip-contrib-extensions/saisies/commit/a30582dcba0adf50ed6d06666db0ac6a0c8e42db

    • Merci Maïeul d’avoir déchiffré mon message ;)

      Dans mon utilisation, il est rare que j’affiche l’optgroup au niveau de la valeur car je l’utilise souvent comme groupe de filtre de recherche, et cela, ou les différentes valeurs deviennent des filtres. Je vous laisse imaginer donc un menu de filtre ou chaque entrée contient le optgroup...
      De plus une option (syntaxe différente) rendant au moins le rendu rétrocompatible serait appréciée.
      Entre temps je vais surcharger le fichier comme suggéré, mais je serais malgré tout heureux de profiter des mises à jour de ce fichier, donc si une nouvelle syntaxe pouvait faire son apparition, ce serait super :)
      Merci à vous.

    • la syntaxe différente ne nous semble pas le plus simple ni le plus pertinent. Mieux vaudrait une opton au niveau de la saisie.

      Cela étant, vu ce que tu décrit, tu ne devrais pas utiliser la VALEUR HUMAINE (= le label) pour tes filtres mais bien la clé technique (qui elle n’a en aucun cas le optgroup). Et pour ce faire il faut utiliser la syntaxe avec **. C’est précisement l’interet d’avoir une clé, c’est de ne pas dépendre de l’affichage.

    • Finalement je surcharge la chaine de langue, c’est effectivement très simple et efficace comme solution ;)
      Merci encore

    • En fait mes filtres utilisent bien la clé coté code mais dans l’interface j’utilise le label pour les utilisateurs c’est quand même plus sympa.

    • Je suis pas sur de comprend alors dans ce cas ce que tu souhaite :)

      C’est quoi ton interface qui aurait été cassée. Un bout de code aiderait à comprendre....

    • Imaginons un select “Hobby” configuré avec des groupes :

      *Gastronomie
      cuisine_fra|Cuisine française
      cuisine_asia|Cuisine asiatique
      *Sport
      yoga|Yoga
      velo|Velo
      rando|Randonnée

      Imaginons une longue liste de personne pratiquant une ou plusieurs de ces activités et que je souhaite donc pouvoir filtrer par activité. je vais généré un menu proposant ces valeurs en filtres qui va devrait ressemblé à ca :

      <--Permet de récupérer les optgroup-->
      <BOUCLE_choix(DATA){source tableau,#LISTER_CHOIX**{hobbies}}>
      <ul><span><b>#CLE</b></span>
      <BOUCLE_data(DATA){source tableau,#VALEUR}>
      <li ><a>#LISTER_VALEURS{hobbies}</a></li>
      </BOUCLE_data>
      </ul>
      </BOUCLE_choix>

      et rendre


      et non pas

    • Je viens enfin de regarder le code de LISTER_CHOIX et en fait je ne vois pas comment tu peux obtenir ça, vu que quand tu mets ** et bien ça n’aplatit PAS le tableau, et donc t’as bien le tableau d’origine, avec à un niveau les groupes, et à l’autre les entrées finales seules. Et donc ça si c’est toi-même qui construit tes boucles tout seul comme tu le montres plus haut, tu peux donc bien avoir le label humain des entrées finales sans problème.

    • J’ai du mal à comprendre ton code : tu utilises à la fois

      #LISTER_CHOIX**{hobbies} et #LISTER_VALEURS{hobbies} dans la boucle ?

      Ce que te dis Maieul, c’est que le paramètre qui te sert à filtrer, par exemple ce que tu mets dans “href” pour une url ou attribut data pour du javascript par exemple, et qui n’est pas présenté ici, c’est la clé technique à utiliser, pas la valeur.

      <BOUCLE_choix(DATA){source tableau,#LISTER_CHOIX**{hobbies}}>
      <ul><span><b>#CLE</b></span>
      <BOUCLE_data(DATA){source tableau,#VALEUR}>
      <li ><a href="[(#SELF|parametre_url{filtre,#CLE})]">#VALEUR</a></li>
      </BOUCLE_data>
      </ul>
      </BOUCLE_choix>

      Dans ce cas le #CLE dans la boucle data doit valoir, par exemple ’cuisine_fra’, et ce code ne dépend pas de la langue du visiteur (si tu déclares une chaine de langue par exemple comme valeur), tel que :

      *Gastronomie
      cuisine_fra|<:cuisine_francaise:>
      cuisine_asia|<:cuisine_asiatique:>

      Ça n’empêche pas qu’il y a eu un changement sur le traitement de la valeur dans les optgroup en utilisant #LISTER_VALEURS.

      Cela dit, comme signale Rasta, #LISTER_CHOIX retourne le même contenu qu’avant sans applatir, c’est à dire, dans ton exemple :

      Array
      (
          [Gastronomie] => Array
              (
                  [cuisine_fra] => Cuisine française
                  [cuisine_asia] => Cuisine asiatique
              )
       
          [Sport] => Array
              (
                  [yoga] => Yoga
                  [velo] => Velo
                  [rando] => Randonnée
              )
      )

      Ceci dit Maieul en passant, j’ai testé le code sur une saisie “checkbox” et l’affichage de la saisie vue est incorrect (rien se s’affiche) ; il faut peut être applatir aussi les saisies-vues radios et checkbox pour avoir le même comportement que les saisies selections du coup ?

    • Je vois que mon code porte a confusion, je l’ai simplifier et réécris à l’extreme pour l’exemple, car mon code s’étale sur plusieurs fichiers impossible à rendre ici sans beaucoup d’explication. J’ai omis volontairement la clé du href car ce n’est pas le sujet de ma requête.
      Ce qu’il faut retenir c’est uniquement qu’auparavant LISTER_VALEURShobbies me renvoyé la valeur et que dorénavant cela me renvoi l’optgroup et la valeur. Ce qui dans une liste de critère\filtre n’est pas désirable.
      Auparavant, il m’était donc possible d’afficher les valeurs sans passer par les fichiers de lang, ce qui dans cette exemple semble jouable, mais j’ai beaucoup beaucoup plus de valeurs possible que ca, ce serait fastidieux et source d’erreur.
      Quoiqu’il en soit je me range derrière vos décisions, la solution de surcharger la variable de lang me permet de retrouver le comportement précédent donc je suis content :)
      Merci à vous.

    • Non mais moi je ne vois toujours pas pourquoi même tu devrais surcharger la chaine de langue, si comme tu sembles l’expliquer, tu fais toi-même les boucles pour lister les filtres.

      #LISTER_VALEURS{hobbies} ce sont les valeurs réellement utilisées par UN contenu précis, donc je ne vois pas comment ça peut servir à t’afficher les “filtres possibles” puisque ce ne sont PAS les filtres possibles mais les valeurs réelles d’un seul contenu précis. Les “filtres possibles” c’est : #LISTER_CHOIX{hobbies} et lorsqu’il y a les ** ajoutées, ça sort bien le tableau complet, et au deuxième niveau ya bien les filtres seuls, sans le groupe ajouté (puisque le groupe c’est le premier niveau).

      J’ai l’impression qu’on comprend pas tout car on essaye de devenir ce que tu cherches à faire, sans l’avoir vraiment. Si ton but c’est “lister les filtres” possibles, c’est #LISTER_CHOIX avec ** en plus.

    • Dans mon code (ignorez ce que j’ai envoyé précédemment), j’utilise #LISTER_VALEURS pour effectivement retournée la valeur associés à objet (AUTEUR) et non pas tout la liste.
      J’utilise #LISTER_CHOIX pour récupérer mes optgroup. Je conçois que mon code est probablement pas optimal et je pourrais faire autrement.
      Je suis bien au fait du fonctionnement de l’utilisation des champs extras et de SAISIES, je les utilise depuis des années ce sont des outils incontournables.
      Il me semble que le comportement précédent est plus logique et intuitif, ce n’est qu’un avis personnel bien entendu. Obtenir une valeur quand on demande une valeur, c’est top. J’affiche optionnellement l’optogroup mais jamais au niveau de la valeur, généralement plus haut.
      Les optgroup (à mon sens) sont pratique pour segmenter les valeurs dans un select pour simplifier le choix de l’utilisateur quand la liste est longue (par exemple une liste de pays, les optgroups peuvent être les continents, un exemple parmis tant d’autres...).

    • Si je reprend ta boucle exemple, et comprenant ce que tu veux faire, il me semble que dans ton cas très précis, effectivement il ne faut pas afficher le optgroup dans la vue de ta saisie. Mais c’est plus l’exception que la règle. Et du coup ce que je t’ai décrit est une solution qui fonctionne. Mais une autre solution serait d’utiliser #LISTER_VALEURS** avec 2 qui te fournirait les clès, et de la tu pourrais retrouver tes labels courts.

    • arf ! effectivement. Je pensais que ca renvoyais le array :(

      du coup bah je sais pas.

    • Ah tiens voilà c’est ce que je m’étais noté de regarder, si avec LISTER_VALEURS ça permettait de faire la même chose. Donc là c’est un bug d’après moi ça devrait faire pareil avec ** et fournir le tableau complet, comme LISTER_CHOIX

    • je suis effectivement étonné de ce comportement. Mais il y a un historique et le modifier risque de casser les choses non ?

    • Mouais, j’ai surtout l’impression que le ** est pas vraiment pris en compte jusqu’au bout pour LISTER_VALEURS. Que ça aplatisse sans étoiles ok, mais quand il y a ** ça doit les transmettre au LISTER_CHOIX qui est appelé en sous-main, comme LISTER_CHOIX avait aussi les étoiles… Moi ça me parait un bug/oubli à corriger, et pour que ça gène, il faut 1) utiliser avec ** ET 2) avoir des groupes, ça me parait super rare et vu que c’est l’actuel qui est pas normal, charge aux deux personnes qui utilise ça (et voulait les noms des groupes intégrés y compris avec **) de changer leur code.

    Reply to this message

  • 2

    Bonjour,
    j’utilise les champs extras sur des documents, dans un site multilingue. Toutes les boucles sont en lang_select=non. Tous les champs standards du document tiennent compte de la balise ... côté public. Mais pas les champs extras ! Les codes langues [fr] etc. sont visibles : https://www.vitmanu.com/?-Nos-Services- dans la partie “Calendrier des activités”. Seul le premier document est édité en plusieurs langues (“Bourgeon d’hiver”) en attendant de régler ce problème.

    Voici le code dans le squelette qui gère l’affichage des documents :

    <BOUCLE_portfolio2(DOCUMENTS){id_article}{mode=document}{extension IN jpg,png,gif}{par rang_lien}{lang_select=non}><div class="calendrier">
    <h5>#TITRE</h5>
    #LOGO_DOCUMENT
    <h6 class="first"><:calendrier_01:> <strong>#STADE_B</strong></h6>
    <h6><:calendrier_02:> <strong>#INPUT_EC</strong></h6>
    <h6><:calendrier_03:> <strong>#MOIS</strong></h6>
    <h6><:calendrier_04:> <strong>#DESC_MAT</strong></h6>
    <h6><:calendrier_05:> <strong>#VITI</strong></h6>
    <h6><:calendrier_06:> <strong>#TRAITEMENT</strong></h6>
    </div></BOUCLE_portfolio2>

    Merci pour votre aide parce que je ne trouve pas où j’ai fait une erreur.
    Rémy

    • Je pense qu’il faut déclarer les traitements typographiques ou propres sur tes champs.
      Tu l’as fait ?

    • Merci pour ta réponse.
      En effet, c’était bien ça (“propre” en l’occurrence).
      Grand merci pour le dépannage et pour cet indispensable plugin :-)
      Rémy

    Reply to this message

  • 1

    Re-Bonjour,
    J’ai une requête concernant les champs DATE.
    La valeur par défaut lors de leur création est “0000-00-00 00:00:00”, ce qui va l’encontre de certaine restriction (NO_ZERO_DATE) difficile a désactiver chez certain hébergeur (GANDI par exemple).
    Cela génère des erreurs et rends la BDD difficilement manipulable.
    Une valeur NULL par défaut ne serait-elle pas plus adéquat?
    Merci de vos lumières.

    Reply to this message

  • 4
    benoit_888

    Comment procéder pour créer une liste déroulante avec une “Liste des choix possibles” issue de données récupérées dans une table non spip ?
    Merci de votre aide.

    Reply to this message

  • 1

    Salut,
    Je pense avoir repéré un bug.
    sur la dernière version (Spip 3.2.7 et Champ extra 3.12.4) et interface 3.5.8, lorsque l’on met un champ oui/non et que l’on indique oui par défaut, le non est par défaut.
    De même dans un menu déroulant, on peut indiquer une valeur par défaut, mais cela n’est pas pris en compte. (et sans doute ailleurs du coup, je pense)

    • Hello,
      Je ne sais pas si c’est lié mais j’ai voulu faire le même genre de champ sauf que j’ai utilisé “case unique”. Quand je fais un nouvel article, la case est bien cochée si j’ai mis “coché par défaut”. En revanche, tous les articles existants, aucun n’est sur ’on’, je dois alors faire un

      UPDATE `spip_articles` SET `AfficherLogoArticle` = "on" 

    Reply to this message

  • 5

    Bonjour,
    D’abord, merci pour cet formidable plugin !
    Toujours attentif d’un multilinguisme correct, je recommande une petite correction pour une prochaine mise à jour :
    Dans l’espace privé on voit le nom du champ (pour un article ou une rubrique), son titre avec l’objet (correctement traduit) et son id, suivi par le statut. Ce dernier n’est pas traduit !

    Cordialement

    Reply to this message

  • 2

    Salut,
    Je bugue sur l’affichage conditionnel et je me demande si ce que je tente est possible.

    J’ai vu que pour un champ oui/non, on peut utiliser

    [(#NOM_DU_CHAMP|oui) ce que l'on veut afficher ] 

    à partir du moment où “oui” a une valeur définie et pas non.

    J’ai fait un #NOM_DU_CHAMP en menu déroulant et je voudrais afficher que si l’option que je souhaite a été choisie.

    Par exemple champ couleur :
    -  vert
    -  bleu
    -  rouge

    Peut-on avoir une affichage conditionnel du type

    [(#NOM_DU_CHAMP|vert) ce que l'on veut afficher ] 

    ?
    Ou quelque chose qui aurait le même effet.

    Merci !

    • Il faut combiner le filtre |oui avec le filtre |== qui permet de vérifier l’égalité entre des valeurs :

      [(#CHAMP|=={vert}|oui) ce que l'on veut afficher ]
    • Merci tcharlss,
      je cherchais pas du tout au bon endroit... En fait, je savais pas trop ce que je cherchais ;) Mais, la doc va bien me servir !
      Merci encore !

    Reply to this message

  • Bonjour,

    Je reporte ici un bug que je pensais lié au plugin Pays mais qui d’après un autre contributeur a un rapport avec champs extras :
    https://contrib.spip.net/Liste-des-pays-avec-codes-ISO-3166-1#comment504613-502472

    Avec ce plugin à jour j’ajoute la liste des pays aux champs extra des auteurs mais cela retourne une erreur (par exemple sur la page d’un auteur) :

    Erreur SQL 1054
    Unknown column 'pays_1' in 'field list' 
    plugins/auto/cextras/v3.12.4/cextras_fonctions.php        champs_extras_voir_saisies(){ sql_fetsel(); }        356

    Le champ n’est pas ajouté en base.

    Merci !

    Reply to this message

Ajouter un commentaire

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