Champs Extras (Interface)

Ce plugin permet de créer et/ou de gérer des champs supplémentaires dans les objets éditoriaux de SPIP depuis l’espace privé de SPIP. Il s’appuie sur le plugin Champs Extras, dont il n’est qu’une simple interface graphique.

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 : séparation de l’API et de l’interface graphique

Il existe deux plugins distincts :

  • le premier, « Champs Extras » (lire « Champs Extras — introduction ») donne accès aux fonctions de création, de gestion et d’affichage des champs. Il est ne constitue qu’un outil de développement. 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 « Core » 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 ». C’est ce plugin qui est documenté ici.

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

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

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

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

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

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

Notes

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

Discussion

268 discussions

  • 2

    Bonjour,
    le seul et unique soucis que je rencontre, c’est l’impossibilité de faire un saut de ligne, ou même un simple retour à la ligne quand j’utilise un « bloc de texte » créé avec Champs Extra.
    Tout est à jour, dernière version de SPIP et de Champs Extra (et de tous les autres plugins).
    La seule solution est d’insérer directement dans le corps du texte des balises
    , ce qui n’est pas pratique à faire comprendre à ceux à qui je destine mes sites.

    Est-ce qu’il y a un truc que j’aurai mal fait ou non ?

    De même, quand je mets la possibilité d’enrichir le texte avec la barre de typo, si je mets disons du gras, le texte ne s’affichera pas en gras, mais aura les  autour (dans l’espace public).

    Par contre, dans l’espace privé, tout s’affiche bien à chaque fois..

    J’ai essayé en désactivant complètement mes CSS, mais ça ne change rien.

    Merci à vous.

    Julien

    • Depuis l’interface, c’est une option « traitements automatiques » dans l’onglet « technique ».

      Appliquer automatiquement un traitement pour la balise #NOM_DU_CHAMP résultante :

      • Aucun
      • Traitements de typographie uniquement (typo)
      • Traitements des raccourcis SPIP (propre)

      Typo prend en charge les sauts de ligne je crois, les chaines de langue. Propre prend aussi en charge les raccourcis de modèle.

      À noter que ce sont aussi deux filtres utilisables en squelette :

      • [(#TOTO|typo)]
      • [(#TOTO|propre)]
    • Vraiment parfait cette réponse. Je vais regarder ça de suite :)
      Bonne soirée.
      Julien

    Répondre à ce message

  • 6
    Teenoo

    Même après mise à jour à la version officielle de SPIP, après la mise à jour du plug, j’ai toujours un joli message d’erreur quand je souhaite configurer les caractéristique d’un champ sélectionné :

    Fatal error : Maximum function nesting level of ’100’ reached, aborting ! in C :\wamp\www\site\ecrire\public\compiler.php on line 647

    Une idée ?

    Merci pour votre réponse :)

    • Tu as certainement Xdebug, qui limite par défaut un peu trop. Tu peux ajouter dans ton mes_options.php :

      ini_set('xdebug.max_nesting_level', 200);
    • Malgrès l’ajout dans mes_options.php j’ai toujours un problème de nesting level...

      ini_set(’xdebug.max_nesting_level’, 200) ;
      Fatal error : Maximum function nesting level of ’100’ reached, aborting ! in C :\Program Files (x86)\EasyPHP-5.3.9\www\ecrire\public\compiler.php on line 647

      J’ai fureté un peu partout pour forcer le nesting level directement mais je ne trouve pas...
      Un conseil ?
      Merci

    • Bon ben avant de poser des questions stupides, la prochaine fois je regarderai mieux comment s’écrit le PHP...
      Problème résolu après l’ajout des

      <?php et ?>

      ...
      Merci

    • Merci pour l’info : je rencontrais le même problème en local également.
      Par contre, dure à trouver cette manip. Elle mériterait d’être écrite en « dur » dans l’article, non ?

    • Fait. en fin d’article :)

      Merci.

    • Parfait, comme d’hab :-)

    Répondre à ce message

  • 4

    Bonjour,
    Il me semble qu’il y a un petit « bug » sur l’espace de configuration des champs extras.
    Par exemple page : ecrire/ ?exec=champs_extras_edit&objet=article
    Si je met « champ obligatoire » pour un bloc de texte, ensuite, quand je veux modifier un champ (n’importe lequel des autres de ce squelette) j’ai toujours le message « Veuillez compléter ce champ » qui bloque toute modification. Je ne peux alors que supprimer ce champ obligatoire pour pouvoir modifier le reste.
    J’ai spip 3.0.5 et Firefox 19.
    Faudrait voir pour que soit mieux distinguer l’espace où on configure les champs des pages où on doit les remplir ?
    Merci,

    • En fait, si je tape quelque chose dans le champ obligatoire, je peux accéder quand même aux boutons de modifications, ce n’est pas hyper pratique, mais on s’en sort !

    • C’est pas plutôt une histoire de HTML5 activé dans la conf de l’espace privé qui crée ce bug dans l’interface de champs extras ?

    • Oui bien vu, le html 5 est activé. Je pensais que c’était bien de cocher ça, ça faisait moderne... Merci

    • Oui, mais cela dit, ça reste un bug ! Ça devrait pas appliquer html 5 dans l’espace privé là.

    Répondre à ce message

  • 1

    Bonjour,

    Je cherche à faire une recherche
    dans les articles sur un choix extrait d’un champs extra liste déroulante.

    Côté public, je récupère les valeur du champs
    dans un formulaire par cette boucle :

    <form method="POST" action="#URL_PAGE{recherche}">
                        <select  name="type" >
                         <option value="">Type</option>
               <BOUCLE_liste_type(ARTICLES) {id_rubrique} {par titre} {0,1}>
                 <BOUCLE_liste(POUR) {tableau #LISTER_CHOIX**{type}{par titre}}   >
                        <option value="#CLE">#VALEUR</option>
                </BOUCLE_liste>
               </BOUCLE_liste_type> 
                </select>
    <input type="submit" value="GO" name="ok">
    </FORM>

    Et sur ma page de résultats page-recherche.html :

    <B_type>
            <ul class="liste-items">
    			<BOUCLE_type(ARTICLES) {id_rubrique=3}  {cle=#ENV{cle}}  {pagination}>
    			<li ><a href="#URL_ARTICLE">#TITRE</a></li>
    			</BOUCLE_type>
    		</ul>
    </B_type>

    Mais ceci ne me retourne aucun résultats, j’imagine que ma syntaxe spipienne est pas bonne,
    mais aucun de mes différents essai s’est avéré concluant, votre aide me sera précieuse.
    Merci

    • Re-bonjour,
      Petite précision, si ce n’était pas clair :
      mon champs extra se nomme type.

      J’ai tenté ça : <BOUCLE_type(ARTICLES) {id_rubrique=3}  {type=#ENV{cle}} >
      à la place de :
      {cle=#ENV{cle}} >

      Mais toujours aucun réultat.
      Notez : ma base compte des articles dotés de cette cle|label !
      mais idem, aucun résultat.
      Merci encore.

    Répondre à ce message

  • 6

    D’abord bonjour et merci pour ce plugin

    Dans une liste déroulante, je voudrais insérer une balise pour traduire automatiquement la valeur du champs :

     
    choix5|<multi>[fr]Chantier[en]Construction</multi>
    choix6|<multi>[fr]Livré[en]completed</multi>
    ... 

    Ca ne marche pas ...
    Il me reste une solution qui consisterait à traduire l’ensemble des choix dans le fichier lang mais cela me semble plus compliqué si d’autres que moi doivent rajouter des choix à ma liste déroulante...
    L’un(e) d’entre vous aurait-il une solution ?
    Merci

    • marc hirt

      Bonjour et bravo pour ce plugin.

      Comme jérome j’étais coincé par les choix multiples avec les labels localisés :

      Dans mon fichier mes_fonctions.php j’ai ajouté un filtre :

      function filtre_echappe_lang_multi($v, $add){
      
          if($texte2 = preg_match('#\['.$add.'\]([a-z \'éèàç]*)#i', $v, $resultat)) {
            return $resultat[1];
          } else {
            return $v;
          }
          
      }

      En gros il suffit d’ajouter dans l’expression régulière les caractères que l’on autorise après le premier pattern de langue « [$add] » ensuite dans mes fichiers, ici un article, j’ajoute cela :

      couleur : [(#LISTER_VALEURS{voiture_lb_couleur}|echappe_lang_multi{#ENV{lang}})]<br>

      Sachant que « voiture_lb_couleur » est un de mes champs extra.

      j’appelle mon filtre « echappe_lang_multi » en lui passant la langue de la page. J’ai pas trouvé mieux comme solution mais je suis preneur si quelqu’un a une autre solution.

      PS : J’appelle #LISTER_VALEURS et non #NOM_DU_CHAMP car autrement ca ne me retourne pinnuts !
      J’utilise les champs extra, non pas dans des formulaires mais dans des pages simple d’article c’est peut être pour cela.

    • Bonjour. Suite à migration spip 2.1 vers SPIP3. Les libellés multilingues de mes champs extra ne fonctionnent plus . Sur mes pages du site cela s’affiche par exemple ainsi
      [en]Text of the proposal[fr]Texte de la proposition Idem si j’utilise les fichiers de langue. Sur le site c’est <:text_proposal:> qui s’affiche.

    • Il te faut :

      • soit mettre <multi>[en]Text of the proposal[fr]Texte de la proposition</multi> dans le label,
      • soit <:text_proposal:>

      En tout cas, dans l’interface privée, ces 2 écritures fonctionnent.

      Pour les squelettes, peut être te faut il ajouter à l’endroit où tu affiches ton label le filtre |typo.

    • Marc HIRT

      Encore bravo matthieu pour ce plugin !

      Juste une précision par rapport à ce que j’ai marqué plus haut, le mécanisme du filtre que j’ai décrit je l’’utilise pour les valeurs et non pour les labels comme cela pourrait être compris dans ma réponse. en gros j’utilise champ extra, pour avoir des articles avec des champs supplémentaires (j’aurai pu utiliser des mots-clé, mais je voulais quelque chose propre à un type d’article, donc les Champs Extra 3 répondaient parfaitement !

      Marc

    • Merci Matthieu. C’était bien le filtre typo qui manquait.

    Répondre à ce message

  • 4
    ploufplouf

    Bonjour,

    Je rencontre un souci avec le plugin qui me bloque la création d’article. En effet j’arrive à créer un nouvel articles dans mes rubriques pour lesquelles j’ai des champs extras obligatoires mais impossible de créer un article dans une rubrique qui ne contient pas de champ extra. Quelqu’un a-t-il déjà rencontrer se problème ? Et avez-vous une solution ou une piste pour résoudre ce problème rapidement SVP ?

    Merci à tous

    • ploufplouf

      Pour faire suite à mon problème après divers tests, le souci viendrai des champs « obligatoires » qui sont contenus dans un groupe de champ avec une restriction sur une rubrique.

      En effet quand je me place dans une rubrique qui ne contient pas ce groupe de champ, l’enregistrement est impossible sans doute du à l’attente de remplissage du champ obligatoire qui pourtant n’apparait pas dans l’article.

      Est-ce dû à un mauvais paramétrages de mes champs ans l’interface ou est-ce un petit problème du plugin ?

      Merci de vos lumières

    • Je croyais ce problème corrigé.

      Tu es certain d’avoir tes plugins à jour ?

    • J’ai un problème similaire sous SPIP 2.1.19, que j’expose ici.
      Pour résumer, une erreur sql 1064 apparait en partie privée depuis quelques semaines (on ne sait pas quand exactement, il n’y a eu aucune opération sur le site depuis octobre 2012), sur la page de visualisation d’un article (et disparait quand on passe à l’édition de l’article).
      Disparition totale du phénomène quand je désactive Interface pour Champs extras.
      Aucune incidence en partie publique, les contenus des champs extras créés apparaissent bien et mes scripts qui les manipulent marchent impec.
      Il ne s’agit pas d’un simple problème d’affichage comme je l’ai cru précédemment : en effet, on ne peut pas créer un nouvel article (plus exactement, il se crée mais les champs dispos à la saisie comme titre, chapo, texte, ainsi que les champs extras créés restent vides) mais si ces champs sont renseignés via Phpmyadmin, on peut ensuite les modifier en partie privée.
      J’ai mis à jour spip et les plugins, viré une restriction sur 3 rubriques dans un fichier mes_fonctions.php, et je ne suis pas concernée par les champs obligatoires (hypothèse qu’évoquait
      ploufplouf précédemment).

      J’ai l’impression que le plugin Interface ne parle pas poliment à Mysql (actuellement : Version PHP Version 5.1.6 - MySql 5.0.77). Me tromperais-je ?

    • C’est résolu ! Grâce à Mathieu.
      Explication : "Le nom « condition » est un mot clé réservé de mysql 5.0 (ça ne l’était pas avant) (http://dev.mysql.com/doc/refman/5.0/en/reserved-words.html). "
      En renommant ce champ, l’erreur sql a totalement disparu.
      Merci Mathieu :-)

    Répondre à ce message

  • 1

    A propos d’une date de dépublication

    Bonjour. A partir de Champ Extra, j’ai ajouté une date de dépublication pour les articles de type ACTUALITE.
    Le champ est de type DATE.

    Le problème :
    1. Quand j’ajoute la date dans mon article, j’ai un retour « Le format de la date n’est pas accepté. »
    2. Quand j’enlève la vérif DATE, ai une erreur base « Une erreur technique a empêché l’enregistrement correct du champ ’date_no’. », mais il arrive à mettre la date dans le champ de la table en laissant l’article ouvert en modif.

    Qui pourrait m’aider à comprende ?
    merci
    YO

    • Bonjour,

      j’ai le même problème, avez-vous trouvé une solution ?

      Merci beaucoup.

    Répondre à ce message

  • Je me sens ballot de poser la question, mais je n’arrive vraiment à trouver la réponse qui doit pourtant être simple) :

    Comment générer la saisie d’un champ extra ?

    J’ai un champ extra très simple (case à cocher) sur les messages de forum, et dans la partie publique, je voudrais permettre aux utilisateurs d’agir sur ce champ. Et à part refaire complément un formulaire je ne vois pas commet faire. Alors qu’il doit bein y avoir un moyen de récupérer la saisie, non ?

    Répondre à ce message

  • Ploufplouf1

    Bonjour,

    Superbe plugin très utile.. Merci !

    J’ai toutefois une petite question :

    Dans un champ « case à cocher » ou « boutons radio » je voudrais mettre en valeur une image sous la forme , est-ce possible ?

    J’ai fait un essai en intégrant plussieurs images dans un article et en notant à la place de l’intitulé mais ca ne fonctionne pas.

    Comment puis-je procéder ? Merci à vous

    Répondre à ce message

  • 1

    J’ai un site administré sous SPIP 2 que je souhaite migrer sous SPIP 3. Les champs extra 2 seront-ils conservés ? Ou faudra-t-il tout re-configurer ? Faut-il faire dans ce dernier cas pour récupérer toutes mes données ? Merci de votre réponse.

    • Il y a plusieurs choses à dire :

      1) il faut mettre à jour le SPIP 3 depuis la base SQL du SPIP 2. Les champs ajoutés et les données saisies seront forcément conservées.

      2) ce qui est parfois à recréer est la déclaration des champs extras :
      -  le plugin prend en charge la migration des champs, disons normaux (ie, fournis anciennement avec le plugin). Donc normalement, on a peu de choses à reprendre derrière, mais il peut arriver que certains champs ne soient pas correctement migrés. Il suffit alors pour ces champs de redemander à les gérer par le plugin.

    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