Bonjour,
dans les docs, il y a plusieurs méthodes décrites pour l'initialisation
de ses tables par un plugin:
- dans un fichier déclaré dans le tag install du plugin.xml
une fonction prefix_upgrade() et
une fonction prefix_vider_tables()
- une fonction prefix_install($action) (dans ce même fichier ?)
avec $action = 'test' | 'install' | 'uninstall'
Sont-elles toutes les deux valides ?
Une méthode plus recommandée qu'une autre ?
Merci d'avance pour vos réponses éclairées !
j'ai examiné les 922 plugins de la zone sur ce point. La majorité utilise la première méthode, ceux utilisant la 2e ne faisant que dupliquer la fonction standard spip_plugin_install sans nécessité, à de très rares exceptions près. Je prépare un article sur cette interface de programmation qui est à mon avis totalement à revoir.
Committo,Ergo:Sum
Quelle bonne idée.
Merci !
La seconde méthode est historiquement la première proposée.
Constatant qu'on y faisait la plupart du temps la même chose, la première méthode a été ajoutée, et est en effet majoritairement utilisée, sauf pour des plugins très anciens non recodés depuis,
ou quelques cas particuliers qui pourraient sûrement être traités par un autre point d'entrée, car c'est un général juste un trigger dont on a besoin.
Cela pourrait être encore simplifié et uniformisé par un simple tableau déclaratif d'opérations élémentaires de mise à jour,
ce que tu avais préparé dans le maj_while du core, et qui donne quelque chose de simple au final comme
http://zone.spip.org/trac/spip-zone/browser/core/plugins/forum/base/forum_upgrade.php#L19
(sauf qu'on pourrait se dispenser d'ecrire la fonction)
Ne manquerait alors qu'un symétrique pour la désinstallation.
Cédric
Bon voilà:
http://spip21.smellup.net/spip.php?article36
la 2e partie est prospective, bien que facile à implémenter.
Committo,Ergo:Sum
Hello. Petits points à la lecture.
- le terme "installation" pour désigner la copie de fichiers me semble confus.
- le terme "activation" me va pour l'activation & (création schéma | mises à jour)
- le terme "suppression" me semble confus également (désinstallation ?)
- le terme "destruction" est violent ^^
Il manque à mon sens un point "décochage" : ne plus considérer un plugin actif, mais ne pas supprimer ses données ! Le reste étant une question de terminologie, de nommage pas évident à trouver. Mais il faut absolument permettre également cela à mon sens, de pouvoir désactiver temporairement un plugin sans effacer ses données donc.
Sinon, autre point qui me trouble est l'obligation proposée de nommer la version de base de données avec un entier. Je ne vois pas en quoi cette obligation est pertinente, puisque si les clés du tableau de mises à jour sont ajoutées dans l'ordre chronologique, il suffit d'itérer sur les clés et de les analyser pour savoir si on a dépassé ou non la version d'arrivée définie. Que ce soit 2.0.0 ou 13489 cela a peu d'importance il me semble.
Voilou les petites remarques.
Il manque à mon sens un point "décochage" : ne plus considérer un plugin actif, mais ne pas supprimer ses données !
Ca s'appele désactiver.
Le reste étant une question de terminologie, de nommage pas évident à trouver.
Justement un des buts de cet article est de se mettre d'accord là-dessus, parce que actuellement c'est confus.
Mais il faut absolument permettre également cela à mon sens, de pouvoir désactiver temporairement un plugin sans effacer ses données donc.
Bien entenu. C'est ce qui est fait actuellement et cet article ne parle pas de changer ça, je ne comprends pas pourquoi tu en parles.
Sinon, autre point qui me trouble est l'obligation proposée de nommer la version de base de données avec un entier. Je ne vois pas en quoi cette obligation est pertinente, puisque si les clés du tableau de mises à jour sont ajoutées dans l'ordre chronologique, il suffit d'itérer sur les clés et de les analyser pour savoir si on a dépassé ou non la version d'arrivée définie. Que ce soit 2.0.0 ou 13489 cela a peu d'importance il me semble.
C'est une question récurrente qu'on a eu sur SPIP lui-même: faut-il permettre le fork dans les schémas de données ? Je pense quant à moi que cette une fuite en avant qu'on finit tôt ou tard par payer très cher. Mais indépendamment de cette question, le foreach de PHP sur un tableau dont les index ne sont pas des entiers va imposer un tri préalable, ce qui n'est pas très heureux.
Committo,Ergo:Sum
Je voulais aussi réagir sur ce point car tu proposes seulement :
"la suppression est l’effacement des données du Plugin et de leur schéma, ainsi que son retrait de la liste des Plugins actifs"
Il manque la "désactivation" : inactivation du plugin sans effacement des données.
JLuc
Oui, comme JLuc, c'est parce que dans tes points de «propositions», ce n'est pas mentionné. J'ai fait le raccourci de croire que tu considérais cela inutile du coup.
En fait, la surveillance couteuse des fichiers des plugins (verifier_plugin) n'a qu'une finalité :
permettre de désactiver un plugin en supprimant ou renommant son répertoire en cas de page blanche après une activation.
Autrement dit c'est une fonction de secours qui permet de rétablir par ftp le fonctionnement normal du site par une opération à peu près naturelle.
C'est l'expérience qui nous avais conduit à ajouter ce fonctionnement qui n'était pas là au tout début.
Sur l'usage des tags, je pense que ce serait une erreur que de générer automatiquement les zip à partir des branches.
L'acte de publication d'une archive doit rester un acte volontaire et conscient (sauf si on parle d'un zip de dev réputé instable).
Il faut pouvoir faire évoluer une branche sans que le zip ne varie, sauf à se retrouver avec des zip temporairement non fonctionnels.
Les tags ont le mérite de figer la version à un moment choisi par les développeurs.
Sur la terminologie, mathieu souligne involontairement en énumérant, le seul petit flou que je vois dans ta proposition :
le terme activation correspond à une unique étape utilisateur, mais à 2 étapes techniques : l'activation donc, et la création du schema/maj
Je pense qu'il serait bien de nommer cette seconde partie, car même si elle est invisible pour les utilisateurs, elle a une existence,
et le fait qu'on soit obligé de périphraser pour la désigner n'est pas génial
J'avais eu le tort de choisir 'installation', alors que ce terme désigne en général l'ensemble du processus, depuis le dépôt des fichiers, jusqu'à la mise en service.
Peut être devrait-on complètement évacuer ce terme, et ne le garder que dans son sens englobant général.
Le build_while n'était pas simplement utilisable en version 2.1 du fait de l'obligation d'utiliser une numérotation de version entière,
et de la gestion de redirection au bout de 20s qui renvoie actuellement sur une url non fonctionnelle dans le contexte de la page des plugins.
Cela dit, sur la branche dev, il a évolué pour prendre en compte les numéros de version x.y.z, et prend en compte la gestion de timeout, avec un point d'entrée
maj_plugin symétrique du maj_base utilisé par le core.
Cela simplifie bien de se reposer sur cette fonction, et je suis d'accord que l'interface technique pour le plugin pourrait se limiter a la déclaration du tableau d'operation de maj.
Cédric
En fait, la surveillance couteuse des fichiers des plugins (verifier_plugin) n'a qu'une finalité :
permettre de désactiver un plugin en supprimant ou renommant son répertoire en cas de page blanche après une activation.Autrement dit c'est une fonction de secours qui permet de rétablir par ftp le fonctionnement normal du site par une opération à peu près naturelle.
C'est l'expérience qui nous avais conduit à ajouter ce fonctionnement qui n'était pas là au tout début.
Je ne comprends pas. Si la page est blanche après activiation, on comprend tout de suite que qqch ne va pas dans ce plugin. En outre, au moment de l'activation on peut faire ces contrôles une fois pour toutes, à quoi ça sert de le faire à chaque fois ?
Sur l'usage des tags, je pense que ce serait une erreur que de générer automatiquement les zip à partir des branches.
L'acte de publication d'une archive doit rester un acte volontaire et conscient (sauf si on parle d'un zip de dev réputé instable).
Il faut pouvoir faire évoluer une branche sans que le zip ne varie, sauf à se retrouver avec des zip temporairement non fonctionnels.
Les tags ont le mérite de figer la version à un moment choisi par les développeurs.
Ce que je prétend, et c'est assez général dans SPIP, c'est qu'il y a redondance de fonctionnalités qui pertubent tout le monde, surtout les nouveaux venus. Dans le répertoire d'un plugin on peut créer des branches et spécifier dans le fichier XML l'état du plugin, de "dev" à "stable", et comme tout le monde a accès en écriture au fichier archivelist, on peut demander qu'une branche soit zippée. Dès lors, la branche générale des archives ne sert à rien: au moment où l'auteur d'un plugin modifie son numéro de version x.y.z si, il décide d'en faire ou non une branche, et qu'elle soit zippée ou non. Gérer d'une part le répértoire de son plugin, d'autre part le répertoire des tags est une complication inutile, coûteuse et perturbante. Par ailleurs comme SVN archive les anciennes versions d'un fichier, l'argument qu'il ne faut pas que le zip varie est irrecevable: si une variation N+1 introduit une régression, il est toujours possible de récupérer l'ancienne version des fichiers et de récréer un zip étiquetté N+2 et identique à N, ça n'a rien de gênant et le cas est rare.
Note qu'il y a en fait 2 questions distincites, l'existence d'une branche générale des archives est-elle souhaitable, et le fichier archivelist doit-il être produit manuellement et collectivement ? Pour moi les 2 réponses sont non, mais elles sont indépendantes.
Sur la terminologie, mathieu souligne involontairement en énumérant, le seul petit flou que je vois dans ta proposition :
Sur ce point ce n'est pas ma proposition mais le reflet de l'état actuel de SPIP.
le terme activation correspond à une unique étape utilisateur, mais à 2 étapes techniques : l'activation donc, et la création du schema/maj
Je pense qu'il serait bien de nommer cette seconde partie, car même si elle est invisible pour les utilisateurs, elle a une existence,
et le fait qu'on soit obligé de périphraser pour la désigner n'est pas génial
Oui cette 2e étape est véritablement l'initialisation du plugin, et devrait être nommée ainsi, en précisant que activation ==> initialisation si pas déjà faite. Mais pour moi le pb n'est pas tant terminologique que logiciel:
comme je le dis dans l'article, cette initialisation se fait lorsqu'on visite une page produite par un exec/
qui normalement ne fait pas d'accès en écriture, seulement de l'affichage. C'est surtout cette entorse au modèle REST qu'il faudrait éliminer. Quant on aura un bon modèle fonctionnel, la terminologie suivra.
J'avais eu le tort de choisir 'installation', alors que ce terme désigne en général l'ensemble du processus, depuis le dépôt des fichiers, jusqu'à la mise en service.
Peut être devrait-on complètement évacuer ce terme, et ne le garder que dans son sens englobant général.
Il faut un mot désignant l'opération de copie des sources d'un plugin dans un répertoire connu de SPIP pour avoir des plugins. Actuellement c'est "installation" qui est pris, on peut prendre autre chose par exemple "chargement" (cf spip_loader), mais maintenant que l'habitude est prise, je suis pas sûr que ça éclaricirait vraiment la situation.
Le build_while n'était pas simplement utilisable en version 2.1 du fait de l'obligation d'utiliser une numérotation de version entière,
et de la gestion de redirection au bout de 20s qui renvoie actuellement sur une url non fonctionnelle dans le contexte de la page des plugins.Cela dit, sur la branche dev, il a évolué pour prendre en compte les numéros de version x.y.z, et prend en compte la gestion de timeout, avec un point d'entrée
maj_plugin symétrique du maj_base utilisé par le core.
J'avais signalé dans ce code que j'avais écrit rapidement pour la sortie de la 2.1 que ça restait "à tester", n'ayant eu le temps de le faire que pour des petits cas sans Time-out. Tant mieux si tu as arrangé ça. Il était en revanche "simplement utilisable" pour des numéros de version entiers dont je répète que c'est une discipline qui contraint faiblement le présent pour éviter de gros ennuis futurs.
Cela simplifie bien de se reposer sur cette fonction, et je suis d'accord que l'interface technique pour le plugin pourrait se limiter a la déclaration du tableau d'operation de maj.
Bon très bien si on est d'accord pour partir là-dessus, mais tout le monde doit se rendre compte qu'il y a des incompatibilités fortes du coup, surmontables sans difficulté mais comme toujours qui demandent du temps.
Committo,Ergo:Sum
L'activation du plugin ne permet pas de vérifier des cas comme la double déclaration de fonction qui provoque une page blanche ou autre.
Si il y a page blanche, on a plus d'interface pour désactiver le plugin.
Lorsque la fonction avait été mise en place, c'était pour provoquer la désactivation automatique du plugin si on enlevait ses sources.
Cela dit, en relisant le code actuel de la fonction, je vois qu'on ne le fait plus et on se contente d'un message d'avertissement.
Donc on a plus le scenario critique auquel ça répondait initialement.
On peut sans doute allèger le code maintenant.
Notamment la compilation des plugins produit pour chaque inclusion un systématique
if (file_exists($f='xxx'){include_once($f);}
qu'on pourrait enrichir d'un
if (file_exists($f='xxx'){include_once($f);} else erreur_plugin_fichier_manquant($f);
ce qui du coup devrait en effet permettre d'évacuer le fichier de verif lui même, ainsi que la verification preliminaire systématique (enfin systématique dans l'espace privé, pour les admin)
Cédric