Discussion sur spip-dev plutôt.
passer par une fonction pour pouvoir spécifier la page de configuration me parait aller à l'encontre du but visé qui est de permettre de faire un plugin avec une page de configuration sans devoir (ni savoir) écrire de php.
Je suis aussi insatifait, mais j'étais perplexe devant l'avalanche de tests conditionant la configuration qui au final se résumait à: soit "?exec=cfg&fond=$PLUGIN" soit .... RIEN. Là au moins on a la possibilité d'aiguiller vers autre chose que CFG, ce qui était quand même une étape obligée vu le code complètement vissé à CFG qu'il y avait auparavant.
Il vaudrait mieux que<config></config> spécifie simplement le nom de la page de config (nom de l'exec), en le limitant de facto à un possible.
Bah non parce que ça veut dire écrire du PHP.
Où ?
Sauf cas (très) particuliers, il est recommandé de ne plus écrire ses exec en PHP mais en HTML, comme cela est documenté sur programmer.spip.org. Donc on peut d'ors et déjà n'indiquer qu'une URL de l'espace privé (ou le nom de l'exec comme dit Cédric) et n'avoir à faire que du HTML. Sauf pour la partie traitement du formulaire, qui n'est pas encore fait (enregistrement auto dans une table metas), mais ça va venir.
Je pense que le but final est plutôt d'indiquer le formulaire CVT chargé de remplir les metas du plugin, qu'on pourrait même inclure en Ajax dans la page admin_plugin.
À mon sens on ne devrait vraiment pas se diriger dans cette direction : le bouton de configuration qui se trouve sur cette page est déjà un *raccourci* qui pourrait parfaitement ne pas exister du tout.
Le chemin "logique" pour arriver à une page de configuration, c'est dans les menus du bandeau ou onglet quelque part. C'est-à-dire que c'est à l'auteur du plugin de placer explicitement sa nouvelle page de configuration à un endroit qu'il trouvera le plus logique possible.
Actuellement le plugin CFG fait une page où il liste avec des onglets toutes les pages de config existantes (fonction dont tu parles plus bas je crois) : c'est le même principe que le raccourci sur la page d'admin des plugins. C'est-à-dire que c'est un fourre-tout automatique qui n'aura pas de sens logique, surtout quand on parle de réorganisation du bandeau (qui est déjà un chantier existant). Tel plugin aura sa config plus à sa place en sous-menu de tel gros boutons, d'autre à l'intérieur d'une page existante (par exemple dans la config de "Contenu du site"), etc. Le placement des pages est donc à faire au cas par cas. Bien sûr on peut aussi faire un truc automatique en parallèle, mais alors uniquement pour quelque chose de non-obligatoire, qui vient en plus pour aider, comme les boutons raccourcis.
Au passage je trouve qu'il y a des incohérences dans l'interface de programmation puisque certaines infos sont cherchées dans plugin.xml et d'autres sont écrites en dur dans le code (genre la fonction d'install == $nom_plugin . '_install'). Il faudrait être plus précis dans ce qu'on attend de plugin.xml.
Même si on pourrait accepter plusieurs<config>, ce raccourci ne saurait être qu'un raccourci vers une page accessible par ailleurs par le menu de configuration. Son existence est déjà en soi discutable, il serait de toute façon ergonomiquement aberrant de mettre là une pléthore de boutons de config.
Ben justement la fonction liste_onglet_cfg permet ça. Moi aussi je trouve ça aberrant
Cool on est tous d'accord en fait. 
, mais mon souci était de ne pas casser la compatibilité CFG, et d'offrir une migration facile vers les métas généralisées.
Je suis le premier à dire que CFG est un marteau-pilon pour écraser une mouche et qu'il faut le remplacer par qqch de beaucoup plus léger intégré au noyau, mais je rappelle tout de même qu'il s'agit de sortir la version 2.1.1, la version 2.1.0 étant par ma faute bancale sur ces histoires de MAJ de plugins via maj_while. Si on va plus loin maintenant, alors c'est vraiment une fonctionnalité nouvelle et on sort une 2.2. Là, je pense que c'est juste une échappée permettant à ceux qui savent coder en PHP d'expérimenter de nouveaux outils de configuration, en attendant de dégager des outils communs à mettre dans le noyau.
Si ça t'ennuie qu'il y ait une nouvelle entrée dans plugin.xml dont la signification risque de bouger, on peut la retirer et convenir de chercher la fonction $nom_plugin . '_config' (cf remarque ci-dessus), en attendant que les choses se clarifient.
Effectivement, ça parait un peu bizarre à partir du moment où ce n'est pas juste commité dans la branche 2.2 mais déjà dans la 2.1 utilisable par tous. Personnellement ça ne me dérange pas du tout d'introduire de nouvelles fonctionnalités en 2.1 tant que ce sont de petites choses, surtout que là c'est plus une amélioration, une généralisation, d'un truc existant. Mais ça vaut uniquement si on dit que ça ne bouge plus trop ensuite, car comme la 2.2 ne va pas sortir tout de suite, cette nouvelle chose va déjà commencer à être utilisée par des développeurs de plugins.
En résumé, mon avis c'est :
- soit on enlève <config> pour l'instant
- soit on y met plutôt une simple URL unique comme le dit Cédric
- et pas d'automatisme dans les menus ou onglets à part pour les boutons de raccourcis
)