Hello,
J’essaye de mettre en place une configuration de plugins dans une table différente que spip_meta et je me heurte à quelques incohérences dans les API SPIP.
-
L’API Config.
Les fonctions lire_config(), ecrire_config() et effacer_config() permettent aujourd’hui de spécifier la table dans laquelle lire ou écrire une variable de configuration.
Il suffit pour ça de rajouter /nom_table_sans_spip/ devant le nom de la variable.
Cela fonctionne parfaitement surtout que l’API gère également la création automatique de la table voire sa suppression quand cela est nécessaire.
-
L’API Meta et les upgrade de base
C’est là que ça se gâte.
Après avoir créé une meta de configuration dans une table autre que spip_meta pour mon plugin, appelons-la spip_mameta, je me suis dis que pour être cohérent il serait mieux de mettre la meta standard du plugin préfixe_base_version.
Donc j’ai utilisé la déclaration meta du paquet.xml (attribut de la balise paquet) qui est censée indiquer justement que les metas du plugin doivent être stockées dans une table donc le nom est celui de l’attribut préfixé par meta.
Donc j’ai ajouté cet attribut dans le paquet.xml, meta=« mameta » et lancé l’installation. Résultats des erreurs : https://framapic.org/JsNg3KT0MQmw/qceJT2ZbZuzM.png et pourtant un plugin installé mais aucune table créée, ni la meta mameta_version_base. Par contre, la configuration écrite via l’API Config est bien dans spip_mameta et la meta tables_config contient bien cette table.
Néanmoins, il existe dans la fonction maj_plugin() un quatrième argument qui permet de passer justement la table meta à utiliser : elle devrait être déduite par l’attribut mais pour essayer je saisis donc mameta dans l’appel de maj_plugin().
Le résultat semble plus probant mais les écritures dans la table spip_mameta ne se font pas car la table n’est pas créée automatiquement si elle n’existe pas comme pour l’API Config.
Donc il me semble qu’il y a plusieurs incohérences voire bugs :
- l’API Config et Meta ne fonctionnent pas de la même façon vis-à-vis d’un table différente de spip_meta
- l’upgrade fait appel à l’API meta et pas à l’API Config ce qui provoque en partie le problème.
- l’attribut meta ne semble pas être utilisé correctement lors de l’installation.
Est-ce que j’utilise mal les API ou confiez-vous les bugs ?
Si bug, il serait bon de les corriger en 3.3.
Hello,
J’essaye de mettre en place une configuration de plugins dans une table différente que spip_meta et je me heurte à quelques incohérences dans les API SPIP.
…
Donc il me semble qu’il y a plusieurs incohérences voire bugs :
- l’API Config et Meta ne fonctionnent pas de la même façon vis-à-vis d’un table différente de spip_meta
- l’upgrade fait appel à l’API meta et pas à l’API Config ce qui provoque en partie le problème.
- l’attribut meta ne semble pas être utilisé correctement lors de l’installation.
Premiers éléments de réponse :
La fonction qui permet d’installer ou de dés installer un plugin est dans la plupart des cas spip_plugin_install().
Cette fonction a le code suivant :
function spip_plugin_install($action, $infos, $version_cible) {
$prefix = $infos['prefix'];
if (isset($infos['meta']) and (($table = $infos['meta']) !== 'meta')) {
$nom_meta = "base_version";
} else {
$nom_meta = $prefix . "_base_version";
$table = 'meta';
}
switch ($action) {
case 'test':
return (isset($GLOBALS[$table])
and isset($GLOBALS[$table][$nom_meta])
and spip_version_compare($GLOBALS[$table][$nom_meta], $version_cible, '>='));
break;
case 'install':
if (function_exists($upgrade = $prefix . "_upgrade")) {
$upgrade($nom_meta, $version_cible, $table);
}
break;
case 'uninstall':
if (function_exists($vider_tables = $prefix . "_vider_tables")) {
$vider_tables($nom_meta, $table);
}
break;
}
}
C’est donc elle qui appelle les fonctions contenues dans _administrations.php.
On voit aussi qu’elle examine la paquet du plugin pour savoir si l’attribut « meta » a été rempli avec une table autre que meta.
Et donc la chose importante est que le prototype de la fonction upgrade ou vider_tables possède toujours un argument $table à la fin qui indique la table des metas pour le plugin.
Et cet argument est systématiquement absent de tous nos plugins et cela est renforcé par le fait que la Fabrique et Programmer n’en font pas référence.
Donc une bonne pratique serait maintenant de rajouter cet argument dans ces fonctions.
Cet argument $table devant être passé à la fonction maj_plugin() ou à effacer_meta par exemple.
Après ces modifications, il ne reste plus qu’un seul problème : la table spécifique des meta n’existe pas la première fois et comme l’API meta ne la crée pas au contraire de l’API config on a une erreur SQL. Je pense que c’est sur ce point qu’il faut faire une correction.
