SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 462 visiteurs en ce moment

Accueil > Outils pour plugins > Config (CFG) > cfg : références

cfg : références

19 mai 2007 – par support, toggg – 40 commentaires

Toutes les versions de cet article : [Español] [français] [italiano]

80 votes

CFG est un plugin pour SPIP qui facilite le paramétrage d’autres plugins ou squelettes en permettant de créer facilement des formulaires de configuration.

Cet article explique les bases de création de ces formulaires et l’utilisation des données issues de ceux-ci. Des liens sont proposés dans l’article découvrir les fonctions avancées de CFG.

Unique fichier de configuration

CFG a été motivé par le besoin récurrent de fabriquer des configurations de plugins ou squelettes.

Son leitmotiv est donc la simplicité. C’est pourquoi une configuration « quelque_chose » (un plugin, un squelette ou ce que l’on veut) est basée sur l’unique fichier fonds/cfg_quelque_chose.html [1].

Ce « fond » contient un formulaire et des propriétés/options qui sont transmises à CFG.

La modification des données (par un administrateur du site) se fait par simple appel de l’action CFG comme
ecrire/?exec=cfg&cfg=quelque_chosequelque_chose correspond au nom du fichier fonds/cfg_quelque_chose.html.

Le formulaire

Il s’agit d’un formulaire HTML standard, interprété comme un squelette. Les données gérées sont reconnues d’après l’attribut « name » des balises de formulaire comme

  • <input type="text" name="truc"...>,
  • <select name="truc"...>,
  • <textarea name="truc" ...>,
  • etc.

Notes sur le nomage des attributs « name »

  • Les noms commençant par _cfg_ sont réservés au fonctionnement interne.
  • Les noms commençant par id_ peuvent poser problème. [2]

Transmettre une action sécurisée
L’action du formulaire étant sécurisée, il faut lui adjoindre les données de contrôle, tout simplement en faisant suivre <form ...> par des « hidden » le plus simple étant :
<form method="post" action="#SELF">[(#ENV{_cfg_}|form_hidden)]

Boutons d’envoi et de suppression
Enfin, les submit de validation ou de suppression doivent être nommés respectivement _cfg_ok ou _cfg_delete (noms réservés)

Formulaire minimal

Un formulaire minimal serait donc :

Comme on peut le voir, les valeurs des données sont récupérables par #ENV{truc}

Important : La méthode d’analyse des formulaires de CFG implique de respecter l’ordre suivant (type puis name, puis les éventuelles class css, puis le reste) dans les balises utilisées (textearea, select, input...).
<input type=... name=... class=... .../>
<textearea/select name=... class=... .../>

Les propriétés de l’objet cfg

Il est possible en plaçant des remarques au format html commençant par propriete= de spécifier des propriétés intrinsèques de l’objet CFG qui manipulera le formulaire.

Par exemple, on peut ainsi définir le titre du formulaire (notez l’espace après <!-- et le = collé au nom du paramètre) :
<!-- titre=Le titre du formulaire -->

Il est possible alors de jouer avec les balises SPIP et les fichiers de langue :
<!-- descriptif=<multi>[fr]Descriptif français [en]In english</multi>-->
<!-- descriptif=<:prefixe_plugin:description_plugin:>-->
Ici, le descriptif sera complètement interprété, comme un squelette ... y compris boucles et toute la machine de guerre SPIP.

Propriété Description
titre Un des 2 titres, fera le gros titre si boite est aussi présent
boite Le titre de la boite formulaire, défaut titre si présent, ’Configuration machin" sinon
descriptif Le descriptif affiché en haut de colonne gauche
nom Le nom du meta où sera stockée la configuration, par défaut c’est le nom du formulaire, xxx dans fonds/cfg_xxx

Il existe d’autres propriétés avancées que vous pouvez trouver dans l’article API CFG : Paramètres des formulaires

Utilisation des données

Les données stockées sont sérialisées sous le nom « quelque_chose » dans la table spip_meta.

On les récupère dans les squelettes avec la balise #CONFIG qui est étendue par cfg pour extraire les subdivisions avec le séparateur /
Par exemple #CONFIG{quelque_chose/mon_area} donnera la valeur du champs mon_area produite par le formulaire fonds/cfg_quelque_chose.html

Depuis le php, on peut utiliser similairement lire_config('quelque_chose/mon_area')

#CONFIG{} ou lire_config() admettent comme deuxième paramètre la valeur à retourner par défaut. Par exemple #CONFIG{quelque_chose/mon_area,defaut area} donnera defaut area si quelque_chose ou mon_area sont vides.

P.-S.

Evidemment, toute contribution est la bienvenue, vous pouvez facilement demander à devenir co-rédacteur.

Notes

[1Le « fond » CFG utilisé sera le premier trouvé dans l’ordre des priorités de SPIP... En priorité dans le répertoire squelettes/, puis dans un des plugins actifs, puis dans dist/, puis dans ecrire/

[2Les variables postées commençant par « id_ » vont s’inscrire dans la la chaine produite par la balise #SELF (comportement standart de SPIP). Si #SELF est utilisée dans le formulaire CFG par <form method="post" action="#SELF">, c’est sa valeur qui sera prise en compte par SPIP lors de l’envoi du formulaire, et non la nouvelle valeur choisie par l’utilisateur (en fait, 2 variables sont envoyées : une en GET (avec l’action="#SELF" et une en POST (le champ du formulaire) de même nom, et SPIP prend prioritairement GET lorsque l’on demande une variable avec sa fonction _request()

Dernière modification de cette page le 3 août 2009

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 23 janvier 2012 à 12:20, par Fann En réponse à : cfg : références

    Bonjour
    J’ai téléchargé le plugin car il m’était demandé pour pouvoir utiliser d’autres plugins, mais j’avoue que je comprends pas comment je peux le modifier, et si ça se fait pas l’espace privé ou un autre logiciel, quelqu’un peut-il m’aider ?

    Répondre à ce message

  • Le 4 novembre 2011 à 22:54, par CM En réponse à : cfg : références

    Voilà un moment que je galérais : dans mon formulaire de configuration, CFG refusait de prendre en compte les champs INPUT alors qu’il acceptait les autres. J’ai enfin trouvé pourquoi : les valeurs des attributs type et name étaient entre ’apostrophes’ et pas entre « guillemets » (par facilité, ces champs étant créés par PHP). Debug difficile car HTTP accepte les 2 syntaxes et les variables étaient bien envoyées par POST.

    Je trouve que cela mériterait d’être précisé sur cette page, par exemple dans le « formulaire minimal ». Et aussi dans le tutorial « coder un plugin simple ».

    Merci d’avance aux auteurs.
    CM

    Répondre à ce message

  • Le 4 novembre 2011 à 16:17, par Jean-Baptiste Pressac En réponse à : cfg : références

    Bonjour,
    J’utilise Saisies pour réaliser un formulaire de configuration de squelettes avec CFG qui s’avère très pratique. J’ai juste rencontré une difficulté pour récupérer la valeur des saisies de type selecteur_rubrique qui permet de choisir une rubrique.

    Rastapopoulos m’a donné une solution sur le forum de Saisie qui m’amène à la proposition suivante :

    De la même façon qu’il est possible de récupérer très facilement dans un squelette la valeur d’un champ d’un formulaire CFG par la balise [(#CONFIG{prefixe_plugin/label_champ})], serait-il possible de rendre possible la récupération de l’identifiant des rubriques / articles des saisies de type selecteur_rubrique, selecteur_article, selecteur_rubrique_article sans avoir à utiliser des filtres :

    1. [(#CONFIG{prefixe_plugin/label_champ}|picker_selected{rubrique}|table_valeur{0})]

    Cela permettrait également de saisir la valeur par défaut de #CONFIG de manière plus intuitive pour ce type de saisies. En effet, pour l’instant, celle-ci doit être de la forme article|2 ou rubrique|3 où 2 et 3 sont les identifiants de l’article et de la rubrique. Par exemple :

    1. [(#CONFIG{prefixe_plugin/label_champ, rubrique|3}|picker_selected{rubrique}|table_valeur{0})]

    Pour info, c’est Bonux qui fournit le code d’affichage de ces types de saisies (dans plugins/spip-bonux/formulaires/selecteur/), ainsi que le filtre picker_selected.

    En tout cas, merci pour ces plugins forts utiles.

    Répondre à ce message

  • Le 7 juin 2011 à 11:53, par fish En réponse à : cfg : références

    Bonjour,

    Je travailles actuellement sur un formulaire CFG pour l’administration d’un plugin s’appuyant aussi sur le plugin Composition mais je me heurte au problème suivant :

    Je construis une liste de checkbox dynamique à partir d’une boucle sur les compositions des rubriques. Mais je n’arrive pas à enregistrer les éléments cochés tant que je n’ai pas mis hors de ma boucle un champ checkbox avec le même nom.

    Code qui fonctionne pas :

    1. <label for="cfg_gm_latitude"><:fraikin:cfg_google_map_label_composition:></label>
    2. <div class='explication'><:fraikin:cfg_google_map_explication_composition:></div>
    3. <B_pour>
    4. <BOUCLE_pour(POUR){tableau #ENV{_compositions}|table_valeur{rubrique}}>
    5. <div class='choix'>[(#VALEUR|table_valeur{icon}|image_reduire{24,24}|inserer_attribut{class,logo})]
    6. <input type="checkbox" name="cfg_gm_compositions[]" value="#CLE" id="cfg_gm_compositions-#CLE" class="checkbox" [(#CLE|=={#ENV{selected}}|oui)checked="checked"] /><label for='cfg_gm_compositions-#CLE'>[(#VALEUR|table_valeur{nom})][(#ENV{composition_heritee}|et{#CLE|=={''}}|oui)(<:compositions:composition_heritee:>)]</label>
    7. [<p class='descriptif'>(#VALEUR|table_valeur{description})</p>]
    8. </div>
    9. </BOUCLE_pour>
    10. </B_pour>

    Télécharger

    Code qui fonctionne :

    1. <input type="checkbox" name="cfg_gm_compositions[]"/>
    2. <label for="cfg_gm_latitude"><:fraikin:cfg_google_map_label_composition:></label>
    3. <div class='explication'><:fraikin:cfg_google_map_explication_composition:></div>
    4. <B_pour>
    5. <BOUCLE_pour(POUR){tableau #ENV{_compositions}|table_valeur{rubrique}}>
    6. <div class='choix'>[(#VALEUR|table_valeur{icon}|image_reduire{24,24}|inserer_attribut{class,logo})]
    7. <input type="checkbox" name="cfg_gm_compositions[]" value="#CLE" id="cfg_gm_compositions-#CLE" class="checkbox" [(#CLE|=={#ENV{selected}}|oui)checked="checked"] /><label for='cfg_gm_compositions-#CLE'>[(#VALEUR|table_valeur{nom})][(#ENV{composition_heritee}|et{#CLE|=={''}}|oui)(<:compositions:composition_heritee:>)]</label>
    8. [<p class='descriptif'>(#VALEUR|table_valeur{description})</p>]
    9. </div>
    10. </BOUCLE_pour>
    11. </B_pour>

    Télécharger

    J’ai vérifié la variable $cfg dans la fonction charger et effectivement si je n’ajoutes pas une checkbox hors de ma boucle le champ cfg_gm_compositions n’est pas présent dans $cfg->champ => impossible de faire un enregistrement.

    Quelqu’un a-t-il déjà été confronté à ce problème ? Si oui avez-vous une solution de contournement ?

    Merci beaucoup,

    Répondre à ce message

  • Le 8 mai 2011 à 23:55, par alain bourdeau En réponse à : cfg : références

    Bonjour,

    La mise à jour de cfg n’est pas toujours bien faite.

    Sur un site actuellement sous spip 2.1.10 17657, le pluging cfg 1.15.0 38187 ne s’actualisait pas dans le répertoire /plugin/auto/cfg. Dans le répertoire /lib/cfg la version était bien 1.16 38776.

    Celà perturbait le plugin menus. En remplaçant par ftp directement la directorie /plugins/auto/cfg par un contenus (1.16 43371) provenant d’un site neuf, plus de problème.

    J’avais eu également un gros problème avec cet ancien cfg qui bloquait l’exploration de googleboot et donc je n’avais plus de référencement google.

    Voilà pour la communauté spip. Amicalement Alain

    Répondre à ce message

  • Le 20 avril 2011 à 12:36, par fish En réponse à : cfg : références

    Bonjour,

    Après quelques tests , il apparait qu’il y a une erreur dans la méthode ajouter_erreur($champ, $message) , en effet si on regarde les sources on utilise la variable $champs et $champ pour placer le message d’erreur.

    Résultat le message d’erreur est ajouter avec la chaîne vide.

    Il faudrait donc corriger dans la prochaine release.

    Là ou ça coince :

    1. /**
    2. * ajoute une erreur sur un champ donne
    3. *
    4. * @param string $champ
    5. * @param string $message
    6. */
    7. function ajouter_erreur({{$champ}}, $message) {
    8. $this->messages['erreurs'][{{$champs}}] = isset($this->messages['erreurs'][{{$champs}}])
    9. ? $this->messages['erreurs'][{{$champs}}] .= '<br />' . $message
    10. : $message;
    11. }

    Télécharger

    Répondre à ce message

  • Le 20 mars 2011 à 16:27, par ocarette En réponse à : cfg : références

    Bonjour,
    J’essaie d’utiliser CFG pour pouvoir configurer un plugin qui s’appelle SpiDoli (prefix=spidoli).

    Voici ce que me transmet CFG depuis que j’ai enregistre une donnée dans un champs appelé adresse_doli :

    Aucun champ trouvé dans spidoli

    De plus il n’est plus possible de modifier les configurations.
    Quelqu’un peut-il me donner des informations pour que je puisse réaliser mon système de configuration.

    Olivier

    • Le 20 mars 2011 à 16:30, par ocarette En réponse à : cfg : références

      Je me répond immédiatement :
      J’avais inclus un size=« 80 » entre type et name. Ceci a bloqué le système.
      En le mettant à la fin, je n’ai pas de problème.
      Olivier

    Répondre à ce message

  • Le 23 janvier 2010 à 15:42, par ? En réponse à : cfg : références

    Comment faire pour utiliser le fichier php appelé avec des fonctions propres à SPIP ?

    Répondre à ce message

  • Le 23 janvier 2010 à 11:51, par ? En réponse à : cfg : références

    Comment faire si le fichier de traitement php que l’on envoie au form se trouve dans le même dossier que le fichier html ?

    Comment faire pour rediriger vers une même page html mais qui est appelé après traitement php et n’est pas la page html, tout en gardant le squelette de cfg ??

    Répondre à ce message

  • Le 30 novembre 2009 à 14:36, par Balou En réponse à : CFG

    Bonjour,

    j’utilise SPIP 1.9.2i sur notre site : http://latoniccia.free.fr

    J’ai un PB avec le plugin CFG qui affiche cette erreur :

    Warning : in_array() [function.in-array] : Wrong datatype for second argument in /mnt/165/sda/7/d/latoniccia/ecrire/public/composer.php(48) : eval()’d code on line 100

    Warning : in_array() [function.in-array] : Wrong datatype for second argument in /mnt/165/sda/7/d/latoniccia/ecrire/public/composer.php(48) : eval()’d code on line 100

    Warning : in_array() [function.in-array] : Wrong datatype for second argument in /mnt/165/sda/7/d/latoniccia/ecrire/public/composer.php(48) : eval()’d code on line 100

    Warning : in_array() [function.in-array] : Wrong datatype for second argument in /mnt/165/sda/7/d/latoniccia/ecrire/public/composer.php(48) : eval()’d code on line 100

    Warning : in_array() [function.in-array] : Wrong datatype for second argument in /mnt/165/sda/7/d/latoniccia/ecrire/public/composer.php(48) : eval()’d code on line 100

    Warning : in_array() [function.in-array] : Wrong datatype for second argument in /mnt/165/sda/7/d/latoniccia/ecrire/public/composer.php(48) : eval()’d code on line 100

    J’utilise la dernière version de CFG.

    Dans l’attente d’une explication !

    Merci d’avance

    Répondre à ce message

Répondre à cet article

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 Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • GIS 4

    11 août 2012 – 1170 commentaires

    Présentation et nouveautés La version 4 de GIS abandonne la libraire Mapstraction au profit de Leaflet. Cette librairie permet de s’affranchir des librairies propriétaires tout en gardant les mêmes fonctionnalités, elle propose même de nouvelles (...)

  • Mailshot

    16 janvier 2013 – 232 commentaires

    Ce plugin prend en charge l’envoi en nombre d’info-lettres par email. Mailshot permet l’envoi en nombre d’emails au moyen d’un SMTP (ou d’un service externe) dédié à cet effet. Il permet de limiter la cadence d’envoi. Enfin, ce plugin implémente la (...)

  • Rainette v1, la méteo au quotidien

    31 juillet 2009 – 193 commentaires

    Ce plugin permet d’afficher les conditions et les prévisions météorologiques d’une ville donnée à partir du flux xml fourni par le site weather.com(r).

  • Simple Calendrier v2

    25 février – commentaires

    Il s’agit de la version pour SPIP 3 du plugin Simple Calendrier. Le plugin « simple calendrier » permet de gérer des évènements en ajoutant un nouvel objet éditorial dans l’administration de votre site SPIP. Il peut constituer une alternative au plugin (...)

  • Article PDF

    9 juin 2007 – 333 commentaires

    Présentation d’un plugin fournissant une version PDF de l’article en cours