Plugin stockant sa configuration dans la table spip_meta
Une majorité de plugins stocke leur configuration dans la table spip_meta (notamment la plupart des plugins utilisant CFG). Pour ces derniers, la déclaration des métas à sauvegarder est relativement simple via le pipeline ieconfig_metas.
L’importeur/exporteur de configurations générera alors un formulaire d’import/export simplifié (exporter : oui / non, importer : oui / non).
Il faut tout d’abord déclarer le pipeline ieconfig_metas dans le plugin.xml du plugin :
- <pipeline>
- <nom>ieconfig_metas</nom>
- <inclure>prefixe_plugin_ieconfig_metas.php</inclure>
- </pipeline>
puis créer un fichier prefixe_plugin_ieconfig_metas.php contenant :
- <?php
- function prefixe_plugin_ieconfig_metas($table){
- $table['prefixe_plugin']['titre'] = nom_du_plugin;
- $table['prefixe_plugin']['icone'] = 'chemin/image.png';
- $table['prefixe_plugin']['metas_brutes'] = 'meta1,meta2,meta3';
- $table['prefixe_plugin']['metas_serialize'] = 'meta4,meta5,meta6';
- return $table;
- }
- ?>
metas_brutes permet d’indiquer les metas dont on fera l’export tel quel, tandis que metas_serialize permet d’indiquer des metas qui sont stockées sous forme serializées (ce qui est notamment le cas avec CFG dans usage courant).
S’il y a plusieurs metas à sauver, il faut séparer leur nom par une virgule (ne pas ajouter d’espace).
Exemples concrets :
Pour le plugin Métas :
- function metas_ieconfig_metas($table){
- $table['metas']['titre'] = _T('metas:configuration_metas');
- $table['metas']['icone'] = 'images/metas-24.png';
- $table['metas']['metas_brutes'] = 'spip_metas_title,spip_metas_description,spip_metas_keywords,spip_metas_mots_importants';
- return $table;
- }
Pour le plugin Dublin Core (qui utilise CFG) :
- function dublin_core_ieconfig_metas($table){
- $table['dublin_core']['titre'] = _T('dublin_core:dublin_core');
- $table['dublin_core']['icone'] = 'images/dublin_core-24.png';
- $table['dublin_core']['metas_serialize'] = 'dublin_core';
- return $table;
- }
Si l’on a besoin de formulaires d’import/export et/ou de traitements plus évolués, il faut passer par un autre pipeline, le pipeline ieconfig.
Le pipeline ieconfig pour des exports/imports entièrement personnalisables
Pour qu’un plugin puisse exporter/importer sa configuration avec l’importeur/exporteur de configurations, il doit se brancher sur le pipeline iecfg.
Ce pipeline est appelé 4 fois :
- pour construire le formulaire d’export
- pour construire le tableau de configuration à exporter
- pour construire le formulaire d’import
- pour stocker la configuration importée en base
Pour un exemple de code, voir http://svn.spip.org/trac/spip-zone/... ou encore http://zone.spip.org/trac/spip-zone....
Construction du formulaire d’export
Pour construire le formulaire d’export, le pipeline ieconfig est appelé en transmettant en argument $flux['args']['action']='form_export'.
$flux['args']['data'] contient un tableau de saisies (voir Saisies) . On ajoutera dès lors à ce tableau les options de saisies propres au plugin. Elles seront réunies dans un fieldset dont le nom sera le préfixe du plugin. Les noms des options de saisies commenceront toutes par prefix_ pour éviter les interférences avec d’autres plugins.
Au minimum, le plugin devra proposer d’exporter ou de ne pas exporter sa configuration.
Il est possible de préciser des critères de vérifications aux saisies (voir Doc Saisies complémentaire).
Tableau à exporter
Pour construire le tableau d’export, le pipeline ieconfig est appelé en transmettant en argument $flux['args']['action']='export'.
Les paramètres d’export saisis par l’utilisateur sont accessibles via la fonction _request().
$flux['args']['data'] contient le tableau des données à exporter. Le plugin rajoutera une entrée à ce tableau, avec pour clé le préfixe du plugin, contenant la configuration à exporter.
Construction du formulaire d’import
Pour construire le formulaire d’export, le pipeline ieconfig en transmettant en argument $flux['args']['action']='form_import'. $flux['args']['action']='config' contient le tableau à importer.
$flux['args']['data'] contient un tableau de saisies (voir Saisies) . On ajoutera dès lors à ce tableau les options de saisies propres au plugin, si le tableau à importer contient une configuration à importer pour ce plugin (entrée ayant comme clé le préfixe du plugin). Elles seront réunies dans un fieldset dont le nom sera le préfixe du plugin. Les noms des options de saisies commenceront toutes par prefix_ pour éviter les interférences avec d’autres plugins.
Au minimum, le plugin devra proposer d’importer ou de ne pas importer la configuration le concernant.
Il est possible de préciser des critères de vérifications aux saisies (voir Doc Saisies complémentaire).
Import de la configuration
Pour importer la configuration, le pipeline ieconfig est appelé en transmettant en argument $flux['args']['action']='import'. $flux['args']['action']='config' contient le tableau à importer.
Les paramètres d’import saisis par l’utilisateur sont accessibles via la fonction _request().
$flux['args']['data'] contient un message d’erreur à afficher si un problème est rencontré. Il sera complété par le plugin si une erreur a été rencontrée lors de l’import.
Fournir des fichiers de configuration dans un plugin
Un plugin, notamment un plugin de squelette, dépendant de plusieurs autres plugins peut fournir un ou plusieurs fichiers de configuration. Cela permet notamment pour un squelette de fournir plusieurs configurations de départ/
Pour cela, il suffit de placer les fichiers YAML de configuration dans un sous-répertoire ieconfig/.
On peut également indiquer que ce fichier de configuration ne doit être proposé par l’importeur/exporteur de plugin que si certains plugins sont actifs en ajoutant dans le yaml du fichier de configuration :
Vos commentaires
# Le 30 janvier 2011 à 08:30, par Déesse A.
En réponse à : Importeur / Exporteur de configurations : documentation développeur
Joli travail Joseph, mais la longueur de ce que tu as dû développer me conforte dans l’idée que le problème de fond est que CFG est fondamentalement perdant en utilisant la table standard des metas pour y fourrer pêle-mêle tous les paramètres de configuration de tous les plugins. Avec la balise#CONFIGURER_METAS que j’ai proposée, on stocke ces paramètres dans une table SQL séparée qu’il suffit de sauver comme n’importe quelle table. Je serais curieux de voir combien de ligne de code il te suffirait d’écrire pour prendre en compte ce cas là (repérable par l’existence dans plugin.xml de la balise XML « meta ») dans ce que tu as fait : juste une bouton radio à cocher il me semble.
# Le 30 janvier 2011 à 14:27, par Joseph
En réponse à : Importeur / Exporteur de configurations : documentation développeur
Le but de l’importeur/exporteur de config est d’être indépendant du système de configuration utilisé par chaque plugin et de ne pas être limitatif.
Il reste qu’il a toujours besoin qu’on lui dise ce qu’il doit exporter / importer et de quelle manière. Il lui faut également pour la présentation une icône et une chaîne de langue au minimum.
Il est à noter que le pipeline
ieconfig_metatsne fait aucune hypothèse sur la manière dont est alimentée la tablespip_meta(via CFG ou autre mécanisme).Il n’y a pas encore de mécanisme pour déclarer simplement que ce qu’on doit exporter est le contenu d’une table spécifique mais effectivement ca ne devrait pas être très long de faire un pipeline
ieconfig_tablepour spécifier que ce qu’on exporte est une table spécifique.L’intérêt du pipeline
ieconfig, certes un peu complexe, c’est qu’il est possible de faire des imports/exports plus complexes.Cela est pour le moment utilisé par exemple par Menus et noiZetier. Pour Menus on peut choisir ainsi quels menus exporter (les infos des menus étant stockés dans deux tables) et à l’import de choisir lesquels importer et, en cas de conflit avec un menu déjà existant, de renommer à la volée le menu à importer ou bien de remplacer le menu existant.
Idem pour le noiZetier où l’import/export est lui aussi plus complexe. D’ailleurs l’import de noisettes pour le noiZetier passe en plus par un autre pipeline propre au noiZetier. Ce pipeline est utilisé par le garde-noisettes (qui possède son propre version_base) pour mettre à jour les paramètres des noisettes à la volée si jamais la config de noisettes importées correspond à une version précédente des noisettes.
Quoiqu’il en soit, il est toujours possible de faire évoluer ieconfig en lui ajoutant des mécanismes génériques pour les méthodes les plus courantes de stockage des paramètres, tant qu’on laisse la souplesse de faire des import/export plus spécifiques pour les plugins qui le nécessitent.
Répondre à ce message