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
- 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. - 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. - 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'> </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'> </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 :)
Discussions par date d’activité
5 discussions
Merci Marcimat pour cet article.
Un détail pour les icones :
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 :
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.
Suivre les commentaires : |