Hello !
Vous pouvez, sans installer SPIP 3 ni SVP vous faire une idée de la nouvelle administration des plugins en regardant le screencast de démo sur medias.spip.org : http://spip.arscenic.tv/medias/demonstrations/article/presentation-de-svp-0-67-0
Attention, l’interface est encore en version beta.
Toutefois, n’hésitez pas a nous faire remonter vos commentaires.
Salut,
il faudrait que le dépôt de plugins.spip.org soit actif par défaut, non ?
2011/12/24 Eric <eric@smellup.net>
Salut,
il faudrait que le dépôt de plugins.spip.org <http://plugins.spip.org> soit actif par défaut, non ?
Je ne reconnais pas là son adresse, mais celui de la zone devrait certainement être activé, oui.
Il sera toujours temps pour les plus curieux des utilisateurs de chercher à se brancher
sur d'autres dépots lorsqu'ils le souhaiteront ou en auront besoin, mais pour l'immense
majorité des utilisateurs, les plugins de la zone doivent être immédiatement accessibles.
Le détour actuel est une complication injustifiée passé la phase de test et debugging.
JLuc
Ouais , ouais, ouais…
Le détour actuel est une complication injustifiée passé la phase de test et debugging.
Alors pour justifier l’injustifiable en tant que dev un peu « cucu » :
Il me semble que c’est déjà le cas sur spip 2.1.
Si on crée auto/ il est possible alors d’ajouter des zones de plugins via les flux rss de contribs et de plugins spip mais qu’aucune n’est active par défaut.
Dans SVP on a donc le même fonctionnement avec aussi un lien SPIPZone qui permet de ne pas s’embêter avec l’url.
Il est tout a fait possible de créer un dépot par défaut. On ne l’a pas fait jusqu’alors car le temps de chargement du dépot de la zone était trop important. Il faut dire que malgré ce que j’ai pu dire jusqu’alors on continue à engraisser le archivelist.txt de la zone sans se soucier du nombre de paquets ni du mélange qu’il peut y avoir.
Et là on touche à ce qui pour moi est un problème :
Je ne trouve pas judicieux qu’on puisse charger par défaut, c’est-à-dire comme une feature de SPIP, un dépot surdimensionné dont les plugins peuvent être dans un état de développement incertain.
Je pense qu’il faudrait un dépot de « plugins SPIP stables » pour cela même si je sais que ce sera encore un troll à venir malheureusement.
Voilà voilà, c’est finalement pas si compliqué et il existe une justification…
Eric, qui franchement en a ras le bol de la tournure de certains mails…
Ouais , ouais, ouais...
Le détour actuel est une complication injustifiée passé la phase de test et debugging.Alors pour justifier l'injustifiable en tant que dev un peu "cucu" :
1) Il me semble que c'est déjà le cas sur spip 2.1.
Oui... mais c'est bien d'améliorer quand on peut !
2) Il est tout a fait possible de créer un dépot par défaut. On ne l'a pas fait jusqu'alors car le temps de chargement
du dépot de la zone était trop important. Il faut dire que malgré ce que j'ai pu dire jusqu'alors on continue à
engraisser le archivelist.txt de la zone sans se soucier du nombre de paquets ni du mélange qu'il peut y avoir.
Et là on touche à ce qui pour moi est un problème :
Je ne trouve pas judicieux qu'on puisse charger par défaut, c'est-à-dire comme une feature de SPIP, un dépot
surdimensionné dont les plugins peuvent être dans un état de développement incertain.
Je pense qu'il faudrait un dépot de "plugins SPIP stables"
Oui, c'est une excellente idée.
> Pour cela même si je sais que ce sera encore un troll à venir malheureusement.
Je ne suis pas sur que cette crainte soit justifiée.
En fait je n'arrive pas bien à imaginer ce que tu crains.
Le fait qu'un plugin soit stable n'est pas un engagement de la team officielle.
Dans le cas où un plugin est déclaré stable alors que la team considère
qu'il ne l'est pas (ou pas 'digne' de figurer dans cette liste, ce qui revient au même
puisque cela signifie que son état de dev est inabouti), il est facile de le signaler
et de corriger, car c'est un argument assez technique (présence de bugs rédhibitorie...).
je me demande si on aurait pas plutôt tendance à constater des plugins stables
mais qui restent en etat 'dev' ou 'test'afin de continuer une petite vie tranquille
loin des projecteurs ? mais c'est pas sur : on peut toujours mieux faire hein...
Peut être on peut tenter cette création de paquet et ajuster le tir au besoin.
Donc : plutôt qu'un 'paquet-plugin-spip' intégrer un paquet 'paquet-plugins-spip-defaut'
dés la détection du répertoire auto
et, pour commencer, donner la définition suivante de ce paquet :
'il contient tous les plugins stables de la zone'.
Si quelque chose m'échappe, peux tu expliciter tes craintes de troll ?
Eric, qui franchement en a ras le bol de la tournure de certains mails....
Il y a dans spip quelques points historiquement difficiles pour les utilisateurs
et quand l'un de ces points est l'objet d'un gros travail de refactoring,
c'est l'occasion ou jamais de faire évoluer les choses.
C'est pour faire entendre cette voix que j'ai employé un ton affirmé
afin de passer les éventuelles barrières à l'écoute des devs.
Je suis désolé si la dose affirmative était trop forte !
JLuc
Bonjour,
Et là on touche à ce qui pour moi est un problème :
Je ne trouve pas judicieux qu'on puisse charger par défaut,
c'est-à-dire comme une feature de SPIP, un dépot surdimensionné dont
les plugins peuvent être dans un état de développement incertain.
Je pense qu'il faudrait un dépot de "plugins SPIP stables" pour cela
même si je sais que ce sera encore un troll à venir malheureusement.
Ça pourrait rester un petit troll...
Ça rejoint peut-être l'idée des 'distributions' de SPIP.
Je ne pense pas que le statut 'stable' soit un critère pertinent: il y a
plein de plugins comme Saisies/API de vérification, Compositions et
Skeleditor par exemple qui ne sont pas stables, et qui me semblent
indispensables dès qu'on a à créer des formulaires et des affichages variés.
D'autre part il y a des plugins stables dont l'usage est très particulier.
Il me semble que l'intérêt serait d'avoir un dépôt par défaut, limité en
taille, de plugins très souvent utilisés, et/ou de groupes de plugins
convenant à des 'profils' d'utilisations de SPIP.
C'est peut-être un filtre de plugins qu'on doit pourrait appliquer au
dépôt 'officiel' de SPIP (sans préjuger de l'implémentation).
En tout cas, cette/ces sélection(s) de plugins devrai(en)t être faite(s)
par l'équipe des devs, comme c'est le cas pour les extensions. Ce serait
des extensions facultatives en quelque sorte. Ça n'empêche personne
d'implémenter son dépot de plugins préférés.
De la même façon, il me semble important, comme certains l'ont déjà
exprimé, de distinguer les thèmes et les plugins.
Mes 2 centimes…
Le fait qu'un plugin soit stable n'est pas un engagement de la team
officielle.
qu'est ce que c'est encore que cette nouvelle invention ?
où donc est cette team *officielle* ?
par là même : où donc se cache la team *non officielle* ?
à trop vouloir jouer avec les mots, on finit par dire et écrire
un peu n'importe quoi non ?
Dans le cas où un plugin est déclaré stable alors que la team considère
je donne mon avis personnel (qui, certes, n'engage que moi mais que je
partage néanmoins, ce qui fait qu'il compte au moins pour 2) :
il est *hors de question* que la 'team' ait un quelconque avis à
donner sur la qualité, pertinence, stabilité ou je ne sais quoi
concernant les *plugins*.
C'est pour faire entendre cette voix que j'ai employé un ton affirmé
afin de passer les éventuelles barrières à l'écoute des devs.
faudrait voir à arrêter de véhiculer cette fausse image des membres
de la team qui seraient sourds et enfermés dans leur tour d'ivoire.
à ma connaissance il n'y a pas que des devs dans la team (au sens où
toi jean-luc tu les définis).
comme dit plus haut (plus bas pour ceux qui rangent leurs affaires à
l'envers) : hors de question !
les seuls 'devs' qui sont à prendre en compte ici, sont les êtres
humains[1] qui participent au code des plugins.
[1] même s'il parait (on me l'a dit) que pour *certains* plugins
il y aurait aussi des 'entités codeuses' mi humaines, mi animales...
En tout cas, cette/ces sélection(s) de plugins devrai(en)t être faite(s)
par l'équipe des devs, comme c'est le cas pour les extensions.comme dit plus haut (plus bas pour ceux qui rangent leurs affaires à
l'envers) : hors de question !
Et pourquoi donc ?
Si ça prive les utilisateurs d'un SPIP utilisable out of the box,
ce principe est inadapté.
les seuls 'devs' qui sont à prendre en compte ici, sont les êtres
humains[1] qui participent au code des plugins.
Il y a le code des plugins et il y a le code de SPIP tel qu'il est distribué.
Ce sont 2 choses différentes.
JLuc
Et pourquoi donc ?
comme déjà dit : les membres de la team de spip n'ont pas vocation
ni autorité à décréter que tel ou tel plugin est homologué.
Si ça prive les utilisateurs d'un SPIP utilisable out of the box,
ce principe est inadapté.
on ne construit pas une communauté libre sur la mise en place
d'un pouvoir d'académiciens (c'est pour moi une évidence).
Humm,
Bonjour,
Je ne pense pas que le statut ‹ stable › soit un critère pertinent: il y a
plein de plugins comme Saisies/API de vérification, Compositions et
Skeleditor par exemple qui ne sont pas stables, et qui me semblent
indispensables dès qu’on a à créer des formulaires et des affichages variés.
Non je ne peux pas être d’accord sur le fait de dire « ce truc est mal utilisé donc il faut le contourner ». On s’est fait chier à restaurer 800 plugin.xml y compris leur version nommée avec des logiques toutes plus folkloriques les unes que les autres c’est pas pour baisser les bras sur ce sujet.
Et pourquoi ne pas utiliser les états de façon correct ? Franchement la dernière version de Saisies est-elle vraiment autre chose que stable ?
Donc le souci c’est d’abord la mise à jour de cet état, pour lequel d’ailleurs il y a une proposition de gestion dans l’aide de Plugins SPIP : http://plugins.spip.net/redaction-du-paquet-xml.html
De la même façon, il me semble important, comme certains l’ont déjà
exprimé, de distinguer les thèmes et les plugins.
Oui mais c’est parce que le vocabulaire utilisés depuis des années, à savoir le terme « plugin », recouvre à la fois l’entité fonctionnelle et le mécanisme de distribution.
Thèmes, squelettes et modules fonctionnels sont distribuables via le mécanisme de plugin.
Il existe donc une interface d’administration des plugins, en tant que mécanisme. Donc tous les « types de modules » doivent pouvoir y être administré.
Yop,
Ne serait-ce pas l'occasion de nommer ces choses-là de façon à mieux comprendre (et éviter de pérenniser le même type de vocabulaire confus comme nous avons déjà pour les « images » qui sont jointes en tant que « document » mais insérées en « img » et vice versa si bien qu'on ne sait plus de quoi on parle...) ?
J'essayais justement, ces jours-ci, de documenter cela et j'ai buté sur le vocabulaire qui rendait les phrases incompréhensibles. Reprenons...
Après avoir installé SPIP, on peut le compléter avec :
- d'un « thème » qui est {grosso modo} une feuille de style CSS (et ses fichiers graphiques), disponible sous cette forme ou sous forme de fichier zip prêt à l'emploi, dit « plugin »
- d'un jeu de « squelettes » plus ou moins complet, qui est constitués de fichiers générant le site public, généralement html, mais incluant parfois un thème et disponible sous la forme d'un dossier ou sous forme de fichier zip prêt à l'emploi, dit « plugin »
- de « plugins » qui ajoutent des fonctionnalités à SPIP, distribués sous forme de fichier zip prêt à l'emploi, dit « plugin »
- il faut aussi mentionner les « extensions », qui sont en fait des « plugins » et « squelettes » (faut pas oublier la « dist »), mais nommées différemment car distribuées d'office avec SPIP
* Est-ce que c'est bien ça ? Ai-je compris ?
* Est-ce compréhensible ? Facilement ?
Pour ne rien simplifier, les répertoires à la racine d'un projet SPIP, s'ils portent les mêmes noms ont un rôle qui ne correspond par tout à fait :
/themes : contient des « thèmes » mais uniquement sous forme de « plugins » et uniquement Z-compatible !
/squelettes : contient des fichiers de tout type (mais jamais de « squelettes » ou « thèmes » distribués sous forme de « plugins » !) et pas seulement des squelettes, contrairement à ce que son nom laisse entendre. C'est le répertoire des surcharges ultimes, pour tout, squelettes, thèmes css, mais aussi pour construire les pages de l'interface d'administration, si, j'vous jure...
/plugins : contient des « plugins » qui peuvent être des « plugins », « thèmes » et « squelettes »
/extensions : contient les « extensions », c'est-à-dire les « plugins » et « squelettes » distribués avec SPIP
C'est beaucoup trop compliqué à expliquer !!!
Je suggère vivement qu'on adopte des termes différents pour désigner les « trucs qu'on ajoute » et leur nature.
Par exemple, on pourrait alors expliquer de façon moins confuse, que SPIP est complété par 4 types d'« extensions » :
- « thème »
- « squelettes »
- « plugins »
- « plugins du core »
les répertoires correspondants seraient :
/themes : plutôt au singulier, puisqu'on n'en utilise qu'un seul à la fois, non ?
/squelettes : historique, conservé pour rétrocompat, mais à réserver aux squelettes
/plugins : comme d'hab
/plugins-core : pour remplacer l'actuel /extensions
et
/perso : dossier de surcharge ultime, qui fonctionnerait donc comme notre actuel dossier /squelettes
Qui dit mieux ?
-- romy
Hello
les répertoires correspondants seraient :
/themes : plutôt au singulier, puisqu'on n'en utilise qu'un seul à la
fois, non ?
/squelettes : historique, conservé pour rétrocompat, mais à réserver aux
squelettes
/plugins : comme d'hab
/plugins-core : pour remplacer l'actuel /extensionset
/perso : dossier de surcharge ultime, qui fonctionnerait donc comme
notre actuel dossier /squelettesQui dit mieux ?
Je me fais un petit récapitulatif du coup.
J'aime bien les idées de renommer :
extensions en plugins-X où X peut être «core» ou «dist» ou je ne sais pas quel joli nom...
J'aime bien l'idée de renommer squelettes/ en perso/, qui me semble plus logique également.
Je suis moins favorable à utiliser un répertoire themes/ vu que ce sont également des plugins en fin de compte.
On aurait donc :
perso/
plugins/ (squelettes / thèmes / fonctionnalités nouvelles)
plugins-core/ (la même chose, fournis avec cette distribution de SPIP, et non désactivables)
MM.
+10000
Bien qu'un conseil au détour d'un échange est toujours bon à prendre 
Pat
+10001
Pat
Coucou,
- d’un « thème » qui est {grosso modo} une feuille de style CSS (et ses fichiers graphiques), disponible sous cette forme ou sous forme de fichier zip prêt à l’emploi, dit « plugin »
- d’un jeu de « squelettes » plus ou moins complet, qui est constitués de fichiers générant le site public, généralement html, mais incluant parfois un thème et disponible sous la forme d’un dossier ou sous forme de fichier zip prêt à l’emploi, dit « plugin »
- de « plugins » qui ajoutent des fonctionnalités à SPIP, distribués sous forme de fichier zip prêt à l’emploi, dit « plugin »
Disons un « module fonctionnel » qui est lui aussi distribué en plugin. A ce propos d’ailleurs, jene comprends pas pourquoi on distribue encore des squelettes non plugin ?
- il faut aussi mentionner les « extensions », qui sont en fait des « plugins » et « squelettes » (faut pas oublier la « dist »), mais nommées différemment car distribuées d’office avec SPIP
Non ce n’est pas au même plan.
Les extensions sont des themes, squelettes ou modules fonctionnels qui sont distribués en plugin mais dont il n’est pas possible de désactiver le fonctionnement (sauf à mettre les mains dans le ftp).
On pourrait donc les installer ailleurs (dans plugins/ par ex), l’existence du répertoire extensions/ tenant plus du mécanisme de verrouillage que du concept.
Pour ne rien simplifier, les répertoires à la racine d’un projet SPIP, s’ils portent les mêmes noms ont un rôle qui ne correspond par tout à fait :
/themes : contient des « thèmes » mais uniquement sous forme de « plugins » et uniquement Z-compatible !
Themes/ n’est pas un répertoire SPIP. On peut s’en passer aujourd’hui car même Zen garden sait trouver les thèmes dans plugins/.
/squelettes : contient des fichiers de tout type (mais jamais de « squelettes » ou « thèmes » distribués sous forme de « plugins » !) et pas seulement des squelettes, contrairement à ce que son nom laisse entendre. C’est le répertoire des surcharges ultimes, pour tout, squelettes, thèmes css, mais aussi pour construire les pages de l’interface d’administration, si, j’vous jure…
Je milite depuis longtemps avec James pour l’appeler perso/, donc on est d’accord.
Et je renouvèle mon idée de distribuer tous les squelettes en plugin afin de pouvoir laisser ce répertoire perso/ pour les seules… personnalisations.
Je suggère vivement qu’on adopte des termes différents pour désigner les « trucs qu’on ajoute » et leur nature.
Par exemple, on pourrait alors expliquer de façon moins confuse, que SPIP est complété par 4 types d’« extensions » :
- « thème »
- « squelettes »
- « plugins »
- « plugins du core »
Ben oui, c’est déjà dans les catégorie : theme, squelette et toutes les autres pour les « modules fonctionnels ».
Plugins du core comme dit plus haut n’est pas une typologie à garder car cela désigne initialement (lors de l’install) la distribution de SPIP choisie et ensuite, la liste des plugins que le webmestre veut absolument protéger de toute désactiviation.
les répertoires correspondants seraient :
/themes : plutôt au singulier, puisqu’on n’en utilise qu’un seul à la fois, non ?
/squelettes : historique, conservé pour rétrocompat, mais à réserver aux squelettes
/plugins : comme d’hab
/plugins-core : pour remplacer l’actuel /extensionset
/perso : dossier de surcharge ultime, qui fonctionnerait donc comme notre actuel dossier /squelettes
Donc en conclusion sur les répertoires :
Je rappelle que j'ai tenté de définir explicitement ce qui signifiait une "extension" actuellement en 2.1, et ce que ça pourrait (mieux !) signifier plus tard dans la prochaine version.
http://blog.smellup.net/spip.php?article33
Je préconisais alors de *tout* mettre dans plugins/, mais d'avoir un fichier déclaratif explicite ("distribution.xml" est un exemple) qui indiquerait lesquels :
- sont installés par défaut et *non désactivables* (verrouillés dit la nouvelle terminologie de SVP)
- sont installés par défaut mais désactivables
Après il faut "juste" que SVP et l'admin de plugin en général (car ça doit être dans le core, pas dans SVP) sache lire ce fichier et interdise toute opération sur ce qui a été déclaré comme intouchable.
Salut !
Oui, c'est aussi ce que j'avais comme idée derrière la tête, mais que je n'ai pas osé ajouter en fin de mon mail avec, dans l'ordre :
/plugins/core
/plugins
/squelettes (à maintenir uniquement pour rétrocompat)
/perso
Remarque en passant : la notion de « thème » n'existant pas dans SPIP puisqu'elle est pour l'instant propre à Z, il n'y a pas lieu de la documenter ni d'en prévoir le sousrep, sauf pour anticiper (reste encore à savoir sur quoi ?), sans oublier qu'un « thème » peut exister hors Z et même hors SPIP.
-- romy