cfg : références

Explications détaillées sur l’utilisation de CFG, le plugin de configuration.

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 :

<form method="post" action="#SELF"><div>[(#ENV{_cfg_}|form_hidden)]

<input type="text" name="mon_text" value="#ENV{mon_text}" />
<textarea name="mon_area">[(#ENV{mon_area})]</textarea>

<input type="submit" name="_cfg_ok" value="<:OK:>" />
<input type="submit" name="_cfg_delete" value="<:Supprimer:>" />
</div></form>

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.

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()

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

Discussion

24 discussions

  • 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

  • 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

  • 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 :

    [(#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 :

    [(#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

  • 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 :

    <label for="cfg_gm_latitude"><:fraikin:cfg_google_map_label_composition:></label>
    					<div class='explication'><:fraikin:cfg_google_map_explication_composition:></div>
    					<B_pour>
    						<BOUCLE_pour(POUR){tableau #ENV{_compositions}|table_valeur{rubrique}}>
    						<div class='choix'>[(#VALEUR|table_valeur{icon}|image_reduire{24,24}|inserer_attribut{class,logo})]
    						<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>
    						[<p class='descriptif'>(#VALEUR|table_valeur{description})</p>]
    						</div>
    						</BOUCLE_pour>
    					</B_pour>

    Code qui fonctionne :

    <input type="checkbox" name="cfg_gm_compositions[]"/>
    					<label for="cfg_gm_latitude"><:fraikin:cfg_google_map_label_composition:></label>
    					<div class='explication'><:fraikin:cfg_google_map_explication_composition:></div>
    					<B_pour>
    						<BOUCLE_pour(POUR){tableau #ENV{_compositions}|table_valeur{rubrique}}>
    						<div class='choix'>[(#VALEUR|table_valeur{icon}|image_reduire{24,24}|inserer_attribut{class,logo})]
    						<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>
    						[<p class='descriptif'>(#VALEUR|table_valeur{description})</p>]
    						</div>
    						</BOUCLE_pour>
    					</B_pour>

    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

  • 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

  • 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 :

    	/**
    	 * ajoute une erreur sur un champ donne
    	 * 
    	 * @param string $champ
    	 * @param string $message 
    	 */
    	function ajouter_erreur({{$champ}}, $message) {
    		$this->messages['erreurs'][{{$champs}}] = isset($this->messages['erreurs'][{{$champs}}]) 
    			? $this->messages['erreurs'][{{$champs}}] .= '<br />' . $message
    			: $message;
    	}

    Répondre à ce message

  • 1

    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

    • 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

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

    Répondre à ce message

  • 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

  • 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

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