[spip-dev] extensions vs plugins

Dev
1

Si je résume l'état des choses :

Les "extensions" actuelles sont des plugins :
1* chargés automatiquement,
2* actifs dès l'install du site,
3* qui ne sont désactivables que si on a accès aux fichiers.
4 Pour les distinguer des autres plugins, ces plugins sont dans le
répertoire extensions/
5 Ils sont livrés dans la distribution de SPIP dans un répertoire extensions/
6 Ils sont développés sur la zone.

Chacun de ces 6 points a ses raisons et ses avantages ; un gros
inconvénient est qu'il est malaisé de jouer avec les configurations
sans déplacer des tas de fichiers (7), et sur le plan théorique, qu'il
y a une sorte d'incohérence à rechercher tel contenu à tel emplacement
en fonction d'une donnée concernant son chargement automatique ou pas
(8).

Au final je trouve ça plutôt perturbant et je propose qu'on parte sur
une autre piste ; il s'agirait de définir dans inc_version.php un
tableau des plugins à charger en extensions.

$extensions = array ('compresseur', 'filtres_images', ...);

Lors de la création du chemin des plugins, on regarderait si ces
plugins sont présents dans le répertoire plugins/ ou un de ses
sous-répertoires, et on les activerait automatiquement. On
retrouverait donc 1, 2, 3, et on gagnerait 7 et 8, puisqu'il suffirait
d'indiquer par exemple, dans config/mes_options.php, quelque chose
comme :
    $extensions[] = 'crayons';
ou encore
    $extensions = array(); # SPIP, ton core !

Le point 4 peut se retrouver, pour qui le souhaite, en rangeant les
dites extensions dans plugins/extensions/

Le point 5, je ne suis pas certain, mais on peut probablement pour le
zip fourni à télécharger, livrer un répertoire plugins/ déjà peuplé.
Par contre en SVN à chacun de se débrouiller pour faire un checkout de
ce qu'il faut dans plugins/ ou plugins/extensions/ (ça réglerait aussi
une des difficultés dans le futur passage à git).

6 ne pose pas de problème.

à vous les studios

-- Fil

2

* Fil tapuscrivait, le 25/09/2010 10:32:

Si je résume l'état des choses :

Les "extensions" actuelles sont des plugins :
1* chargés automatiquement,
2* actifs dès l'install du site,
3* qui ne sont désactivables que si on a accès aux fichiers.
4 Pour les distinguer des autres plugins, ces plugins sont dans le
répertoire extensions/
5 Ils sont livrés dans la distribution de SPIP dans un répertoire extensions/
6 Ils sont développés sur la zone.

Chacun de ces 6 points a ses raisons et ses avantages ; un gros
inconvénient est qu'il est malaisé de jouer avec les configurations
sans déplacer des tas de fichiers (7), et sur le plan théorique, qu'il
y a une sorte d'incohérence à rechercher tel contenu à tel emplacement
en fonction d'une donnée concernant son chargement automatique ou pas
(8).

Au final je trouve ça plutôt perturbant et je propose qu'on parte sur
une autre piste ; il s'agirait de définir dans inc_version.php un
tableau des plugins à charger en extensions.

$extensions = array ('compresseur', 'filtres_images', ...);

Lors de la création du chemin des plugins, on regarderait si ces
plugins sont présents dans le répertoire plugins/ ou un de ses
sous-répertoires, et on les activerait automatiquement. On
retrouverait donc 1, 2, 3, et on gagnerait 7 et 8, puisqu'il suffirait
d'indiquer par exemple, dans config/mes_options.php, quelque chose
comme :
     $extensions = 'crayons';
ou encore
     $extensions = array(); # SPIP, ton core !

Le point 4 peut se retrouver, pour qui le souhaite, en rangeant les
dites extensions dans plugins/extensions/

Le point 5, je ne suis pas certain, mais on peut probablement pour le
zip fourni à télécharger, livrer un répertoire plugins/ déjà peuplé.
Par contre en SVN à chacun de se débrouiller pour faire un checkout de
ce qu'il faut dans plugins/ ou plugins/extensions/ (ça réglerait aussi
une des difficultés dans le futur passage à git).

6 ne pose pas de problème.

Pour ma part, le fait de pouvoir installer automatiquement un plugin juste en le plaçant dans extensions/ est assez pratique.

Et puis, je vois bien la situation d'un plugin "rootkit" qui aurait dans sont _options.php ce qu'il faut pour le considérer comme extension.
Du coup, il pourrait s'activer comme un plugin et ne serait jamais désactivable :wink:

-- RealET

3

La declaration dans un tableau par le prefixe a ses limites, dans le cas ou un meme plugin en plusieurs versions est disponible dans plugins/

Le checkout par SVN qui ne fournit pas une version standard me gêne aussi, mais j'ai l'impression que git ne va pas savoir faire dans tous les cas ?

4

La declaration dans un tableau par le prefixe a ses limites, dans le cas ou un meme plugin en plusieurs versions est disponible dans plugins/

Je vois mais l'argument est limité : que se passe-t-il si un même
plugin en plusieurs versions est disponible dans extensions/ ?

Le checkout par SVN qui ne fournit pas une version standard me gêne aussi, mais j'ai l'impression que git ne va pas savoir faire dans tous les cas ?

ça obligerait en effet à faire deux checkout, pour avoir les extensions.

Pour ma part, le fait de pouvoir installer automatiquement un plugin juste
en le plaçant dans extensions/ est assez pratique.

peut-être avec $extensions = glob("plugins/extensions/*") ; dans le
config/mes_options de ta mutu

Et puis, je vois bien la situation d'un plugin "rootkit" qui aurait dans
sont _options.php ce qu'il faut pour le considérer comme extension.
Du coup, il pourrait s'activer comme un plugin et ne serait jamais
désactivable :wink:

euh, sans doute ; mais est-ce que tu vois bien le plugin "poubelle"
qui fait sql_query('drop database'); dans son fichier options.php ?

-- Fil

5

Non, non c'est pas limité comme argument.
Actuellement, on sait que les extensions sont actives quel que soit le contenu du dossier plugins/
Donc quand un utilisateur dit "j'ai un bug" avec le spip sorti de la boite, on sait ce qui est actif et dans quelle version.

L'argument que je soulève, c'est que ce ne sera plus le cas. Si l'utilisateur a mis autre chose dans son dossier plugins/,
on ne peut pas être sur qu'une autre version du plugin n'est pas active a la place de celle qu'on a testé.
Ce qui me gêne donc, c'est que ce n'est pas déterministe, et qu'on ne sera pas sur de la configuration, même si l'utilisateur dit
"je n'ai activé aucun plugin"

Cédric

6

Donc quand un utilisateur dit "j'ai un bug" avec le spip sorti de la boite, on sait ce qui est actif et dans quelle version.
Ce qui me gêne donc, c'est que ce n'est pas déterministe, et qu'on ne sera pas sur de la configuration, même si l'utilisateur dit
"je n'ai activé aucun plugin"

Le cas se présente déjà un peu (peut-être un peu moins, c'est vrai),
et c'est à ça que sert l'entête X-Composed-By spip version + plugins
versions ; et le panel de plugins doit afficher clairement les infos
de version.

-- Fil

7

Je maintiens que ça n'est pas déterministe et que le simple fait de poser dans ton repertoire plugins/ une version dev d'un plugin déclaré par ailleurs en extensions pourra te faire planter ton site, ce qui est problématique.
Ce n'est pas un cas hypothétique, et ça empêche même d'avoir ton site qui tourne avec une version stable et d'avoir sous la main une version de dev.

La séparation dans un répertoire extensions/ permet à l'utilisateur d'être conscient que si il dépose un plugin dedans il touche au core et fait une manip particulière.
En mergeant tout dans un même répertoire, on perd cette notion et une manipulation anodine comme poser des plugins dans ton repertoire plugins/ peut casser ton site alors même que tu n'as rien activé nulle part. C'est cela qui ne va pas et qu'il faut résoudre.

Cédric

8

Je profite de la discussion pour soulever quelques questions :

- Que se passe-t-il lorsqu'une version plus récente d'une extention est disponible dans le répertoire plugin ? Autrement dit, supposons une extension en version 1.1. Puis-je activer une version 1.2 de cette extension que j'ai installer dans plugins, ou bien dois-je d'abord supprimer la version 1.1 du répertoire extension ?

- Je suppose que STEP ou un équivalent intégrera à terme le core. Un des grands intérêts de STEP c'est de pouvoir bénéficier automatiquement des mises à jours. Or, il y a tout intérêt à pouvoir aussi bénéficier des mises à jours pour les extensions, ce qui permet de pouvoir corriger des bugs dans les extensions sans avoir à attendre une prochaine version de SPIP.

- Les mises à jours dans STEP se basent à partir des zip et non à partir du SVN. Par contre, je ne sais pas comment Step gère la question des mises à jours quand il y a un zip à la fois pour une version 1.1 stable et une version 1.2 en développement.

Bref, le débat sur les extensions vs plugins dans les futurs versions de SPIP ne gagnerait-il pas à intégrer la dimension des mises à jours des extensions ?

Cordialement

Joseph

9

Ciao

La question de la version est déjà un problème à l'heure actuelle.

Dans le cas svn actuel, on charge la dernière version tagguée/branchée
des extensions, il suffit par la suite de faire un commit dessus pour
rendre inconsistant la version de l'extension.

Dans la solution de fil on peut ajouter l'information version pour
dire quel plugin à quelle version et être ainsi déterministe.

Dans le cas git, les solutions qu'on a vu (et qui reste encore un gros
chantier de réflexion) semblent plus précises on peut verrouiller
depuis le core la version de chaque extension.

Git ne devrait pas amener de complications complémentaires à l'instant
où on détermine bien la notion de core et de distribution.

Km

10

* RealET tapuscrivait, le 25/09/2010 10:44:

Et puis, je vois bien la situation d'un plugin "rootkit" qui aurait dans
sont _options.php ce qu'il faut pour le considérer comme extension.
Du coup, il pourrait s'activer comme un plugin et ne serait jamais
désactivable :wink:

Après réflexion, je vois un gros intérêt à la proposition de Fil dans le cadre d'une installation de SPIP mutualisée :
- la possibilité d'avoir dans le mes_options.php commun un lot d'extensions
- *et* la possibilité dans le mes_options spécifique d'un site de désactiver une de ces extensions, ou d'en activer d'autres

-- RealET