Carnet Wiki

CFG dans spip core

Version 1 — Février 2011 JLuc

ref : Mathieu, Rastapopoulos dans http://permalink.gmane.org/gmane.comp.web.spip.zone/22402

Nouveau ! CFG Intégré à SPIP-CORE

Un système de formulaire de configuration, nécessitant uniquement de donner un squelette de formulaire est déjà intégré dans la version « dev » (spip >2.1).

C’est le même que dans le plugin Bonux, donc en l’utilisant, il n’y a plus aucun besoin de CFG.

Pour une migration en douceur de avec CFG / sans CFG + spip dev (stable + bonux) :
-  dans fonds/cfg_xx.html, simplement appeler #FORMULAIRE_CONFIGURER_XX
-  dans formulaires/configurer_xx.html, mettre ces propriétés CFG habituelles.
-  utiliser nom et casier, mais pas de stockage différent de meta ou metapack (en gros) : stockage php et table n’est actuellement pas supporté par bonux. Par contre il supporte une table spip_xx_meta au besoin.

Exemples d’utilisation : porte_plume
-  http://zone.spip.org/trac/spip-zone/browser/_plugins_/porte_plume_extras/codes/fonds/cfg_porte_plume_codes.html :

<!-- titre=<:pp_codes:pp_codes:> -->
<!-- descriptif=<:pp_codes:cfg_description_pp_codes:> -->
<!-- icone=images/porte_plume_codes-22.png -->
<!-- logo=images/porte_plume_codes-128.png -->
<div class="ajax">#FORMULAIRE_CONFIG_PORTE_PLUME_CODES</div>

-  http://zone.spip.org/trac/spip-zone/browser/_plugins_/porte_plume_extras/codes/formulaires/config_porte_plume_codes.html (mais renommé en « configurer_porte_plume_codes »)

<!-- autoriser=configurer -->
<!-- refus=<:cfg:refus_configuration_configurer:> -->
<!-- nom=porte_plume -->
<!-- casier=codes -->

<div class="formulaire_spip formulaire_[(#ENV{form})]">
	
[<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>
	<li class="fieldset">

		<fieldset>
			<h3 class="legend"><:pp_codes:cfg_activer_extension_sur:></h3>
			<ul>
				[(#SAISIE{oui_non,activer_barre_edition,
					label=<:pp_codes:cfg_activer_barre_edition:>,
					defaut=on})]
					
				[(#SAISIE{oui_non,activer_barre_forum,
					label=<:pp_codes:cfg_activer_barre_forum:>})]
			</ul>
		</fieldset>
	</li>
</ul>

<p class="boutons">
	<input type="submit" name="_cfg_ok" value="<:cfg:ok:>" class="submit" />
	<input type="reset" value="<:reset:>" class="reset" />
</p>
</div>
</form>
</div>

Limites
Ce que ne fait pas Bonux (ou spip-dev) par rapport à CFG, c’est lister les pages présentes dans fonds/ . Pour passer (pour l’instant) de CFG à Bonux, il faut en plus :
-  supprimer fonds/cfg_xx.html
-  ajouter un pipeline sur une des pages de configuration pour insérer le formulaire.

Exemple avec porte_plume :
-  dans le plugin.xml de porte_plume on trouve :

<!-- Pour formulaire de configuration -->
<pipeline>
   <nom>affiche_milieu</nom>
   <inclure>porte_plume_pipelines.php</inclure>
</pipeline>


-  dans porte_plume_pipelines.php on trouve :

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;
}

Alternatives

-  plugin CFG traditionnel utilisé par un grand nombre de plugins
-  balise #CONFIGURER_METAS définie et utilisée par ESJ pour plusieurs plugins
-  plugin BONUX