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

  • Bonjour,

    Est-il possible d’ajouter des champs extra sur les formulaires de forum ?

    Merci.

    Répondre à ce message

  • 1

    Bonjour,

    Peut-on ajouter des champs extras aux formulaires de forum ?

    merci.

    Répondre à ce message

  • 3
    Teenoo

    Bonjour,

    je pense que je trouverai réponse ici... j’ai créé une liste d’auteurs dans une rubrique, ce sont ceux qui peuvent lire la rubrique, ajouter des documents et modifier les autorisations de cette rubrique. Le champs est auteurs_1.

    Je souhaite bêtement dans ma boucle dire que si #SESSIONid_auteur est présent dans LISTE_VALEURSauteurs_1 alors ça affiche le titre des rubriques.

    J’ai essayé directement dans ma boucle mais c’était faux

    <BOUCLE_filtre_modif(RUBRIQUES){id_secteur IN 4}{auteurs_1 IN #SESSION{auteur}}{tous}>

    Ou un traitement conditionnel bancal

    [(#LISTE_VALEURS{auteurs_1}|==#SESSION{id_auteur}|oui) j'affiche ]

    Auriez-vous une petite idée ?

    • Ça serait :

      [(#SESSION{id_auteur}|in_array{#LISTER_VALEURS{auteurs_1}}|oui) j'affiche ]
      Ou pour une boucle {si #SESSION{id_auteur}|in_array{#LISTER_VALEURS{auteurs_1}}}

      Cependant je pense que pour ce besoin, ça serait le plugin Accès restreint à utiliser.

    • Teenoo

      Bonjour,

      eh non le restreint je ne peux pas car ce sont des rédacteurs et des admins qui peuvent créer en public leur dossier :)

      J’ai testé tes 2 solutions mais j’obtiens ce genre de message :
      Warning : in_array() expects parameter 2 to be array, string given in ... eval()’d code

    • Teenoo

      J’ai réussi avec ceci

      [(#SESSION{id_auteur}|in_array{#LISTER_VALEURS**{auteurs_1}}|oui)  affichage ]

    Répondre à ce message

  • Bonjour,
    Je rencontre un problème... il m’est impossible de configurer un nouveau champ. En effet un message d’erreur apparait dés que je clique sur l’icône de config du champ : « Oups. Une erreur inattendue a empêché de soumettre le formulaire. Vous pouvez essayer à nouveau. » (cf. capture jointe). De fait j’essaie à nouveau mais.. ben non..

    D’autre part je trouve aussi que la page « Champ Extra » fait drôle par rapport à la capture de la doc ci-dessus.. les objets Spip se répartissent sur une seule liste au lieu de 2 cotes à cotes, liens soulignés.. fond coloré 1 ligne sur deux... Puis pas de « Liste des champs présents non gérés » (mais ça c’est peut-être normal).

    Bref ça ne va pas, mais quoi ?

    Il s’agit d’un Spip 3.1.4 tout neuf installé en local (wamp).
    Les plugins installés (tous via svp) sont :
    -  API de vérification 1.6.2
    -  Champs Extras 3.11.2
    -  Champs Extras (Interface) 3.5.1
    -  Facteur 3.4.10
    -  Saisies pour formulaires 2.18.5
    -  SPIP Bonux 3.4.2
    -  YAML 1.5.2

    Avant les 2 champs extra, j’avais installé le plugin Formidable mais ce que je veux faire passant plutôt par l’usage des Champs Extras et bien j’ai supprimé le formulaire créé, désactivé puis supprimé le plugin Formidable + caches vidés, avant d’installer les Champs Extras puis de tester l’insertion de nouveaux champs dans les articles.

    Merci pour votre réponse et pour votre travail.

    Répondre à ce message

  • 2
    crazyspip

    Bonjour,

    Ma question est un peu bête mais je bloque. J’ai créé un champ multi-choix « sexe_chat » dont les cle/label sont :

    choix1|inconnu
    choix2|mâle
    choix3|femelle

    Dans mon squelette, je place #SEXE_CHAT et dans la création de mon article, je choisis « mâle ». La boucle me retourne « choix2 ». J’ai essayé avec une liste déroulante et des boutons radio pour le même résultat. Je dois avoir mal compris quelque chose... ?

    • 2 choses :

      • En configuration du champs extras, choix1 est ce qui est enregistré en bdd, tandis que Inconnu est ce qui est affiché textuellement au visiteur. Tu peux (et c’est conseillé), mettre un terme plus sémantique (mais un identifiant informatique quand même) à la place de choix1 en configuration d’une part. Par exemple :
        inconnu|Inconnu
        male|Mâle
        femelle|Femelle
      • À l’affichage, écrire #LECHAMP affiche le contenu stocké en BDD (avec éventuellement des traitements appliqués en plus dessus (typo, propre) à définir dans le dernier onglet de configuration). Mais ça n’affiche pas par défaut pour les radios ou sélections le texte humain. Pour cela il faut utiliser la balise #LISTER_VALEURS tel que #LISTER_VALEURS{sexe_chat}
    • crazyspip

      Bonjour Matthieu,

      Merci infiniment pour la solution mais aussi pour l’explication limpide. Elle mériterait d’ailleurs d’être intégrée au sein de l’explication du plugin ci-dessus car le sujet y est abordé moins clairement, je trouve. En tout cas, j’avais lu plusieurs fois et mal interprété le passage concerné. Encore merci !

    Répondre à ce message

  • 2

    Hello,

    J’ai ajouté un champ extra aux rubriques via l’API (restreint à un secteur).
    Celui-ci n’apparaît pas quand je crée une rubrique. En revanche si je modifie une rubrique existante, c’est bon (peu importe son statut).

    Ah, et aussi, la vidéo n’apparaît plus au début de l’article :)

    Champs extras 3.8.0
    SPIP 3.1

    • Oui tcharles, si l’id_rubrique (id_parent ?) n’est pas dans l’environnement, on n’affiche aucun champ « restreint » de ce type. En d’autre termes, si on ne sait pas où se situe ce qu’on édite, les champs restreints ne sont pas affichés.

    • J’ai corrigé l’intégration de la vidéo aussi du coup.

    Répondre à ce message

  • Bonjour,
    Je voulais juste signaler qu’il semble que l’emploi des chaînes de langues ne fonctionnent pas sur les documents, alors qu’ils fonctionnent sur les articles, rubriques, auteurs...

    Répondre à ce message

  • 6

    Bonjour,

    je viens signaler un petit soucis avec le plugin. En effet, pour l’utilisation en public avec #FORMULAIRE_EDITER_ARTICLE si nous renseignons une restriction à un secteur ou une branche les champs extras n’apparaissent pas. Il faut enlever toute restriction pour faire fonctionner l’ensemble.

    C’est assez contraignant d’avoir le formulaire actif sur l’ensemble d’un gros site pour un seul secteur...

    • Comment cela n’apparaissent pas ? ils n’apparaissent pas si c’est un nouvel article et qu’il n’y a aucune information de rubrique indiqué au chargement du formulaire.
      En dehors de ce cas là, donc avec id_rubrique dans l’url ou id_rubrique transmis à #FORMULAIRE_EDITER_ARTICLE, ça doit fonctionner.

    • Oui, c’est bien la création d’un article. Pourtant l’id de la rubrique est bien mentionnée et le formulaire est inclue dans sa boucle.

      #FORMULAIRE_EDITER_ARTICLE#ID_ARTICLE, #ID_RUBRIQUE, #SELF

    • Ah oui, en fait pour les nouveaux articles il faut le &id_rubrique dans l’URL.
      C’est pour les articles déjà existants que ce n’est pas nécessaire.

    • Qu’appelle-tu l’URL ? faire une sorte #ENV ?

    • trouvé :) Effectivement ça va mieux ! Merci du tuyaux !

    • bonjour j ai un sousci avec mon pourtable teeno ildemande mot de passe protection de la vie privee merci besoin aide svp

    Répondre à ce message

  • 9

    Bonjour,

    J’ai importé un fichier de fichier extra exporté depuis un autre site.
    Le changement dans la db a bien été effectuée mais lorsque que je vais sur /ecrire je n’ai pas accès aux nouveaux champs.
    Le cache a été vidé, la version pour :spip 3.1.3, champs extra 3.11.2. et php 2.6
    Le test a été fait en gardant seulement les plugins nécessaires.
    Je cherche une piste pour comprendre ce qui se passe, avez vous une idée ?
    Merci d’avance

    • Bonjour,

      Je rajoute une précision après avoir eu une illumination.
      J’ai activé de nouveau le plugin partageur et je me suis aperçu que un article créé par ce plugin ne prenait pas en compte les champs extra (ce qui n’est pas en soi si catastrophique) mais par contre en retournant sur ce même article pour le modifier (via /ecrire) je n’ai pas accès aux champs gérés par champs extra.
      Pouvez-vous me donner une piste ; quelque chose dans la db, un fichier généré ?
      Merci d’avance,
      Brice

    • Les champs peuvent avoir des autorisations particulières, tel que limités au secteur 1 du site ou je ne sais quoi. Est-ce que ce point a été vérifié ?

    • Matthieu,

      Oui en effet les champs extra font partis d’un groupe sur lequel une restriction a été positionnée (appartenance à une rubrique qui est la numéro 2). Mais lorsque l’article est importé via le partageur, il est aussi créé dans cette rubrique.
      Si je crée un article manuellement dans cette rubrique j’ai bien accès aux champs extra mais pas lorsqu’il est créé via le partageur. Une liste quelque part est constituée peut-être ?
      Merci pour ton retour,
      Brice

    • Humm j’ai l’impression d’avoir fait une erreur de manipulation en répondant à ton message ...

    • Non, il n’y a pas de liste particulière. L’autorisation est testée au moment où on en a besoin.

      Il faudrait peut être regarder dans la BDD qu’est-ce qui change pour ces articles créés avec le Partageur (je ne connais pas ce plugin). Peut être qu’il n’intègre pas la valeur du champ « id_secteur » ? ou ne demande pas à l’actualiser.

      Comme restriction tu as mis « rubrique » 2 ou « secteur » 2 ?

    • Matthieu,
      Merci beaucoup !!! Tu as mis le doigt sur le problème en effet.
      Le partageur ne semble pas renseigner l’information du secteur en effet dans mon cas précis.
      Merci encore pour avoir consacré du temps à mon problème.
      Brice

    • Hum… comme je disais je ne connais pas ce plugin.
      Si tu as d’autres articles à traiter avec le partageur, peut être que tu pourrais tester une modification de celui-ci, autour de la ligne 660 de exec/partageur_import.php dans ce plugin.
      Remplacer id_parent par id_secteur. Donc remplacer :

      // recupère id du secteur
      function partageur_get_id_secteur($id_rubrique) {
      	   if ($row = sql_fetsel("id_parent","spip_rubriques","id_rubrique=$id_rubrique"))
                                 return $row['id_parent'];
      	return 0;
      }

      Par :

      // recupère id du secteur
      function partageur_get_id_secteur($id_rubrique) {
      	if ($row = sql_fetsel("id_secteur","spip_rubriques","id_rubrique=$id_rubrique")) {
      		return $row['id_secteur'];
      	}
      	return 0;
      }

      J’imagine que c’est un des problèmes. Ce n’est peut être pas le seul cependant.

      Sinon il faudrait après avoir intégrer des articles que le plugin appelle la fonction « calculer_rubriques() » de SPIP pour recalculer les identifiants de secteurs sur les rubriques. Faudrait que je vois avec Erational.

      MM.

    • Ah wouahh, ça c’est de l’entraide !!
      Je vais faire des tests, j’avais déjà écrit un petit mot dans le forum du partageur.
      Merci encore pour ton aide et ton implication dans la communauté !

    • Merci pour le signalement. Je corrige le partageur de mon coté.

    Répondre à ce message

  • 2

    Bonjour,

    Je viens d’installer champs_extras sur une spip 3.1.3 en test.

    J’ai un champ qui provient d’un sélecteur d’article et quand je veux
    utiliser la balise résultante ici #ARTICLE_PERE dans un squelette
    j’obtiens ceci « article|359 » (359 est bien l’id de l’article).

    J’ai l’impression de ne pas avoir tout compris : comment extraire
    uniquement la valeur « 359 » pour l’utiliser dans une boucle article ?

    Merci d’avance,

    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