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

Footnotes

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

Discussion

252 discussions

  • 8

    Bonjour,
    Suite à la mise à jour de champs extra et champs extra interface :
    La mise à jour du plugin « Champs Extras » (de la version : 3.13.2 à 3.14.2) s’est correctement déroulée
    La mise à jour du plugin « Champs Extras (Interface) » (de la version : 3.5.8 à 3.5.9) s’est correctement déroulée

    Je n’arrive plus à valider certains de mes formulaires :
    Il y a 1 erreur dans votre saisie, veuillez vérifier les informations.

    Par contre je ne vois pas ou ca coince précisément. (quel champs par exemple).
    Une erreur est ajouter dans le journal de yaml.log
    3. erreur plugins/auto/yaml/v2.0.13/inc/sfyaml.php:L76:sfyaml_yaml_decode()
    Erreur d’analyse YAML : Unable to parse line 116 (data).

    Une idée?
    Merci

    • Un export du formulaire pour aider à debuger ?

    • Bonjour Maieul,
      C’est toujours le même formulaire, je ne peux pas faire d’export puisque tout est codé en php et nécessite des fonctions et une base de données bien formatés...
      Je t’envoie un email avec le php “nettoyé” pour consultation.

      Merci

    • as tu mis aussi à jour verifier et saisies qui fonctionent de conserve ?

    • Oui, j’ai commencé par tester ces mise à jours, je pensai que cela venait de la, mais j’ai fait un test dans la foulée sans problème.
      Donc à priori “saisies” et “verifier” ne sont pas en cause.

    • bah comme c’est saisies et verifier qui s’occupent de verifier les formulaires...si a priori ils sont en causes. On a mutualisé les moyens, et du coup ca a pu casser les choses dans le refactoring.

      Pour le message d’erreur sur le .yaml, c’est corrigé avec la v3,.51.4 (concernait l’édition d’une selection multiple dans une interface de modife des cextras)

    • Bon, alors après analyse voici ce qu’il en est de ce dossier

      1. En janvier, petite modifications dans champs extra de sorte que les champs masquées par afficher_si sont vidées lors de la soumission, pour que ce qui soit en base corresponde à ce qui est effectivement postée (et donc éviter des tests après coup)
      2. Problèmes : il y avait un bug dans afficher_si, résolu en mars,qui faisait qu’un champ conditionné par un champ sur un autre fieldset était vidé à la soumission (cf historique des messages ici)
      3. Un bugfix temporaire pour Jul : mettrre un “afficher_si_avec_post” sur les champs en question, pour être sur de ne jamais perdre la valeur
      4. En mars, je modifie les verifications de cextras pour qu’il utilise véritablement l’API de Saisies.
      5. Du coup, dans le cadre du formulaire de Jul, on post un champ qui combine les 3 critères suivantes

      • Il est vide
      • Mais il est obligatoire
      • Mais il est masqué comme afficher_si_avec_post
        Un tel champ n’aurait normaleemnt pas du exister, car :
      • Si on met un champ vide et obligatoire, on ne peut pas d’afficher_si:_avec_post, mais uniquement afficher_si
      • Si on met un champ vide avec un afficher_si_avec_post, il ne peut être obligatoire, puisque la logique d’afficher_si_avec_post c’est que l’affichage est masquée, mais le reste des contrainte sur le champ reste :)
      • Son met un champ obligatoire avec afficher_si_avec_post, il faut accorder alors une valeur par défaut

      Bref, le bug de JUL est lié à bugfix rapide sur un bug résolu depuis. Il lui faut donc enlever son afficher_si_avec_post et ce sera résolu (fort heureseuemnt afficher_si_avec_post est peu documenté)

    • pour info, ceci nous a bien fait cogiter sur les liens entre afficher_si_avec_post et verification, et du coup une nouvelle versions de saisies est sortie qui devrait éviter à Jul ce genre d’erreur avec son code actuel (mais il devrait totu de même supprimer ses afficher_si_avec_posts qui n’ont guère de sens en champ extra)

    • pour infos aussi Jul : on a scinder la doc, en distinguant celle consacré au core de cextras, et celle consacré à l’interfade

      donc à l’avenir https://contrib.spip.net/Champs-Extras plutot

    Reply to this message

  • 1

    bonjour,
    si j’ai plusieurs sites avec les mêmes squelettes
    est-ce que je dois créer les champs extra sur chaque site ou peut- on les importer?
    merci

    • si tu déclare tes champs extra via l’interface, il y a un plugin pour faire des imports/exports.

      Mais le mieux serait encore déclarer tes champs extra dans ton jeu de squelettes (que tu ferais sous forme de plugin). Ceomme cela à l’activation du squelette-plugins, tes champs extra sont installés automatiquement, et tu n’a pas de problème de synchro.

    Reply to this message

  • 6

    Bonjour Maieul,
    Je rencontre des soucis avec la toute dernière version.
    Ca fait 24h que je me casse la tête sur un nouveau bug sur les sites de mes clients, pour enfin réaliser que cela provient de la dernière mise à jour...
    J’ai regardé les modifs et commentaire sur Git.
    Le problème est le suivant :
    J’utilise des champs extras sur des événements, j’utilise la fonction “afficher_si” sur nombre de ces CA, et même en cascade...
    Désormais quand je modifie un événement, des données (des CAs) sont supprimées de la BDD, alors qu’ils sont liés à des champs bien affiché... C’est très impactant comme soucis...

    Je déduis donc que le nouveau comportement d’afficher_si qui “reset” les datas des champs non affichés, semble également vider des champs affichés ...
    Je vais ajouter des afficher_si_avec_post" => True à gogo pour voir si ca aide mais malgré tout, je pense qu’il y a une coquille qqpart.
    Merci de ton assistance.
    JuL

    • hum. C’est vraiment très très étonnant ton affaire.

      Pourrais tu m’exporter tes champs extras ?

      en attendant je vais supprimer le tags, par précaution. Mais j’avais testé chez moi.

    • Je peux pas les exporter aux formats YAML car je les déclare en php dans mon plugin. Il sont très nombreux et il y a plein de php autour donc tu pourras pas faire un test facilement.

    • envoi moi ton php alors :)

    • en tout cas je viens de retester, et je ne reproduis pas...

    • Suite et fin de l’épisode

      pour info, on a debuger un cas de bug sur les afficher_si, qui peut
      expliquer le bug que tu as eu en janvier.

      Cela se produisait si un champ A était conditionné par la valeur d’un
      champ B qui se trouvait dans un autre fieldset.

      la dernière version de saisies 3.47.3 corrige cela.

    • Il se confirme que le bug était bien lié à cela.

    Reply to this message

  • 6

    Bonjour,
    Depuis quelques versions de champs extra, je dois enregistrer plusieurs fois les modifs pour qu’elles soient effectives. Pour info, je rencontre toujours le problème malgré les maj, je suis actuellement en :
    -  Saisies pour formulaires 3.48.2
    -  API de vérification 1.12.0
    -  Saisies pour formulaires 3.48.2
    Est ce un problème connu ?
    Merci à vous

    • Bonjour,

      cela ne me dit rien. Mais la phrase est peu claire. S’agit-il de modifs
      1. De la valeur de champ extra en particulier ?
      2. Des champs extra eux même (via l’interface graphique).

      Utilisez vous des afficher_si ?

    • Je précise, cela arrive à la création et à la modification de champs extras via l’interface champ extra. Typiquement sur les labels. Ce qui est étrange c’est la différence de valeur entre l’écran de recap des champs extras et le formulaire d’édition des champs extras. Souvent bon dans le forum mais non mis à jour dans l’écran de récapitulatif général (page principal du plug-in interface champ extra)

    • Pas d’utilisation conditionnelle via afficver_si

    • Hum, je ne reproduis pas via l’interface. Et il n’y a pas eu de modif de l’interface ces derniers temsps. En revanche pas mal de modif côté saisie sur l’affichage en onglet, mais je ne vois pas ce qui pourrait jouer.

      Une possibilité cependant, mais cela remonte à il y a au moins 2 ans, ce sont les modifs que j’ai faite sur les sessions et saisies. Peut être du coup vider tout tmp/sessions (en s’assurant que personne ne soit connectés à ce moment là) pour avoir une base saine.

      Si le problème se reproduit, il faudrait alors essayer d’investiguer plus. Et pour cela, nous décrire pas à pas à quel moment cela arrive.

    • Effectivement le problème n’est pas récent et je le rencontre sur différents sites, j’ai longtemps garder une version inférieur pour l’éviter.

      J’ai essayé en vidant les sessions, le problème apparait toujours de façon aléatoire.

      En re-testant, un autre phénomène se produit, après l’ajout d’un champ (testé avec case unique), quand je demande son édition pour renseigner ses infos, le champ disparait complétement (directement au clic sur picto édition). Se genre de phénoménes a lieu également avec le plugin formidable, lors de l’ajout de champ.
      Je suis chez OVH en PHP 7.2, FPM, si cela peut aider.

    • Hum. je viens de retester aussi formidable, et je ne rencontre pas le problème que vous décrivez.

      Est-ce que vous auriez par hasard des plugins supplémentaire qui pourraient interferer avec le JS? Serait-il possible de me monter un site de test/dev pour que je puisse voir ce qu’il en est, et voir si j’arrive à debuger en live, puisque je n’arrive pas à reproduire le bug chez moi.

    Reply to this message

  • 1

    Bonjour
    je ne trouve pas comment limiter les champs extras “articles” à une rubrique

    merci pour votre aide
    Natacha

    Reply to this message

  • Bonjour,

    petite question sur un blocage... est-ce possible de récupérer les valeurs de groupes de champs ?
    J’ai un groupe appelé prix avec : titre, contenu, et prix (en input text ou textarea). Pour le bien de présentation je souhaite faire un tableau des valeurs pour une boucle DATA afin de bien ordonner mes données (il se peut que mon groupe prix1 soit présent mais prix3 absent donc je ne veux pas mettre une ligne de code pour chaque groupe...)

    merci pour votre aide !

    Reply to this message

  • 2

    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

  • 2

    Bonjour,

    Je rencontre un petit souci avec Champs extra 3.
    Je dispose dans l’objet article de 188 champs extras.
    Je m’y retrouve très bien. Il n’y a pas de Fieldset. Ce n’est qu’une suite de champs que je lis et que je complète.

    Mon souci est le suivant : si sur ma base de donnée, je peux créer une colonne supplémentaire ; sur Champ extra, je ne peux pas ajouter ce 189e champ.
    Si j’essaie d’intégrer ce “champ non géré”, l’interface de Champs extra 3 saute et je dois recharger une sauvegarde en yaml qui ne tient compte que des 188 premiers champs.

    Ma BDD est toute petite : 1762 lignes ou enregistrements sur spip_articles. 7Mo.
    Il n’y a pas de restriction de secteur ou de branche.
    Le nom de ce champ ou de ces champs supplémentaires ne sont pas en cause. Il n’est pas employé pour un mot-clé et est écrit en minuscule.

    Ma configuration
    Base MySQL
    SPIP 3.3.0-dev [24578]
    Champ extra 3.13.0
    Champs extra interface 3.5.8
    Saisies 3.43.0
    SPIP Bonux 3.5.5
    YAML 1.5.4 - stable
    Groupes arborescents de mots clés 1.2.11
    Coche Mots 1.2.1 - stable
    couteau suisse, orthotypo et Fulltext

    Quelle pourrait être la cause de ce refus de gérer un champ ?
    Y aurait-il une limite en nombre de champ extra ?
    En vous remerciant par avance de vos idées et d’une éventuelle solution.
    Bien à vous
    Eric

    • Il y a une limite au nombre de champ extras gérable par l’interface.

      Les informations sur les champs extras par l’interface sont stockés dans la table spip_metas, sur une colonne “valeur” qui ne peut contenir que 65535 caractères. Il se pourrait donc que l’ensemble de la description de vos champs extras, avec toutes les metas informations et serializés, dépasse cela, et que le plugin d’interface n’arrive pas à gérer.

      Je dis cela comme hypothèse, car je ne connais pas grand monde qui utilise 188 champs extras (ca pose tout de même une sérieuse question de pourquoi utiliser une telle structuration? Ne faudrait-il pas créer plutot des objets à part).

      Pour vérifier mon hypothèse, il faudrait avoir la valeur dans la table spip_metas pour la cle champs_extras_articles.

      Pour résoudre ce problème, deux solutions
      1) soit passer par une déclaration de champs extras en PHP, qui n’est pas limitée (enfin si, j’imagine que mysql a un nombre maximum de colonne)
      2) soit modifier la structure de la table spip_metas pour que le champ valeur soit de type BIGTEXT

    • Bonsoir,

      Tout d’abord, merci de m’avoir répondu. Votre analyse était juste.
      Dans la table spip_meta, la colonne valeur était limité à 65535 caractères et mes informations sur les champs extras étaient de 65460.
      En modifiant, la structure de la table spip_méta, il m’est désormais possible de rajouter des champs extra.
      Concernant le pourquoi d’une telle structuration, il devient urgent, je pense, que j’apprenne à créer des objets éditoriaux que je puisse lier à des articles.
      Bien à vous
      Eric

    Reply to this message

  • 2

    Merci pour ce super plugin plus qu’indispensable !
    Je me demandais juste : pourquoi n’y a-t’il pas l’option “afficher_si” pour le champ de type “sélecteur de document” ? Est-ce que c’est possible de le rajouter ? J’en aurais vraiment besoin pour un projet.
    Merci !

    Reply to this message

  • 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

Add a comment

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 / PostgreSQL
  • 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 apparait.

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.

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