CFG : comment s’en passer !

CFG est un outil pour développeur de plugins qui permettait de créer des configurations de façon plus simple que d’ordinaire. L’évolution progressive de SPIP et l’arrivée de SPIP 3 font que ce plugin est, la plupart du temps, devenu inutile.

Nous expliquons dans cet article d’une part pourquoi, et d’autre part comment migrer un plugin pour qu’il ne dépende plus de CFG.

Pourquoi se passer de CFG

CFG a fait son temps et a bien servi. Voici un peu la chronologie des apports :

  • L’introduction dans SPIP 2.0 des formulaires CVT avait déjà permis de simplifier les formulaires [1].
  • Plus tard, le plugin SPIP Bonux à partir de sa version 2.2, intégrait un mécanisme pour émuler une partie du fonctionnement de CFG (les formulaires et les fonctions lire, ecrire et effacer_config), avec un code source plus simple.
  • Enfin, SPIP 3 intègre les apports de SPIP Bonux en ce qui concerne ses traitements de config, tout en permettant de traiter plus simplement la création de pages dans l’espace privé.

Tout cela cumulé fait que le plugin CFG n’aura plus d’intérêt en SPIP 3 et son ancien fonctionnement ne sera pas maintenu. Il existe une version de CFG pour SPIP 3 qui inclut simplement le mode de stockage ’PHP’ pour ceux qui l’utilisaient. Pour tout le reste, notamment les affichages, il faudra créer des pages de squelettes spécifiques et migrer les formulaires.

Comment se passer de CFG

Le principe est simple :

  • Si on a un site en SPIP 3 : il faut utiliser le fonctionnement natif de SPIP 3,
  • si on a un site en SPIP 2.1, utiliser le plugin SPIP Bonux qui permet une transition douce.

Fonctionnement de SPIP 3

Il faudra se rapporter à la documentation spécifique dès qu’elle sera disponible. Disons simplement quelques lignes.

Il y a au moins 3 possibilités pour appeler un formulaire de configuration dans SPIP 3

  1. une icône de configuration apparaît sur la page d’administration des plugins dès qu’un plugin possède une page prive/squelettes/contenu/configurer_XX.html où XX est le préfixe du plugin.
  2. la présence d’une ligne de menu dans le fichier paquet.xml peut afficher un lien dans le menu de SPIP 3, par exemple dans la partie « Configuration ». Cette ligne peut être : <menu nom="configurer_xxx" titre="xxx:configuration_xxx" parent="menu_configuration" icone="images/xxx-16.png" />, où xxx est le préfixe du plugin éventuellement.
  3. enfin, via l’utilisation de pipeline, on peut intégrer un formulaire donné dans une page quelconque, par exemple sur la page de « Configuration > fonctions avancées ».

Pour les points 1 et 2, il faut créer au moins la page qui affiche le formulaire, par exemple créer dans son plugin le squelette prive/squelettes/contenu/configurer_XX.html, qui contient ici, pour le plugin ’Compagnon’, l’appel de 2 formulaires :

[(#AUTORISER{configurer,compagnon}|sinon_interdire_acces)]
<h1 class="grostitre"><:compagnon:titre_page_configurer_compagnon:></h1>
<div class="ajax">
	#FORMULAIRE_CONFIGURER_COMPAGNON
</div>
<div class="ajax">
	#FORMULAIRE_REINITIALISER_COMPAGNON
</div>

Pour le 3e point, cela peut ressembler à l’exemple ci-dessous qui ajoute un formulaire (configurer_porte_plume) dans la page de configuration avancées :
-  paquet.xml

<pipeline nom="affiche_milieu" inclure="porte_plume_pipelines.php" />

-  dans porte_plume_pipelines.php

function porte_plume_affiche_milieu($flux){
	if ($flux['args']['exec'] == 'configurer_avancees')
		$flux['data'] .= recuperer_fond('prive/squelettes/inclure/configurer', array('configurer' => 'configurer_porte_plume'));
	return $flux;
}

Il ne reste plus qu’à créer les formulaires souhaités, soit en construisant un formulaire CVT traditionnel et en créant à coté les fonctions charger(), vérifier() et traiter() correspondantes, soit en ne créant qu’une partie ou aucune de ces fonctions. À ce moment là, le formulaire se comporte comme faisait CFG en analysant le code HTML pour déterminer les champs nécessaires, et en gérant l’enregistrement.

Attention : il est nécessaire pour cela que le nom du formulaire commence par « configurer_ », comme formulaires/configurer_compagnon.html

Au code HTML du formulaire, il est possible d’ajouter quelques champs cachés pour modifier le comportement de stockage automatique, par exemple le champ _meta_casier indique à quel endroit stocker (dans spip_meta) nos données. Par défaut, c’est le nom du formulaire (sans « configurer_ »), ce qui dans notre exemple donnerait le nom « compagnon ».

Voici dessous un exemple qui propose de stocker non pas dans « compagnon » mais dans compagnon/config :

<div class="formulaire_spip formulaire_configurer formulaire_#FORM">
	
<h3 class="titrem"><:compagnon:titre_compagnon:></h3>

[<p class="reponse_formulaire reponse_formulaire_ok">(#ENV*{message_ok})</p>]
[<p class="reponse_formulaire reponse_formulaire_erreur">(#ENV*{message_erreur})</p>]
<form method="post" action="#ENV{action}">
<div>
#ACTION_FORMULAIRE{#ENV{action}}

<ul>
	#SET{name,activer}#SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}}
	<li class="editer editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]">
		<label for="#GET{name}"><:compagnon:label_activer_compagnon:></label>
		<div class="explication"><:compagnon:explication_activer_compagnon:></div>
		[<span class='erreur_message'>(#GET{erreurs})</span>
		]<div class="choix">
			<input type="radio" name="#GET{name}" id="#GET{name}_oui" value="oui"
			[(#ENV{#GET{name}}|=={non}|non)checked="checked"] /><label for="#GET{name}_oui"><:item_oui:></label>
		</div>
		<div class="choix">
			<input type="radio" name="#GET{name}" id="#GET{name}_non" value="non"
			[(#ENV{#GET{name}}|=={non}|oui)checked="checked"] /><label for="#GET{name}_non"><:item_non:></label>
		</div>
	</li>	
</ul>

<input type="hidden" name="_meta_casier" value="compagnon/config" />
<p class='boutons'><span class='image_loading'>&nbsp;</span><input type='submit' class='submit' value='<:bouton_enregistrer:>' /></p>

</div>
</form>
</div>

Vous pouvez décider d’utiliser le plugin « Saisies » pour simplifier encore l’écriture de formulaire. Par exemple, le formulaire précédent, peut s’écrire avec des balises #SAISIE :

<div class="formulaire_spip formulaire_configurer formulaire_#FORM">
	
<h3 class="titrem"><:compagnon:titre_compagnon:></h3>

[<p class="reponse_formulaire reponse_formulaire_ok">(#ENV*{message_ok})</p>]
[<p class="reponse_formulaire reponse_formulaire_erreur">(#ENV*{message_erreur})</p>]
<form method="post" action="#ENV{action}">
<div>
#ACTION_FORMULAIRE{#ENV{action}}

<ul>
	[(#SAISIE{radio,activer,
		label=<:compagnon:label_activer_compagnon:>,
		explication=<:compagnon:explication_activer_compagnon:>,
		datas=[(#ARRAY{
			oui,<:item_oui:>,
			non,<:item_non:>})]})]
</ul>

<input type="hidden" name="_meta_casier" value="compagnon/config" />
<p class='boutons'><span class='image_loading'>&nbsp;</span><input type='submit' class='submit' value='<:bouton_enregistrer:>' /></p>

</div>
</form>
</div>

Une fois les formulaires mis en place, l’utilisation des valeurs se fait comme avant avec CFG. On peut utiliser #CONFIG{compagnon/config/activer} dans un squelette, ou les fonctions lire_config('compagnon/config/activer'), ecrire_config('compagnon/config/activer', 'oui') ou effacer_config('compagnon/config/activer') en PHP à partir du moment où on a inclus au moins une fois la librairie inc/config :

include_spip('inc/config');
$actif = lire_config('compagnon/config/activer');

Migrer avant SPIP 3, sur un SPIP 2.1

Le jeu consiste à s’approcher le plus possible du fonctionnement de SPIP 3.

Pour les très vieux CFG qui n’ont que le répertoire fonds/ il faut déjà le séparer en deux en déplaçant la partie formulaire dans formulaires/configurer_xx.html et en le recodant si possible avec la même syntaxe HTML que ce que propose SPIP [2]

Ensuite, il faut recoder ce formulaire pour qu’il fonctionne avec SPIP-Bonux, ce qui consiste à supprimer tous les paramètres d’en-tête du fichier CFG [(#REM) nom=valeur ] ou <!-- nom=valeur --> par leurs équivalents en input hidden s’ils existent.

De la sorte

<!-- nom=valeur -->
<!-- casier=chemin/par_la -->

Sera remplacé, dans le formulaire (à l’intérieur de <form>) par :

<input type="hidden" name="_meta_casier" value="valeur/chemin/par_la" />

Enfin, il faut déplacer l’appel du formulaire, placé dans fonds/ pour le mettre dans une page prive/exec/configurer_XX.html.

L’emplacement de cette page est la seule différence par rapport à SPIP 3 (qui est lui, dans prive/squelettes/contenu/configurer_XX.html).

Notes sur les stockages supplémentaires

En SPIP 3, lorsque les stockages sont différents de « meta » ou « metapack », ils nécessitent le plugin CFG pour SPIP 3, mais seul le stockage « php » a été recodé pour l’instant.

Stockage PHP
Si le stockage se faisait en php (le casier est identique) :

<input type="hidden" name="_meta_stockage" value="php" />
<input type="hidden" name="_meta_table" value="" />

S’il y avait un fichier spécifique de déclaré, le mettre dans le casier :

<input type="hidden" name="_meta_casier" value="adresse/fichier.php:nom/casier/champ" />

Autres stockages (table, tablepack)
Ils ne sont actuellement pas pris en compte par le plugin CFG pour SPIP 3.
Si quelqu’un veut les recoder, qu’il se lance :)

Discussion

5 discussions

  • 1

    Merci Marcimat pour cet article.

    Un détail pour les icones :

    <menu nom="configurer_xxx" titre="xxx:configuration_xxx" parent="menu_configuration" icone="images/xxx-16.png" />

    le chemin réel de l’image est dans prive/themes/spip/images/

    Et du coup, dans paquet.xml, on a tout intérêt à placer le logo dans ce même dossier :
    logo="prive/themes/spip/images/xxx-32.png"

    • La classe grostitre n’est plus efficace, voir même contre productive sur les version récente de spip.

      Marcimat, tu me confirme cela ?

    Répondre à ce message

  • Bonjour,

    Je suis confronté à un cas similaire, mais j’aurais cependant une remarque/question.

    Dans l’exemple présenté sur cet article,
    En SPIP 3, ne serait-il pas préférable de déplacer les formulaires du type de « configurer_compagnon » et « reinitialiser_compagnon » dans le répertoire prive/formulaires/  ?

    Par ailleurs, après l’avoir tester on se rend compte que les formulaires sont alors pas inclus dans la page contenu/configurer_xxx.html.

    Je ne trouve pas suffisamment d’informations sur ce répertoire.

    Par avance, merci pour votre réponse.

    Répondre à ce message

  • Bonjour,

    Dans CFG on pouvait utiliser #CFG_CHEMIN conjointement a un champ de formulaire input type file, y’a t’il une correspondance ou un équivalent sous Spip3 ?

    merci de votre réponse

    Répondre à ce message

  • Hello Marcimat

    Typiquement, sans cfg, si on ne définit pas de fonction traiter pour un formulaire de configuration de plugin, c’est Bonux (ou Spip3) qui gère tout seul l’enregistrement des paramètres.

    Dans le cas où, par exemple, je voudrais invalider le cache si le formulaire est valide, de dois créer une fonction traiter, ajouter l’invalidation et gérer moi même l’enregistrement des paramètres. Mais est-il possible de juste ajouter l’invalidation et appeler la fonction de traitement classique ? Je ne trouve pas comment :-(

    Répondre à ce message

  • J’aimerai faire sorte d’adapter le nivoslider trouvé sur votre site pour ne pas as avoir à installer CFG, en utilisant bonux, sauf que je n’y arrive pas, je ne comprend pas ce que je dois ajouter/retirer et ou les placer afin qu’il fonctionne...
    Un coup de main serait bienvenu et un exemple plus concret serait appréciable.
    J’utilise SPIP 2.1.xx

    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