Je note en consultant tes chiffres qu’en fait :
sur les 11604 sites recensés, seuls 5034 envoient des informations sur la version de SPIP et les plugins utilisés.
Les 6476 sites restant étant soit injoignables, soit plus sous SPIP, soit dans une vieille version < 1.8
Ramener le ratio des sites ayant activés un plugin sur les 11604 sites est assez peu pertinent, puisque seuls les sites sous versions >=1.9.0 sont suceptibles d’avoir activé un plugin.
On peut toujours argumenter qu’un vieux site en 1.6 n’a pas de plugin et cela montre que les fonctionnalités des plugins ne sont pas nécessaires, mais alors il faudrait élargir l’argument au fait que SPIP 1.9 et suivant eux même ne sont pas nécessaires, puisque les-dits sites semblent se satisfaire d’une vieille version.
Par ailleurs, cette argumentation ignore totalement les forks et personnalisations de SPIP qui étaient à l’époque opérées par les webmestres faute de plugin (souvenez vous de l’installation d’un spip-listes sur SPIP 1.8 …) mais qui revenaient à enrichir fonctionnement le SPIP de base.
Si l’on se ramène donc au seul contingent des sites sous SPIP ayant la possibilité d’activer un plugin, cela représente alors 4578 sites.
Parmi lesquels 3642 sites ont activé au moins un plugin, soit près de 80%.
Ce qui peut donc s’exprimer sous la forme :
80% des sites sous SPIP>=1.9 ont besoin de fonctionnalités en plus de celles qui sont dans le SPIP-Core, et ajoutent pour cela au moins un plugin.
L’avantage des études statistique c’est qu’on peut leur faire dire ce que l’on veut !
Attention donc avant de s’appuyer sur cela pour argumenter des choix stratégiques !
Pour ceux que ça intéresse (et qui ont un compte sur spipnet), la suite ici: SPIP
Ces chiffres indiquent que moins d'un tiers des sites sous SPIP ont besoin d'un plugin, et Bonux ne saurait prétendre à intégrer le noyau qu'après intégration de cfg, couteau_suisse et thickbox1. Est-ce bien raisonnable ?
...
L'avantage des études statistique c'est qu'on peut leur faire dire ce que l'on veut !
Attention donc avant de s'appuyer sur cela pour argumenter des choix stratégiques !
Mon mail disait justement la même chose, en répondant à un argumentaire chiffré, à la louche de surcroît: si on tire argument d'un effet de nombre, on part sur une mauvaise direction.
J'en suis d'ailleurs encore plus convaincu aujourd'hui, ayant regardé pour la première fois en détail CFG, lors de la mise à niveau SPIP2 du plugin Association: pour simplement lire une valeur dans un tableau PHP alimenté par une table SQL (voire alimenté par cache), lire_configuration crée 2 objets, alloue quantité de tableaux via explode et consorts, en donnnant un service supplémentaire moins élaboré que CVT. CVT plus la généralisation des tables des metas que je viens d'envoyer suffise à mon avis à ranger CFG au placard, et à terme faire baisser les stats ci-dessus. Je suis donc bien convaincu que les arguments d'ordre qualitatif sont indispensable pour fonder les choix stratégiques.
heu là je ne suis pas d'accord *du tout*: la force de CFG réside *avant tout* sur le fait qu'il permet d'utiliser des options de configuration pour un plugin et de construire l'interface correspondante sans avoir à coder (ou connaître!) *une* ligne de PHP.
Pour tous ceux qui pluginisent leurs squelettes (par exemple) et qui n'ont donc pas d'autres capacités de codeurs que celles de connaître le HTML et le code SPIP cela reste un atout *irremplaçable*! (et, amha, dans la droite ligne de l'esprit de SPIP de simplicité de mise à disposition d'outils aux non-développeurs)
Après, on peut imaginer remettre une "couche" par dessus les CVT pour arriver à un résultat similaire, mais ça ne sera jamais qu'un *autre* plugin...
Ecrire le html d'un formulaire de configuration CVT n'est pas plus compliqué qu'avec CFG (qui peut aussi utiliser un CVT maintenant).
Mais là où CFG charge toute une panoplie d'objets et de materiel pour faire du multi conteneur alors qu'on utilise dans 99,9% des cas une meta serializee, on pourrait avoir une couche minimale qui se dispense du multiconteneur, se contente de metas et, si possible, du scan compliqué du squelette de formulaire par une simple déclaration annexe.
Il y a quasiment deja tout ce qu'il faut dans le core (lire_metas, appliquer_modifs_config), il ne manque pas grand chose pour faire le liant rendre les choses aussi faciles qu'avec CFG mais sans CFG
Ecrire le html d'un formulaire de configuration CVT n'est pas plus compliqué qu'avec CFG (qui peut aussi utiliser un CVT maintenant).
Mais là où CFG charge toute une panoplie d'objets et de materiel pour faire du multi conteneur alors qu'on utilise dans 99,9% des cas une meta serializee, on pourrait avoir une couche minimale qui se dispense du multiconteneur, se contente de metas et, si possible, du scan compliqué du squelette de formulaire par une simple déclaration annexe.
Il y a quasiment deja tout ce qu'il faut dans le core (lire_metas, appliquer_modifs_config), il ne manque pas grand chose pour faire le liant rendre les choses aussi faciles qu'avec CFG mais sans CFG
Oui je suis assez d'accord avec ce constat et j'ajouterais que ça pourrait aussi régler la question lancinante de l'intégration ou pas de CFG dans le core (ou du moins du moteur hors interface). C'est une bonne idée à mon avis qu'il faut creuser.
En fait techniquement il ne manque rien : il suffit de s'insérer dans les pipelines CVT et d'appliquer des traitements par défaut si on s'aperçoit que le formulaire n'a que le HTML et pas de fonctions déjà définies. C'est ce que fait désormais CFG, et c'est plutôt propre pour cette partie-là.
La seule chose qui manque, c'est se mettre d'accord sur comment on déclare les deux ou trois informations dont ce traitement par défaut aura besoin pour faire l'enregistrement afin de ne pas faire de "surcompilation" du HTML comme le fait CFG.
Donc ça comprend :
- la liste des champs autorisés à être enregistrés (CVT le prévoit déjà)
- le nom de la meta dans laquelle on enregistrera
- optionnellement le nom de la table metas qu'on utilisera, depuis le commit d'ESJ qui étend ce principe
Après, on peut imaginer remettre une "couche" par dessus les CVT pour arriver à un résultat similaire, mais ça ne sera jamais qu'un *autre* plugin...
Non justement parce que CVT n'est pas un plugin. Comme le dit Eric, c'est la question lancinante de l'intégration des outils de configuration de plugin à l'intérieur du noyau. Il faut effectivement garder la facilité d'utilisation de CFG, mais se débarasser de sa gestion de fonctionnalités peu utilisées qui grève
considérablement ses performances.
La seule chose qui manque, c'est se mettre d'accord sur comment on déclare les deux ou trois informations dont ce traitement par défaut aura besoin pour faire l'enregistrement afin de ne pas faire de "surcompilation" du HTML comme le fait CFG.
Oui tout à fait.
Donc ça comprend :
- la liste des champs autorisés à être enregistrés (CVT le prévoit déjà)
- le nom de la meta dans laquelle on enregistrera
- optionnellement le nom de la table metas qu'on utilisera, depuis le commit d'ESJ qui étend ce principe
Oui, et ce qui me gène encore c'est dans spip_plugin_install, la table utilisée est en dur "spip_meta", ce qui est gênant: si je veux sauvegarder les tables d'un plugin, j'ai besoin d'avoir le numéro version_base du dump produit, or ce numéro est donné par $PLUGIN_version_base dans la table "spip_meta". Donc soit on n'a pas cette info si on ignore cette table, soit on la sauvegarde aussi mais alors il faut savoir ignorer ce qui ne concerne pas le plugin.
Attention, il me semble que le schema avec table meta dédié est un cas particulier correspondant aux besoins des gros plugins qui sont en nombre restreints de ce point de vue.
Dans la plupart des cas on a besoin que de stocker 2 ou 3 valeurs en meta, ça me parait ridicule d'ajouter une table pour cela, non ?
Mon souci est de pouvoir faire des dumps complets d'un plugin donné. Dans le pire des cas ça ferait une table des meta réduite au numéro de version décrivant le dump, c'est évidemment ridicule mais ça l'avantage d'offrir un comportement unifié.
Sur le plan des perfs, ça ne me paraît pas un pb puisque c'est mis en cache à l'install du plugin et ensuite ça ne bouge plus (en fait si, lors du chgt d'aléa mais même ça on pourrait le virer).
Au passage, depuis que la fonction maj_while s'applique aussi plugin, on pourrait étendre spip_plugin_install pour qu'il l'appelle en boucle, plutôt que laisser chaque $PLUGIN_upgrade le faire.
Oui, et ce qui me gène encore c'est dans spip_plugin_install, la table utilisée est en dur "spip_meta"
A la réflexion, un moyen simple est de rajouter un élément "meta" dans plugin.xml, qui par défaut vaudrait spip_meta, et sinon le nom de la table des meta spécifiques au plugin. Après il suffit d'un ajout dans get_info et prendre en compte cet ajout dans installe_un_plugin lorsq'il appelle spip_plugin_install.
A ce propos je ne comprends pas pourquoi ce que celle-là transmet à celle-ci est seulement $infos['prefix'] et pas $infos tout entier: si on a besoin d'autres infos que le préfixe, on est obligé de rappeler get_infos alors qu'il était à portée d'environnement.
Cela a donc été impléménté dans 15675, tandis que 15780 fournit une nouvelle défnition de la fonction surchargeable plugins_afficher_plugin qui admet un argument supplémentaire, savoir un bloc clicable donnant accès à la confiuraiton du plugin. Par défaut, ce bloc est celui emmenant vers CFG comme auparavant, mais l'idée est évidemment de pouvoir emmener ailleurs. Toutefois ce n'est pas satisfaisant car cette fonction est appelée en plusieurs endroits.
Que diriez-vous d'une déclaration d'une fonction de config dans plugin.xml ?
A la réflexion, un moyen simple est de rajouter un élément "meta" dans plugin.xml, qui par défaut vaudrait spip_meta, et sinon le nom de la table des meta spécifiques au plugin. Après il suffit d'un ajout dans get_info et prendre en compte cet ajout dans installe_un_plugin lorsq'il appelle spip_plugin_install.
A ce propos je ne comprends pas pourquoi ce que celle-là transmet à celle-ci est seulement $infos['prefix'] et pas $infos tout entier:
Cela a donc été impléménté dans 15675, tandis que 15780 fournit une nouvelle défnition de la fonction surchargeable plugins_afficher_plugin qui admet un argument supplémentaire, savoir un bloc clicable donnant accès à la confiuraiton du plugin. Par défaut, ce bloc est celui emmenant vers CFG comme auparavant, mais l'idée est évidemment de pouvoir emmener ailleurs. Toutefois ce n'est pas satisfaisant car cette fonction est appelée en plusieurs endroits.
Oui, la référence en dur à CFG dans le core ne me plaisait pas beaucoup, et je pensais plutot l'évacuer au profit d'un pipeline,
Que diriez-vous d'une déclaration d'une fonction de config dans plugin.xml ?
ça me parait encore le mieux : un tag
<config>nomdelexec</config>
Ok, je m'en occupe. Au passage, une chose me chiffone: dans plugin.xml on utilise parfois des noms complets (description, categorie, necessite, pipeline),
parfois des abréviations par apocopes influencées par l'anglais (install, prefix, icon). Dans la mesure où les accents sont virtuellement interdits, je pense que les abréviations sont plus recevables que des mots complets mais amputés de leurs accents, et je prends donc "config".
Ouais bof, enfin pas pour config mais pour les abréviations est ce forcément nécessaires. Par contre, on a aussi une balise et ce qui n’est pas très heureux.
