Champs Extras (Interface)

Publié le : 16 janvier 2012 – Dernière modification le 13 janvier 2022 – par Matthieu Marcillaud – 830 commentaires

1
2
3
4
5
80 votes

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

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

Discussion

5 ans 1 an 3 mois Sans limite
par date
Filtrer

268 discussions

  • 1
    aka80

    Bonjour à tous

    J’ai un petit soucis pour afficher les noms des champs et valeurs d’un article. Je m’explique

    J’ai créé à l’aide du plugin champs extras 3 des champs ( Nom (nom du champs : nom_membre ) , prenoms (nom du champs prenom_membre) et j’ai intégré ces champs aux articles.
    Quand je crée maintenant un article, j’ai en dessous les champs nom et préom qui sont visible et qu’on peut renseigner.
    Jusque là tout va bien .
    Maintenant bon but c’est d’afficher les valeurs des champs de cet article dans une boucle qui se retrouve dans un squelette.
    En cherchant sur le net j’ai eu une piste mais qui ne marche pas mais c’est un début de piste. Voilà ce que j’ai mis :

    [valeur extra : (#ENVvaleur_extra)]

    Mais là rien ne marche. Je suis sûr que c’est possible et que quelqu’un parmi vous à la solution.

    Répondre à ce message

  • 2
    yonddaime

    Bonjour,
    Je n’arrive carrément pas à aller sur l’onglet « restriction » et « technique ». En gros, quand je clique dessus l’onglet est vide..
    D’où ça peut venir ??
    Merci.

    Répondre à ce message

  • papa.troll

    To display articles from ’selecteur article’ field I use :

    <BOUCLE_joined(ARTICLES) 
                 {id_article IN #SELECTEUR_ARTICLE_2*|picker_selected{article}} {tout}>
                 <li><a href="#URL_ARTICLE">#TITRE</a></li>
</BOUCLE_joined>

    Répondre à ce message

  • 6
    arriflex

    Bonjour et merci pour ce plugin formidable,

    Je cherche à utiliser l’option Affichage conditionnel pour afficher une ligne de texte si un case a été précédemment cochée.

    Le champ comportant de cette case s’appelle : film_checkbox, et il n’y a qu’un choix possible choix1|oui

    J’ai testé ces paramètres pour le champ conditionnel :
    @film_checkbox@==“checked”
    @film_checkbox@==“oui”
    @film_checkbox@==“choix1|oui”

    mais rien ne semble fonctionner.

    Est-ce que vous sauriez me dire d’où vient l’erreur ?

    Merci beaucoup !

    • arriflex

      ... vraiment aucune solution ou ressource à conseiller pour que je puisse m’en sortir tout seul ?

      Merci beaucoup !

    • arriflex

      Bonjour,

      Je rencontre toujours ce problème et n’ai pas tellement l’ombre d’une solution...
      Quelqu’un aurait-il une piste pour m’aider ?

      Merci d’avance

    • Raphaël

      Salut,

      Je ne suis pas sûr que ça t’aide, mais as-tu pensé à utiliser les filtres de spip : « si la valeur existe, sinon » ?

    • arriflex

      Merci Raphaël pour ta réponse !

      Et bien dans la configuration des champs extra, l’option Affichage>Affichage conditionnel me semblait toute indiquée pour éviter de surcharger les squelettes de la partie privée (comme la propriété que tu suggères devrait en effet permettre de faire).

      Je souhaite qu’un ligne de texte apparaisse si une checkbox (ayant pour valeur « oui ») a été cochée et le code appliqué L’Affichage conditionnel de la ligne de texte

      @film_case_adaptation=="oui"

      ne donne rien...

    • arriflex

      Bon, je me réponds finalement :

      Il y avait une double erreur d’écriture du code conditionnel

      @film_case_adaptation@=="on"

      1) Il manquait le 2èmè @ après le nom du champ
      2) j’ai mis non pas l’attribut « on » et non pas « oui » (il n’y avait qu’un seul choix de case à cocher)

      Et ça fonctionne !

    • Raphaël

      Cool : Je retiens l’info, ne m’en étant pas encore servi. ^^

    Répondre à ce message

  • 3
    anthony

    Bonjour,

    Est-ce que quelqu’un aurait un exemple de code pour récupérer un article lié depuis le selecteur d’articles du plugin svp...
    J’ai beau avoir des pistes (picker_selected, IN, etc...), je n’’arrive pas à m’en sortir ! :/
    Merci d’avance

    Anthony

    • anthony

      J’ai oublié de préciser que je cherche à le récupérer dans un squelette évidemment...

    • Raphaël

      Salut,

      Une méthode parmi d’autres :

      <BOUCLE_liste_valeurs(ARTICLES){id_article=#LISTER_VALEURS{nom_du_champ_extra}|replace{article\|}}{0,1}>
	#SET{url_article_selectionne,#URL_ARTICLE}
	#SET{titre_article_selectionne,#TITRE}

	#GET{url_article_selectionne}
	#GET{titre_article_selectionne}
</BOUCLE_liste_valeurs>

      En espérant que cela te convienne...

    • anthony

      Yes !! Merci beaucoup raphael !!
      Je vais pouvoir arriver à ce que je veux à partir de là.
      Pas tout compris encore à la logique du SET et du GET.
      Encore merci
      ANthony

    Répondre à ce message

  • 1
    ElJuez

    Bonjour à tous,

    Cela va vous paraître très bête, mais voilà, je me remet tout doucement à spip quand j’ai le temps avec un autre contributeur d’ici (Jack31).
    Donc comme je le disais, je me remet en route petit à petit et j’essaie d’utiliser un champs extra dans un filtre.

    En fait j’ai une boucle sites (de l’html5 dedans)
    BOUCLE_site1(SITES)id_secteur=3
    bla bla bla
    /BOUCLE_site1
    Rajoutez les symboles qui vont bien < et >
    Voila, ça fonctionne bien, mais maintenant j’ai un champs extra qui s’appelle ETAT_SITE et qui a trois valeurs possibles ... et je n’arrive pas à ajouter un filtre sur ce champs extra ...

    Comment faire ? J’ai fait des recherches et j’ai pas vu (ou alors suis aveugle) de manière de filtrer sur un champs extra.

    • Jacques

      J’ai utilisé une écriture qu’on m’avait indiquée il y a quelques années. C’est peut-être trivial et ça semble assez simple... une fois qu’on le sait ^^ Cet usage n’est pas décrit dans l’article ci-dessus et il y a peut-être d’autres solutions mais je trouve la façon de faire ci-dessous bien pratique.

      Pour commencer j’ai nommé le champ-extra ajouté aux sites référencés avec un nom facilement identifiable, je l’ai appelé « statut_site ».
      Puis j’ai également mis des noms facilement identifiables dans la liste des choix possibles :
      actif|En activité
      avenir|A venir
      arret|Arrêté

      Ensuite j’appelle le critère comme ça {statut_site == 'actif'}

      Ce qui donne dans la première boucle :
      <BOUCLE_site1(SITES){id_secteur}{statut_site == 'actif'}>
      Et pour les boucles suivantes il suffit de remplacer « actif » par « avenir » ou « arret »

    Répondre à ce message

  • 4
    Julien

    Bonjour,

    Plus moyen de mettre des champs extra dans les documents.

    Il me génère l’erreur suivante :

    Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/www/9ac78dca8bb398fab50aefda8e0c2440/web/test/plugins/auto/champs_extras3/cextras_pipelines.php on line 213

Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/www/9ac78dca8bb398fab50aefda8e0c2440/web/test/plugins/auto/champs_extras3/cextras_pipelines.php on line 222

    Une idée ?

    Merci d’avance

    Répondre à ce message

  • 1
    checkbox dans l’espace privé

    Bonjour,

    Quelqu’un pourrait-il m’aider a changer la présentation des checkbox dans l’espace privé. Car suivant comment cela me fait des énormes liste et je trouve dommage de ne pas pouvoir exploiter les espaces libre dans la mise en page. Voir images ci-dessous.

    Merci beaucoup ! :-)

    • Matthieu Marcillaud

      C’est une histoire de CSS donc.

      Il te faut par exemple créer un CSS qui sera utilisé dans l’espace privé. Si tu as un plugin perso, ou en trichant dans squelettes/ c’est possible avec un fichier squelettes/prive/style_prive_plugin_CEQUETUVEUX.html

      Avec dedans

      #CACHE{3600*100,cache-client}
#HTTP_HEADER{Content-Type: text/css; charset=iso-8859-15}
#HTTP_HEADER{Vary: Accept-Encoding}

.formulaire_editer_article .editer_nomduchamp .choix {
    display:inline;
}

      C’est le code CSS le plus simple. Il faut remplacer article par ton formulaire à toi si ce n’est pas l’édition d’un article, et nomduchamp également par le nom du tien !

      Il y a de quoi améliorer le CSS, mais là tu as la base.

    Répondre à ce message

  • 7
    Jean-Charles

    Super plugin.
    Malheureusement, je reste bloqué sur un phénomène bizarre en saisie d’une zone supplémentaire (de type date) mise dans la table articles. Comme un dessin vaut mieux qu’un long discours, voila comment ça se présente dans l’image jointe. (J’aurais aimé l’insérer dans mon texte mais bon...).
    J’ai donc 2 ’date-picker’ qui se font concurrence et au final, j’ai une erreur à la validation de l’article.
    A l’entrée en modification sur la fiche article, la zone est remplie par jj/mm/aaaa alors que le champ est renseigné dans la bdd par une date valide (20/10/2013).
    Quand je choisis la date en cliquant sur le petit triangle, la zone se remplit bien.
    Quand je choisis en cliquant sur le calendrier, la zone reste avec l’affichage jj/mm/aaaa.
    Quelque soit la méthode employée (l’une ou l’autre ou les deux), la validation me renvoie une erreur. J’ai mis dans le fichier joint l’extrait du source de la page html :

    Les versions utilisées :
    SPIP 3.0.11 [20757]
    AnythingSlider 2.0.0 - dev
    API de vérification 1.0.3 - test
    Articles d’accueil 1.1.1 - test
    Aveline 2.3.7 - stable
    Champs Extras 3.2.5 - stable
    Champs Extras (Interface) 3.1.0 - stable
    Compositions 3.3.4 - test
    Court-circuit 2.4.0 - stable
    GIS 4.9.6 - stable
    Menus 1.4.6 - stable
    Mini Calendrier 2.3.5 - test nécessaire Pour Aveline
    minibando 1.1.3 - stable
    NoiZetier 2.2.0 - stable
    Pages 1.0.2 - stable
    Saisies pour formulaires 1.35.0 - test
    SPIP Bonux 3.0.5 - stable
    YAML 1.5.1 - stable
    Zen-Garden 2.5.3 - test
    Zpip-dist v1 1.7.22 - stable
    Zpip-vide 2.1.3 - stable

    Si quelqu’un peut m’aider .....

    • Matthieu Marcillaud

      Je ne sais pas pourquoi le code javascript est visible (sur ta capture).

      Par contre le format de date attendu dans la base de données est de type Mysql, « datetime » soit « yyyy-mm-dd hh:mm:ss ». C’est possiblement pour ça que le sélecteur de date ne fonctionne pas par défaut comme tu veux.

    • Jean-Charles

      L’image est un assemblage par photoshop. Le script provient du code source de la page donné par chrome.
      J’ai oublié de dire qu’avant d’avoir cette bizzarerie, ça marchait avec l’icone calendrier à la droite de la saisie. Et puis, sans savoir pourquoi ni comment, j’ai vu apparaitre cette double saisie pour une même zone (mise à jour de plugins ? nouveaux plugins ?). J’ai alors désactivé tous les plugins inutiles pour l’instant pour ne conserver que les plugins que j’avais quand ça marchait et j’ai supprimé le répertoire cache. Même problème. En fait, si je pouvais faire disparaitre le date-picker situé à l’intérieur de la zone de saisie, je pense que ça réglerait le problème. Mais comme c’est de la génération de code, je ne maitrise pas encore suffisamment l’environnement spip pour savoir où chercher. Est-ce par exemple, en définissant une classe css pour cette zone, ça réglerait le problème ?
      Je précise aussi qu’en dehors de ce champ extra je n’ai pas de problème de saisie de date par exemple en modifiant la DATE DE PUBLICATION EN LIGNE d’un article.

    • Jean-Charles

      J’ai un peu avancé. Dans le code html côté client, à l’endroit de la saisie de la date (balise input), je lis ceci :
      input type=« date » name=« date_evt » class=« date date datePicker hasDatepicker » id=« champ_date_evt » value=« 21/07/2013 » maxlength=« 10 »
      Je ne suis pas un expert en html. En standard, je n’ai pas trouvé de valeur date pour l’attribut type. Si je remplace à la volée type=’date’ par type=’text’, cela fonctionne. Je peux utiliser l’icone calendrier à droite de la zone et ma date est bien mise à jour dans mysql (comme avant).
      Si ça peut mettre sur la voie d’une solution...

    • Jean-Charles

      A priori, le type date est possible en HTML5. J’ai fait la modif provisoire dans le plugin Saisies dans le fichier saisies/date.html où j’ai forcé le type text quelque soit la version du HTML. Je ne sais pas juger si la modif est pertinente mais ça débloque la situation. Peut-être y a-t-il une évolution dans l’interface avec le plugin Saisies concernant les dates ?

    • Matthieu Marcillaud

      Hum, je pense que tu as du activer dans la configuration de SPIP l’option HTML5…

      Et on a du coup des interférences on dirait avec le plugin saisies et cette option de date.

      C’est problématique.

    • Jean-Charles

      C’est exact. J’avais le html5 actif. J’avais eu le réflexe de le désactiver. Mais que pensez de l’option :
      Se limiter au HTML4 sur le site public ?
      Est-ce à dire que le html5 est systématiquement actif dans l’espace privé ?
      Vu que les champs extras sont dans l’espace privé !

    • Matthieu Marcillaud

      je confirme que ça vient de cette option ton souci, mais ça ne le fait pas avec tous les navigateurs qui plus est j’ai l’impression. En tout cas, j’ai pareil que toi avec Chrome, mais ça ne le fait pas avec Firefox… Enfin…

      En fait c’est pour l’option, normalement elle n’est là que pour l’espace public (enfin je suppose). Mais là nous sommes face à un problème avec le plugin Saisies, qui met des tests #HTML5 pour définir le type du champ, et ce quelque soit l’usage de ce champ. Or là dans notre cas, il y a un javascript qui se charge d’ajouter le sélecteur de date déjà. Et visiblement, lorsqu’il y a ET le type date, et le javascript, ça plante (double affichage du coup de sélection) avec certains navigateurs.

      Je ne vois pas trop là, à froid, comment améliorer ça proprement…

    Répondre à ce message

  • 4
    bcaron

    Champ extra est vraiment extra.
    J’ai des difficultés pour protéger des champs (ou alors je n’ai pas trouvé comment faire)
    1er exemple
    Restriction/Voir la saisie : Tout le monde peut
    Restriction/Modifier la saisie : Seulement les administrateurs
    En fait les utilisateurs peuvent modifier le contenu du champ, même non administrateur

    2e exemple
    Afin de palier le problème ci dessus, je fais en plus :
    utilisation/Lecture seule : Le champ peut être lu, sélectionné, mais pas modifié : oui

    Effectivement le champ n’est plus modifiable mais même les administrateurs ne peuvent le modifier.

    Y a t il une solution pour que, par exemple dans la fiche auteur, les utilisateurs voient certains champs sans qu’ils puissent les modifier mais que les administrateurs le puissent ?

    Merci

    • bcaron

      je n’ai pas été clair
      1er exemple :
      1er exemple
      Restriction/Voir la saisie : Tout le monde peut
      Restriction/Modifier la saisie : Seulement les administrateurs
      En fait le champ n’apparait pas

      2e exemple
      Restriction/Voir la saisie : Tout le monde peut
      Restriction/Modifier la saisie : Tout le monde peut
      Le champ apparait et tout le monde peut le modifier : normal

      3e exemple
      Afin de palier le problème ci dessus, je fais en plus , par rapport au 2 :
      utilisation/Lecture seule : Le champ peut être lu, sélectionné, mais pas modifié : oui
      mais le champ n’et modifiable par personne même pas les webmestres.

      Y a t il une solution pour que, par exemple dans la fiche auteur, les utilisateurs voient certains champs sans qu’ils puissent les modifier mais que les administrateurs le puissent ?

      Merci

    • Matthieu Marcillaud

      En fait tu dis qu’il y a un bug ?

      Parce que normalement, oui c’est possible de permettre de voir à tous les rédacteurs, et de ne permettre de modifier qu’aux administrateurs.

    • bcaron

      mon problème concerne des visiteurs authentifiés mais non rédacteurs

    • Matthieu Marcillaud

      Mais comment des visiteurs authentifiés peuvent ils se rendre dans l’espace privé ?

      Ou alors je ne comprends pas ; tu souhaites que ces autorisations fonctionnent dans l’espace public ?

    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