Le mécanisme de configuration actuel

Nombre de plugins utilisent des variables de configuration pour paramétrer les traitements qu’ils proposent. Initialement motorisé par le « très utilisé » plugin CFG, le mécanisme de configuration est maintenant proposé nativement par le noyau de SPIP 3.0 ce qui entraine l’abandon progressif de CFG.

Le mécanisme de configuration de SPIP 3.0 est basé principalement, comme l’explique l’article Configurer une fonctionnalité de votre site, ou un plugin :

• sur la technique des formulaires CVT
• sur la méthode de stockage dans la table « spip_meta » ou dans une table déclarée dans l’attribut « meta » de la balise <paquet> du nouveau fichier XML de description d’un plugin (paquet.xml).
• et sur l’API de manipulation des variables de configuration issue de CFG, à savoir, la balise #CONFIG en HTML et les fonctions lire_config(), ecrire_config() et effacer_config() en PHP.

Cette évolution proposée par SPIP 3.0 permet de rationaliser la mise en place d’une configuration au sein d’un plugin mais laisse encore des points ouverts ou du moins non standardisés comme :

• l’affectation des valeurs par défaut,
• la possibilité d’exporter ou d’importer une configuration,
• la suppression automatique des variables de configuration en base de données suite à la désinstallation complète du plugin.

Affectation des valeurs par défaut

La problématique

Aujourd’hui deux techniques cohabitent dans les plugins sans que l’une ou l’autre ne soit réellement adoptée comme une pratique standard malgré les explications donnée dans l’article cité ci-dessus :

1. Les valeurs par défaut sont positionnées à chaque fois qu’on utilise une fonction de l’API de configuration : par exemple, #CONFIG{variable, défaut} ou lire_config(variable, défaut).
2. Les valeurs par défaut sont chargées une fois pour toute lors de l’activation du plugin via la fonction d’installation du schéma de données ${prefixe}_upgrade(). Dans ce cas, il n’est plus utile de préciser la valeur par défaut quand on manipule une variable de configuration en HTML ou en PHP.

La première technique devient rapidement pénible quand la liste des variables s’allonge et de surcroît multiplie les risques d’erreur d’affectation par défaut.

La deuxième technique simplifie grandement l’écriture dans le code HTML ou PHP et le rend aussi plus maintenable et évolutif. Cette initialisation à l’installation permet aussi d’envisager l’utilisation du mécanisme d’upgrade de schéma pour faire évoluer la configuration : elle semble donc à privilégier.

Les pistes de solution

Adopter en standard cette technique d’initialisation à l’installation d’un plugin, revient à faire évoluer les pratiques de codage mais aussi le noyau de SPIP 3.0 (très peu car tout existe ou presque). Une configuration de plugin nécessiterait donc :

• d’utiliser systématiquement l’attribut « schema » d’un plugin pour décrire l’existence d’une configuration de plugin tout autant que l’existence d’une modification de la structure de la base de données. Le principe d’évolution du schéma s’appliquerait donc indifféremment à la configuration ou à la base de données.
• de déclarer la liste des couples (variable de configuration, valeur par défaut) du plugin.
• d’utiliser la fonction ${prefixe}_upgrade pour déclarer les évolutions de la configuration du plugin dans le temps.
• de continuer à utiliser l’attribut « meta » du plugin pour décrire la table de stockage des variables de configuration si celle-ci est différente de spip_meta.

En ce qui concerne la déclaration afin de se rapprocher du mécanisme actuel de création de la base on pourrait utiliser un pipeline declarer_config pour définir les variables de configuration et leur valeur par défaut dans une variable globale $config_plugins indexée par le préfixe du plugin.

Cette fonction pourrait être insérée dans le même fichier que celui de la base si il existe ou du moins dans le dossier base/ du plugin. Il est également possible d’améliorer cette déclaration pour introduire plus finement les types et méthodes de stockage des variables de configuration (un peu comme le faisait CFG).

Dans le même genre d’idée SPIP fournirait une fonction maj_config('prefixeplugin') pour déclencher la création des variables de configuration du plugin. Pour l’upgrade de la configuration il est déjà possible aujourd’hui d’utiliser une fonction dédiée par upgrade ou les fonctions ecrire_config() ou effacer_config().

A ce stade, il reste un petit bémol avec les formulaires de configuration. En effet, il y a une dernière redondance à gérer car le formulaire définit aussi :

• le nom des metas dans la base soit en utilisant son nom ou un input caché
• et le nom des variables en utilisant les attribut name des inputs.

Il faudrait donc assurer la cohérence des deux définitions. A réfléchir !

Autre chose, sauf à utiliser des variables obligatoires dans le formulaire de configuration il faut s’assurer qu’il n’est pas possible d’effacer une valeur en la supprimant dans un input du formulaire sinon une écriture type lire_config('variable') pourrait être incorrecte. Peut-être faudrait-il appeler une fonction de vérification/positionnement du défaut spécifique au processus de validation du formulaire de configuration.

Sauvegarde et restauration de variables de configuration

La problématique

Quand le nombre de variables de configuration augmente, repasser tous les formulaires de configuration en revue pour appliquer une configuration donnée peut s’avérer pénible.

Même si d’aucuns, à juste titre, ne sont pas fans des configurations « clicodrome », force est de constater que la multiplication des plugins activés sur un site fait de toute façon enfler la configuration globale du site sans que l’on puisse distinguer celle de SPIP de celle des plugins. De ce fait, la nécessité de sauvegarder et de restaurer cette configuration des plugins pour des besoins de distribution par exemple n’est plus à négliger.

Un squelette comme Sarka-SPIP possède entre 100 et 200 variables de configuration réparties dans plus de 20 formulaires (donc 20 metas en base de données). Le squelette intègre donc un mécanisme spécifique de sauvegarde/restitution de la configuration basée sur des fichiers texte contenant les metas sérialisées.

Le noiZetier, le squelette Aveline et d’autres plugins ont aussi été confrontés à la même problématique et de là est né le plugin IEConfig, qui porte bien mal son nom, car il permet d’importer et d’exporter une liste de metas dans un même fichier au format YAML et non de configurer Internet Explorer ! Néanmoins, pour traiter ces metas de configuration, IEConfig demande à chaque plugin de (re)définir sa liste de metas de configuration dans un pipeline dédié.

Actuellement, IEConfig est utilisé de façon sporadique et n’est pas un standard même si il est intégré « à la hussarde » dans les plugins de la distribution SPIP 3.0. Il convient donc de trouver un solution générique SPIP à cette problématique.

Les pistes de solution

A partir du moment où l’on utilise la déclaration des variables de configuration des plugins comme proposée plus haut, il est toujours possible de connaître :

• la liste des metas de configuration d’un plugin
• la liste des metas de configuration de tous les plugins
• et donc a fortiori, par différence, la liste des metas de configuration de SPIP si on considère une situation où ce mécanisme est en place pour tous les plugins [1].

Il est alors facile d’imaginer un mécanisme d’exportation et d’importation de la configuration intégré à SPIP ou au plugin Dump voire à un plugin dédié. Le format du fichier d’export reste à déterminer : YAML, JSON, XML, Texte... Il pourrait être créé dans tmp/dump afin de ne pas multiplier les répertoires et s’appeler config_[${prefixeplugin}|plugins|spip]_${date_heure} en fonction du choix d’exportation.

On pourrait aussi envisager des pages d’export et d’import de la configuration à l’instar de celles de sauvegarde et restauration de la base de données proposée par le plugin Dump. Le choix entre un plugin donné, tous les plugins et SPIP serait proposé systématiquement.

Nettoyage des variables de configuration

La problématique

Au fur et à mesure que l’on installe, active, désactive ou désinstalle des plugins, la table spip_meta s’engorge d’enregistrements inutiles sauf si la configuration des plugins est contenue dans une table dédiée désignée par l’attribut « meta » de la balise <paquet> (cas très rare).

Si cela n’est pas plus dangereux que de laisser les tables du plugin Notation sans qu’elles soient utilisées, ce n’est pas non plus satisfaisant. Je suis d’ailleurs tombé sur un problème récemment où ayant supprimé le plugin STEP par FTP, je n’ai donc pas détruit proprement la table spip_plugins. Or, en migrant à SPIP 3.0 j’ai installé automatiquement SVP qui crée lui aussi une table spip_plugins : le résultat a été un peu surprenant.

Désinstaller un plugin devrait donc toujours s’accompagner de l’effacement en base de données de toutes ses traces.

Les pistes de solution

Là encore la déclaration des variables de configuration permettrait de s’acquitter automatiquement de cette tache. En appelant une fonction vider_config_plugin('prefixeplugin') dans la fonction actuelle ${prefixe}_vider_tables() ou peut-être en l’intégrant systématiquement dans le mécanisme de désinstallation on pourrait supprimer les enregistrements des metas du plugin.
Cette fonction pourrait aussi s’occuper de supprimer automatiquement la meta prefixeplugin_base_version.

En outre, l’existence d’une fonction d’export des variables de configuration permettrait de sauvegarder la configuration du plugin avant de la supprimer complètement.