! [spip-dev] Un système de plugins

Dev
1

Salut,

c'est le retour des plugins et des points d'entree, voyez :
http://trac.rezo.net/trac/spip/changeset/4883

Pour les points d'entrée, j'ai essayé de faire quelque chose de simple, qui
généralise, d'une certaine manière, ce qu'on fait pour les traitements
standards des balises (dans inc-compilo-api).

Pour ce qui concerne les plugins, c'est l'architecture la plus simple, là
aussi, qui a été choisie : un répertoire /plugins/ ; il faudra l'étendre de
manière à ce qu'elle fonctionne avec les find_in_path() etc, mais dans un
premier temps je préfère ne pas compliquer les choses.

1) les "points d'entree", a.k.a. "pipelines"

On définit pour chaque "point d'entrée", dans le code de SPIP, une chaîne de
traitements (que j'ai appelé pipeline, mais on peut sans doute changer de
denomination si vous avez une meilleure idée), sous la forme d'une suite de
fonctions à appliquer.

Les cinq premiers points d'entrée sont les suivants :

$spip_pipeline = array(
        'pre_typo' => array('extraire_multi'),
        'post_typo' => array('quote_amp'),
        'pre_propre' => array('extraire_multi'),
        'post_propre' => array(),
        'post_syndication' => array()
);

Aux cinq endroits qui vont bien dans le code (c'est-à-dire, respectivement,
au début de la fonction typo, à la fin de la fonction typo, au début de la
fonction propre, à la fin de la fonction propre, et à la fin de l'entree en
BDD d'un nouvel article syndiqué), on insère l'appel suivant :

        $letexte = pipeline('pre_typo', $letexte);

en indiquant le nom du pipeline, éventuellement une entrée, et
éventuellement un résultat.

Le pipeline execute ensuite toutes les fonctions listees dans le tableau
$spip_pipeline pour l'action demandée.

2) les "plugins"

à la racine du site, dans /plugins/, se trouvent une série de
sous-répertoires. Chaque sous-répertoire est un "plugin", qu'on peut activer
ou désactiver à la demande.

Un "plugin" est composé obligatoirement d'un fichier version.php, qui (pour
chaque plugin actif) sera chargé à chaque hit ; ce fichier doit être le plus
léger possible.

SPIP commence par charger ecrire/mes_options.php3, qui peut définir un
tableau des plugins à charger, par exemple :
        $plugins = array('smallcaps', 'revision_nbsp', 'podcast_client');

Ensuite SPIP charge /plugins/smallcaps/version.php, puis
/plugins/revision_nbsp/version.php etc.

Le fichier version.php peut manipuler les variables courantes, et donc, en
particulier, modifier les pipelines (mais ce n'est pas la seule manière pour
un plugin d'agir).

Par exemple podcast_client/version.php va inserer le traitement (la
fonction) podcast_client dans le pipeline du point d'entrée
"post_syndication", en faisant :

        $spip_pipeline['post_syndication'][] = 'podcast_client';

3) la matrice des fichiers définissant les fonctions

ce qui précède ne suffit pas totalement, car comme cette fonction est
grosse, on ne va pas la définir dans version.php ; on va en revanche
indiquer à SPIP où il pourra trouver la défintion de cette fonction, s'il en
a besoin. Cela se fait en l'indiquant dans la variable globale $spip_matrice

        # la matrice standard (fichiers definissant les fonctions a inclure)
        $spip_matrice = array ();

version.php dit donc :
$spip_matrice['podcast_client'] = dirname(__FILE__).'/podcast_client.php';

et, quand SPIP aura besoin de cette fonction dans un pipeline, il saura
qu'il doit charger /plugins/podcast_client/podcast_client.php

4) ToDo publique : ce que vous pouvez faire

* avec cette architecture, je pense qu'il est facile de créer des plugins
dès maintenant, en sinspirant de ceux qui y sont déjà ; on verra à l'usage
les limites du modèle, qui est volontairement assez minimaliste (pas de
programmation objet, par exemple) pour permettre à n'importe quel
programmeur du dimanche d'essayer sans être rebuté par les aspects formels.
On peut déjà commencer sur SPIP Zone.

* il devrait être assez aisé aussi d'ajouter une interface graphique de
sélection (activation/désactivation) des plugins, puisqu'ils sont bien
rangés dans /plugins/ ; il faut peut-être prévoir un fichier de
documentation par plugin, et pourquoi pas un fichier spécifique
d'installation dans des cas particuliers, qui permettraient à cette
interface graphique de montrer quelque chose à l'utilisateur (et pas juste
le nom du plugin)

* il faudra, au fur et à mesure que des besoins s'expriment, trouver les
bons endroits où insérer les points d'entrée. Le faire de son côté ne
requiert qu'un patch d'une ligne à chaque fois, ce qui permet quand même de
pas mal expérimenter sans tout casser.

-- Fil

2

Salut,

c'est le retour des plugins et des points d'entree, voyez :
http://trac.rezo.net/trac/spip/changeset/4883

ouais !!!

1) les "points d'entree", a.k.a. "pipelines"
$spip_pipeline = array(
        'pre_typo' => array('extraire_multi'),
        'post_typo' => array('quote_amp'),
        'pre_propre' => array('extraire_multi'),
        'post_propre' => array(),

  Plutôt que d'avoir des pre et post typo et propre, pourquoi ne pas
avoir un pipeline "typo" et un autre "propre", contenant par défaut
array('typo') et array('propre') ?
  Ça permettrait de gérer typo et propre comme des plugins, et donc de
pouvoir les remplacer par autre chose si on veut, tout en permettant
de mettre des trucs avant/après.

2) les "plugins"
Le fichier version.php peut manipuler les variables courantes, et donc, en
particulier, modifier les pipelines (mais ce n'est pas la seule manière pour
un plugin d'agir).

  Si on ajoute une interface graphique par dessus, ça veut dire
qu'idéalement il faudrait générer le contenu de version.php en fonction
de ce qu'on a coché dans l'interface. Sinon, ce fichier devra aller
chercher des infos en bdd ou dans un autre fichier (quoique, un include
d'un fichier autogénéré posé à coté, c'est pas la mort).

3) la matrice des fichiers définissant les fonctions

  Sympa cette idée !
  On pourrait peut être la généraliser pour les fonctions de balises, ce
qui éviterait le coup de la balise #public.
  Ça permettrait également de définir des boucles, balises, critère
supplémentaires sans les mettre à chaque fois dans mes_fonctions.

4) ToDo publique : ce que vous pouvez faire

* il devrait être assez aisé aussi d'ajouter une interface graphique de
sélection (activation/désactivation) des plugins, puisqu'ils sont bien
rangés dans /plugins/

  Pour ça, il faudrait pouvoir déterminer pour chaque plugin, les
fonctions qu'il définit et les pipelines dans lesquelles on peut les
insérer. On pourrait alors contrôler le tableau pipeline de façon
centralisée par cette interface.

; il faut peut-être prévoir [...] un fichier spécifique
d'installation dans des cas particuliers

pas facile ça : à quel moment ce fichier sera il exécuté ? s'il
est interactif, comment gérer les enchaînements ?

* il faudra, au fur et à mesure que des besoins s'expriment, trouver les
bons endroits où insérer les points d'entrée.

Déjà, les endroits où il y a des "if(!function_exists(..)) include ..."
comme pour chercher_squelettes par exemple.

3

Grandiose, j’ai hate d’essayer ça …

Si j’osais, je dirais qu’il ne manque plus qu’un point d’entrée dans l’interface d’admin pour permettre l’ajout de pages d’admin liées aux plugin.
Peut-être faut-il penser à un menu « plug-in » (genre « suivre la vie du site ») dans lequel se ferait le point d’entrée.
C’est à mon avis le point qui reste bloquant pour ajouter un plugin avec fonctionnalités d’admin, sans devoir toucher au noyau.

Pour le reste, je crois que on va avoir maintenant pas mal de degré de liberté.

Salutations,
CM

Fil fil@rezo.net
Envoyé par : spip-dev-bounces@rezo.net

19/10/2005 17:04

A
spip-core@rezo.net

cc

Objet
! [spip-dev] Un système de plugins

Salut,

c'est le retour des plugins et des points d'entree, voyez :
http://trac.rezo.net/trac/spip/changeset/4883

Pour les points d'entrée, j'ai essayé de faire quelque chose de simple, qui
généralise, d'une certaine manière, ce qu'on fait pour les traitements
standards des balises (dans inc-compilo-api).

Pour ce qui concerne les plugins, c'est l'architecture la plus simple, là
aussi, qui a été choisie : un répertoire /plugins/ ; il faudra l'étendre de
manière à ce qu'elle fonctionne avec les find_in_path() etc, mais dans un
premier temps je préfère ne pas compliquer les choses.

1) les "points d'entree", a.k.a. "pipelines"

On définit pour chaque "point d'entrée", dans le code de SPIP, une chaîne de
traitements (que j'ai appelé pipeline, mais on peut sans doute changer de
denomination si vous avez une meilleure idée), sous la forme d'une suite de
fonctions à appliquer.

Les cinq premiers points d'entrée sont les suivants :

$spip_pipeline = array(
'pre_typo' => array('extraire_multi'),
'post_typo' => array('quote_amp'),
'pre_propre' => array('extraire_multi'),
'post_propre' => array(),
'post_syndication' => array()
);

Aux cinq endroits qui vont bien dans le code (c'est-à-dire, respectivement,
au début de la fonction typo, à la fin de la fonction typo, au début de la
fonction propre, à la fin de la fonction propre, et à la fin de l'entree en
BDD d'un nouvel article syndiqué), on insère l'appel suivant :

$letexte = pipeline('pre_typo', $letexte);

en indiquant le nom du pipeline, éventuellement une entrée, et
éventuellement un résultat.

Le pipeline execute ensuite toutes les fonctions listees dans le tableau
$spip_pipeline pour l'action demandée.

2) les "plugins"

à la racine du site, dans /plugins/, se trouvent une série de
sous-répertoires. Chaque sous-répertoire est un "plugin", qu'on peut activer
ou désactiver à la demande.

Un "plugin" est composé obligatoirement d'un fichier version.php, qui (pour
chaque plugin actif) sera chargé à chaque hit ; ce fichier doit être le plus
léger possible.

SPIP commence par charger ecrire/mes_options.php3, qui peut définir un
tableau des plugins à charger, par exemple :
$plugins = array('smallcaps', 'revision_nbsp', 'podcast_client');

Ensuite SPIP charge /plugins/smallcaps/version.php, puis
/plugins/revision_nbsp/version.php etc.

Le fichier version.php peut manipuler les variables courantes, et donc, en
particulier, modifier les pipelines (mais ce n'est pas la seule manière pour
un plugin d'agir).

Par exemple podcast_client/version.php va inserer le traitement (la
fonction) podcast_client dans le pipeline du point d'entrée
"post_syndication", en faisant :

$spip_pipeline['post_syndication'][] = 'podcast_client';

3) la matrice des fichiers définissant les fonctions

ce qui précède ne suffit pas totalement, car comme cette fonction est
grosse, on ne va pas la définir dans version.php ; on va en revanche
indiquer à SPIP où il pourra trouver la défintion de cette fonction, s'il en
a besoin. Cela se fait en l'indiquant dans la variable globale $spip_matrice

# la matrice standard (fichiers definissant les fonctions a inclure)
$spip_matrice = array ();

version.php dit donc :
$spip_matrice['podcast_client'] = dirname(__FILE__).'/podcast_client.php';

et, quand SPIP aura besoin de cette fonction dans un pipeline, il saura
qu'il doit charger /plugins/podcast_client/podcast_client.php

4) ToDo publique : ce que vous pouvez faire

* avec cette architecture, je pense qu'il est facile de créer des plugins
dès maintenant, en sinspirant de ceux qui y sont déjà ; on verra à l'usage
les limites du modèle, qui est volontairement assez minimaliste (pas de
programmation objet, par exemple) pour permettre à n'importe quel
programmeur du dimanche d'essayer sans être rebuté par les aspects formels.
On peut déjà commencer sur SPIP Zone.

* il devrait être assez aisé aussi d'ajouter une interface graphique de
sélection (activation/désactivation) des plugins, puisqu'ils sont bien
rangés dans /plugins/ ; il faut peut-être prévoir un fichier de
documentation par plugin, et pourquoi pas un fichier spécifique
d'installation dans des cas particuliers, qui permettraient à cette
interface graphique de montrer quelque chose à l'utilisateur (et pas juste
le nom du plugin)

* il faudra, au fur et à mesure que des besoins s'expriment, trouver les
bons endroits où insérer les points d'entrée. Le faire de son côté ne
requiert qu'un patch d'une ligne à chaque fois, ce qui permet quand même de
pas mal expérimenter sans tout casser.

-- Fil

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

4

  Plutôt que d'avoir des pre et post typo et propre, pourquoi ne pas
avoir un pipeline "typo" et un autre "propre", contenant par défaut
array('typo') et array('propre') ?

tout à fait d'accord, la difficulté dans un premier temps est que ces
fonctions sont une concatenation de fonctions à plusieurs variables bien
compliquées... mais oui, dans l'idéal il faudraréussir à faire ça

  Si on ajoute une interface graphique par dessus, ça veut dire
qu'idéalement il faudrait générer le contenu de version.php en fonction
de ce qu'on a coché dans l'interface. Sinon, ce fichier devra aller
chercher des infos en bdd ou dans un autre fichier (quoique, un include
d'un fichier autogénéré posé à coté, c'est pas la mort).

Non, il y a un version.php par plugin. Si le plugin est activé, ce
version.php est appelé, sinon non. Ce qu'il faudra générer (sur disque ou en
base ?) c'est la liste des plugins actifs (actuellement $plugins = array();
surchargeable dans mes_options.php3)

> 3) la matrice des fichiers définissant les fonctions
  Sympa cette idée !
  On pourrait peut être la généraliser pour les fonctions de balises, ce
qui éviterait le coup de la balise #public.

je ne suis pas sûr de voir e que tu veux dire, mais oui on peut généraliser
l'usage de cette matrice aux filtres, par exemple. A l'endroit où l'on fait
if (function_exists($filtre)) ajouter une vérif sur la matrice.

  Ça permettrait également de définir des boucles, balises, critère
supplémentaires sans les mettre à chaque fois dans mes_fonctions.

ça en fait c'est un simple point d'entrée à ajouter dans inc-compilo :
pipeline('compilo', $rien) => appelle des fonctions qui appellent des
fichiers qui définissent des balises, boucles etc. C'est à ça que tu penses?

> 4) ToDo publique : ce que vous pouvez faire

> * il devrait être assez aisé aussi d'ajouter une interface graphique de
> sélection (activation/désactivation) des plugins, puisqu'ils sont bien
> rangés dans /plugins/
  Pour ça, il faudrait pouvoir déterminer pour chaque plugin, les
fonctions qu'il définit et les pipelines dans lesquelles on peut les
insérer. On pourrait alors contrôler le tableau pipeline de façon
centralisée par cette interface.

Non, justement c'est là le piège : chaque plugin doit avoir l'intelligence
de savoir où il doit se fixer. Ce n'est pas à l'utilisateur de dire "telle
fonction se branche à tel endroit". Bref, plus quelque chose qui ressemble à
un système de cartouches de jeux vidéos qu'à un kit d'électronique, si tu
vois ce que je veux dire.

> ; il faut peut-être prévoir [...] un fichier spécifique
> d'installation dans des cas particuliers
pas facile ça : à quel moment ce fichier sera il exécuté ? s'il
est interactif, comment gérer les enchaînements ?

regarde dans sedna, on crée un champ supplémentaire dans la table
spip_auteurs ; il n'y a rien de spécial dans le code : si le champ n'existe
pas il le crée et puis c'est tout. Pour des cas plus complexes, bon, il faut
peut-être un script d'install, mais on ne peut pas deviner à priori quelle
méthode il faudra employer, tant qu'on n'a pas de cas réel à traiter.

> * il faudra, au fur et à mesure que des besoins s'expriment, trouver les
> bons endroits où insérer les points d'entrée.
Déjà, les endroits où il y a des "if(!function_exists(..)) include ..."
comme pour chercher_squelettes par exemple.

oui, pourquoi pas, dis-moi ce que tu arrives à faire avec ça ; je vais aussi
essayer de passer safehtml() en plugin

une autre idée c'est d'en ajouter un après chaque action qui pourrait
appeler, par exemple, une notification

-- Fil

5

Fil wrote:

[...]

Excellent et prometteur :slight_smile:

* il devrait être assez aisé aussi d'ajouter une interface graphique de
sélection (activation/désactivation) des plugins, puisqu'ils sont bien
rangés dans /plugins/ ; il faut peut-être prévoir un fichier de
documentation par plugin, et pourquoi pas un fichier spécifique
d'installation dans des cas particuliers, qui permettraient à cette
interface graphique de montrer quelque chose à l'utilisateur (et pas juste
le nom du plugin)

Pourquoi ne pas avoir un fichier meta.php par ex qui serait appelé dans la
page d'administration des plugins qui ressemblerait à la page de la zone
"Administration du site" et qui permettrait de gérer le activé / désactivé.

Pour lister le contenu de cette page, il "suffirait" de parcourir lister les
répertoires présents dans /plugins/ et de récupérer chaque fichier meta.php

Meta.php contiendrait :
- titre du plugin
- description du plugin
- statut : activé/désactivé

Mes 2 sous,
Nicolas

6

Fil a écrit :

SPIP commence par charger ecrire/mes_options.php3, qui peut définir un
tableau des plugins à charger, par exemple :
        $plugins = array('smallcaps', 'revision_nbsp', 'podcast_client');

Ensuite SPIP charge /plugins/smallcaps/version.php, puis
/plugins/revision_nbsp/version.php etc.

Le fichier version.php peut manipuler les variables courantes, et donc, en
particulier, modifier les pipelines (mais ce n'est pas la seule manière pour
un plugin d'agir).

Par exemple podcast_client/version.php va inserer le traitement (la
fonction) podcast_client dans le pipeline du point d'entrée
"post_syndication", en faisant :

        $spip_pipeline['post_syndication'] = 'podcast_client';

3) la matrice des fichiers définissant les fonctions

ce qui précède ne suffit pas totalement, car comme cette fonction est
grosse, on ne va pas la définir dans version.php ; on va en revanche
indiquer à SPIP où il pourra trouver la défintion de cette fonction, s'il en
a besoin. Cela se fait en l'indiquant dans la variable globale $spip_matrice

        # la matrice standard (fichiers definissant les fonctions a inclure)
        $spip_matrice = array ();

version.php dit donc :
$spip_matrice['podcast_client'] = dirname(__FILE__).'/podcast_client.php';

et, quand SPIP aura besoin de cette fonction dans un pipeline, il saura
qu'il doit charger /plugins/podcast_client/podcast_client.php

Super !

7

Pourquoi ne pas avoir un fichier meta.php par ex qui serait appelé dans la
page d'administration des plugins qui ressemblerait à la page de la zone
"Administration du site" et qui permettrait de gérer le activé / désactivé.

Pour lister le contenu de cette page, il "suffirait" de parcourir lister les
répertoires présents dans /plugins/ et de récupérer chaque fichier meta.php

Meta.php contiendrait :
- titre du plugin
- description du plugin

Oui, je pensais aussi à un truc comme ça, mais en imaginant que version.php
pourrait suffire à rendre ce service. Cela dit tu as probablement raison,
car si on met la description (multilingue !) dans version.php, on perd le
caractère "très léger" de ce fichier.

- statut : activé/désactivé

non, ce statut ne peut pas être dans le plugin, par définition.

-- Fil

8

Fil wrote:

- statut : activé/désactivé

non, ce statut ne peut pas être dans le plugin, par définition.

En effet, j'ai été maladroit dans mes propos, en fait c'est plutôt le
contenu de la boite "plugin" que j'avais en tête quand j'ai écrit ça.

Elle contiendrait :
- nom plugin
- description
- bouton radio permettant d'activer / désactiver le plugin

Nicolas

9

repost suite à erreur de destinataire ...

SPIP commence par charger ecrire/mes_options.php3, qui peut définir un
tableau des plugins à charger, par exemple :
        $plugins = array('smallcaps', 'revision_nbsp', 'podcast_client');
....
il devrait être assez aisé aussi d'ajouter une interface graphique de
sélection (activation/désactivation) des plugins, puisqu'ils sont bien
rangés dans /plugins/ ;

Mes 2 sous pour intégrer ce point dans l'admin,

en gardant la procédure la moins intrusive possible :
1/ je pose mon plugin avec tous les fichiers qui vont bien
2/ j'ouvre la page de gestion des plugins dans l'admin (à créer)
- elle charge le tableau des plugin actifs (stocké dans un ficher
inc_plugin.php à la racine de plugin par exemple)
- liste les sous répertoires de /plugins et vérifie la présence des
fichiers (inc_version ....)
- compare avec le tableau des actifs
- si un nouveau plugin est détecté il est affiché et un bouton permet
de l'activer , ajout du répertoire dans le fichier inc_plugin.php
- si un répertoire est endomagé ou disparu le signale et met le
fichier inc_plugin à jour. (évite les plantageau cas où)
- pour les plugin actif un bouton permet de les désactiver (ou
carrément les supprimer)

Le fichier inc_plugin est appelé par inc_version. (pas de vérif pour
gaion de temps car il peut toujours y avoir au départ un fichier avec
déclaration d'un tableau vide).
Il peut contenir :
- soit la déclaration en masse du tableau
  $plugins = array('smallcaps', 'revision_nbsp', 'podcast_client');

- soit des ligne d'ajout (une par plugin) du style
$plugins='smallcaps'; la désactivation pouvant alors être une bête
mise en commentaire. (facile à faire avec une regex)

Si ça convient je peux écrire ça rapido.
a+

10

Le fichier inc_plugin est appelé par inc_version. (pas de vérif pour
gaion de temps car il peut toujours y avoir au départ un fichier avec
déclaration d'un tableau vide).

Non, je n'aime pas cette idée d'avoir un fichier executable écrit par le
système ; on a déjà meta_cache et ça engendre des problèmes de temps à
autres, pas la peine d'en rajouter. par contre, hum... ça pourrait peut-être
aller dans ce fameux meta_cache...

Il peut contenir :
- soit la déclaration en masse du tableau
  $plugins = array('smallcaps', 'revision_nbsp', 'podcast_client');

on peut avoir un fichier ecrire/data/plugins.txt qui contienne juste

"""
smallcaps
revision_nbsp
podcast_client
"""

et qui soit lu via $plugins = file(data/plugins.txt)
Ce n'est pas exécutable, donc moins fragile ; mais pas certain que ça soit
la bonne solution, car ecrire/data/ est censé pouvoir être effaçable sans
dommages. Peut-être aussi stocker les valeurs dans la table spip_meta ?

Si ça convient je peux écrire ça rapido.

Quoi qu'il en soit si déjà tu écris la page qui liste les plugins et affiche
l'interface qui les sélectionne etc, le format de sortie peut être amélioré
par la suite, donc go!

-- Fil

11

- bouton radio permettant d'activer / désactiver le plugin

peut-être pas l'interface complète, mais une description des libellés "on"
et "off", par exemple

        "on" => "Activer le client de podcast"
        "off" => "Ne pas activer le client de podcast"

la page d'activation s'occuperait de gérer l'interface proprement dite (avec
des valeurs par défaut pour les flemmards)

-- Fil

12

Non, je n'aime pas cette idée d'avoir un fichier executable écrit par le
système ;

heu .. le cache de squelettes c'est quoi ? :wink:

on a déjà meta_cache et ça engendre des problèmes de temps à
autres, pas la peine d'en rajouter. par contre, hum... ça pourrait peut-être
aller dans ce fameux meta_cache...

  donc dans la table spip_meta ?
  genre deux entrées : plugins installés et plugins actifs. On sait
alors déduire de ces listes et du résultat du "ls /plugins" la liste des
plugins apparus/disparus/inactifs.
  why not

13

> on a déjà meta_cache et ça engendre des problèmes de temps à
> autres, pas la peine d'en rajouter. par contre, hum... ça pourrait peut-être
> aller dans ce fameux meta_cache...
  donc dans la table spip_meta ?
  genre deux entrées : plugins installés et plugins actifs. On sait
alors déduire de ces listes et du résultat du "ls /plugins" la liste des
plugins apparus/disparus/inactifs.

ça paraît pas mal.

  why not

le petit hic avec le stockage en BDD, c'est quand tu importes une base sur
un autre site où il te manque des plugins. Mais en refaisant un ls /plugins/
à chaque écriture du meta_cache ça devrait rouler (on ne veut pas le faire à
chaque hit, bien entendu, pour des questions de perfs)

-- Fil

14

> > on a déjà meta_cache et ça engendre des problèmes de temps à
> > autres, pas la peine d'en rajouter. par contre, hum... ça pourrait peut-être
> > aller dans ce fameux meta_cache...
> donc dans la table spip_meta ?
> genre deux entrées : plugins installés et plugins actifs. On sait
> alors déduire de ces listes et du résultat du "ls /plugins" la liste des
> plugins apparus/disparus/inactifs.

ça paraît pas mal.

Moi aussi, mais je ne vois pas l'intéré d'avoir un liste des plugin
inactif, c'est un plugin qui est dans le répertoire est qui n'est pas
actif.
par contre un liste des plugins en erreur peut être remplie
éventuellement pour renseigner l'admin sur un plugin défaillant ou
manquant. elle est automatiquement mise en jour en fonction de l'écart
entre plugin actif et liste des répertoire.

> why not

le petit hic avec le stockage en BDD, c'est quand tu importes une base sur
un autre site où il te manque des plugins. Mais en refaisant un ls /plugins/
à chaque écriture du meta_cache ça devrait rouler (on ne veut pas le faire à
chaque hit, bien entendu, pour des questions de perfs)

La fonction de contrôle des plugins actifs peut être partagée et
ajoutée au début de la fonction de mise en cache de méta => la table
méta est mise à niveau avant son cache avant la maj du cache. Ca a le
mérite de faire peut d'interférence avec le reste de la gestion des
méta ..

le fichier mes options va donc juste lire la valeur du meta plugin
actifs pour créer son tableau de plugin via un explode.
Je vais essayer de prendre tout ça en compte dans mon ptit bout de
code pour avoir du concret à se mettre sous la dent ...

NB : le libellé et la description du plugin resteront lus à partir du
fichier du plugin à chaque appel de l'admin.

Je prend ça comme base de travail et j'essaie d'envoyer ça pour ce soir.

15

Dingue ca, tu quittes ton ecran quelques heures et en revenant,
paf, un systeme de plugin, ca fuse dans tous les sens, des points
d'entrée partout qui se profilent, y compris dans l'espace redaction,
une bonnes idées tous les 1/4 d'heure ...
MERCI !!!

Bon, j'essaye juste de mettre mon grain de sel en l'etat des reflexions
ayant un cas concret sous la main :

- installation des plugins :
l'idée d'utiliser un meta pour lister les plugins disponibles me semble
tres bonne.
Ca me parait aussi tres bien de lister les plugins actifs et qu'un
plugin ne soit pas activé automatiquement, mais uniquement lorsqu'on
l'active dans l'admin, certains plugins pouvant necessiter une
installation specifique ou un parametrage (par les interface qu'il ajoute).
Si je ne dis pas trop de betises, la mise à jour pourrait etre appelée à
la fin de ecrire_meta() et stocker uniquement le tableau serialisé
(mieux que de faire un explode à mon avis) des plugins dispo et corriger
si necessaire celle des actifs (si un plugin actif n'est pas dispo).
Comme ca, au pire, il suffit d'aller valider dans configuration quand on
transfere une base d'un site à l'autre (c'est en gros le meme probleme
avec la generation d'image, si on a GD2 sur le premier serveur et pas
sur le second, ca coince, on est bien obligé d'aller reconfigurer ...
sauf que la,la validation de n'importe quelle page de configuration
reglerait le pb)
Pour tout ce qui est label de configuration, ca pourrait peut etre juste
s'appuyer sur une normalisation tout simplement, non ?
On peut par exemple dire qu'un plugin vient avec un fichier lang du nom
de plugin_nomdurepertoire qui doit contenir "activer", "desactiver" ... et eventuellement un lien vers la page d'installation (si necessaire).
La page d'installation pourrait donc etre generée automatiquement en
fonction de la liste des plugins disponible (juste avec un parcours du
tableau) et actifs (pour cocher les bons radios boutons ...)
Il y a juste le cas du premier appel à regler : si le meta n'existe pas,
on appelle la fonction de mise à jour des plugins dispos.

Je ne sais pas si je suis clair ...
Sinon, je regarderai le boulot d'Arnaud et je ferai une version
organisée comme ca.

En tous cas, comme ca, ca couvre presque tous les besoins que j'ai eu
sur spipcarto SAUF :
l'insertion de petits morceaux d'interfaces dans les interfaces existantes.
Pour les formulaires et pour spipcarto, on a une liste des raccourcis
pour inserer les formulaires et cartes existants.
il faut pour l'instant faire une modif dans article_edit (ou xxx_edit)
Emmanuel a deja mis en place un truc avec inc_xxx (dans naviguer et
agenda je crois), il faudrait peut etre faire un mix des 2 en cherchant
un inc_xxx dans les repertoires plugins.
ou peut etre trouver un truc moins couteux comme les "point d'entrée".
J'ai regardé ni l'un ni l'autre serieusement, donc je n'ai pas d'avis,
mais par contre, j'ai le besoin ...
:stuck_out_tongue:

Merci pour tout ca en tous cas.

Je tache de passer spipcarto en plugin des que possible ... mais sans
doute pas avant 10/15j quand meme, sorry.

@++

16

je n'explode la liste qu'au moment de la comparer à a liste des fichiers.
ça me permet d'utiliser les fonctions de comparaison de tableau
array_diff, n'étant pas un pro du php je n'ai ucune idée des perf sur
ces fonctions.

detail ... mais bon, normalement, coté perf, c'est mieux, ca reste gerable à la main et surtout c'est beaucoup plus evolutif car tu peux aller vers des choses plus complexes comme un tableau à plusieurs dimensions.
Mais c'est simple à modifier, par urgent et vraiment un detail (j'ai dit grain de sel ... pas plus !)

Pour tout ce qui est label de configuration, ca pourrait peut etre juste
s'appuyer sur une normalisation tout simplement, non ?
On peut par exemple dire qu'un plugin vient avec un fichier lang du nom
de plugin_nomdurepertoire qui doit contenir "activer", "desactiver" ...
   

là je suis pas ? pourquoi 2 libellé
il suffit d'avoir le nom du plugin et 3 chaine dans le fichier de
langue standard ("actif" "inactif" pour les bouton et "en panne" s'il
était actif mais plus là.

Oui peut etre, Fil avait parlé du nom du plugin internationnalisé, c'etait en fait à ca que je pensais au debut,je me suis planté.
Mais c'est un detail,en gros, ce qui doit apparaitre dans l'administration des plugin doit, amha, reposer uniquement sur des conventions.
Mais laencore : detail.

et eventuellement un lien vers la page d'installation (si necessaire).
   
par convention on peut dire que si besoin il y a dedans un fichier config.php3

Heu, pourquoi imposer ca ?
Pourquoi tester quand on peut declarer et pourquoi imposer quand on peut etre souple.
Mots_partout et spipcarto repose aujourd'hui sur une installation sur leur interface principale + ?installation=oui
Si on veut integrer un autre truc deja fait, il faudrait se recoller un "adapteur" pour appeler l'installeur.
Tout cela n'est pas tres compliqué à faire ou à changer,mais pourquoi se l'imposer quand un lien suffit et qu'il peut etre optionnel ?
Maintenant, le mettre dans un fichier de langue, c'est peut etre pas ideal, mais c'est peut etre plus prudent (certains vont peut etre devoirpasser des parametres de langue en url,dautres avoirs des sous repertoires,d'autres des fichiers differents pour certaines langues ...)
C'etait simple et ouvert, maintenant, le lien peut peut etre se trouver dans un fichier conf dans le plugin.
Il y a ou il y aura forcement besoin d'un fichier normalisé autre que version.php pour poser des affaires, rien n'empeche alors de passer par un "accesseur" pour chercher les parametre, ce qui permet au besoin de faire des parametres calculés (das mon exemple en fonction de la langue, mais eventuellement en fonction de meta, de la presence d'autres plugins ...)

en poussant plus loin il faudra peut être créer des équiivalent de
constructeurs et destructeurs dans les répertoires du plugins.

??? pas compris pour quoi ?

La page d'installation pourrait donc etre generée automatiquement en
fonction de la liste des plugins disponible (juste avec un parcours du
tableau) et actifs (pour cocher les bons radios boutons ...)
Il y a juste le cas du premier appel à regler : si le meta n'existe pas,
on appelle la fonction de mise à jour des plugins dispos.
   
Je suis plutot sur un appel de la fonction de mise à jour avant
l'affichage pour être sur que la liste affichée est cohérente

Normalement,ca n'est necessaire qu'au premier appel je pense.

Je ne sais pas si je suis clair ...
   
mais si mais si

bon j'arrête mes bavardages et retourne à mon pov' code qui prend du retard :wink:

A priori, tout ce que je disais n'est que detail, trucs simples à modifier, et reflexion pour la suite : fonce !
Bon courage et merci
@++

17

>
>par convention on peut dire que si besoin il y a dedans un fichier config.php3
>
>
Heu, pourquoi imposer ca ?
Pourquoi tester quand on peut declarer et pourquoi imposer quand on peut
etre souple.
Mots_partout et spipcarto repose aujourd'hui sur une installation sur
leur interface principale + ?installation=oui

j'imposai rien c'est juste qu'il faudra bien trouver un moyen de
tansmettre le nom de l'interface principale non (mais vu l'heure le
neurone faiblit)

Si on veut integrer un autre truc deja fait, il faudrait se recoller un
"adapteur" pour appeler l'installeur.
Tout cela n'est pas tres compliqué à faire ou à changer,mais pourquoi se
l'imposer quand un lien suffit et qu'il peut etre optionnel ?

Faudra juste me donner plus de détail sur comment on récupère le lien
à insérer (c'est pour cela que je mettais un lien vers config s'il
existe et auquel on peut envoyer tout ses paramètres , ?installation,
configuration , désintégration.
S'il y a plus soule faut pas hésiter ..

Maintenant, le mettre dans un fichier de langue, c'est peut etre pas
ideal, mais c'est peut etre plus prudent (certains vont peut etre
devoirpasser des parametres de langue en url,dautres avoirs des sous
repertoires,d'autres des fichiers differents pour certaines langues ...)

Ah la réponse à ma question du dessus (

C'etait simple et ouvert, maintenant, le lien peut peut etre se trouver
dans un fichier conf dans le plugin.
Il y a ou il y aura forcement besoin d'un fichier normalisé autre que
version.php pour poser des affaires, rien n'empeche alors de passer par
un "accesseur" pour chercher les parametre, ce qui permet au besoin de
faire des parametres calculés (das mon exemple en fonction de la langue,
mais eventuellement en fonction de meta, de la presence d'autres plugins

je vais déjà mettre mes 2 petits boutons et un truc pour faire un lien
, on réfléchiera à partir de là,

de toute façon le code devrait pas être très long donc facile à
changer , c'est juste a base de travail.

...)

>en poussant plus loin il faudra peut être créer des équiivalent de
>constructeurs et destructeurs dans les répertoires du plugins.
>
>
??? pas compris pour quoi ?

c'est juste l'équvallent de ton ?installation

>
>
>>La page d'installation pourrait donc etre generée automatiquement en
>>fonction de la liste des plugins disponible (juste avec un parcours du
>>tableau) et actifs (pour cocher les bons radios boutons ...)

c'est bien ça , je parcours le répertoire pour lister les présent et
le champ meta me donne les actifs
je pensai rajouter aussi un "warning" sur ceux qui était actif mais
pas présent pour prévenir les erreurs (mais pas sur car ça complique
plus que ça ne simplifie ....)

>>Il y a juste le cas du premier appel à regler : si le meta n'existe pas,
>>on appelle la fonction de mise à jour des plugins dispos.

Normalement,ca n'est necessaire qu'au premier appel je pense.

C'est là que je me suis pris la tête pour voir quand faire la maj. Je
reprendrai ce point à une heure plus décente pour mon cerveau.

A priori, tout ce que je disais n'est que detail, trucs simples à
modifier, et reflexion pour la suite : fonce !

présentement je vais me coucher je ne vois puls mon clavier |-(

j'ai bien dégrossi le inc_plugin , l'admin_plugin prend forme donc à
suivre bientot.

si quelqu'un à une idée d'iconographie pour les plugins, le graphisme
est loin d'être mon fort.

Merci pour les compléments.

a+

18

Je reviens encore à la charge avec mon DotClear, mais si l’installation d’un plugin pouvait être aussi simple… copier / coller l’adresse d’un fichier, puis la lancer et le tour est joué : répertoires créés, fichiers copiers, plugin installé, admin installé, il n’y a plus qu’à aller sur la page de l’admin correspondante pour voir comme l’utiliser et le paramétrer… plus simple côté utilisateur : tu meurs… ce n’est que l’avis d’un utilisateur…

mon grain de sel…A+

Ventre Arnaud a écrit :

19

jl-grellier@cr-limousin.fr a écrit :

Je reviens encore à la charge avec mon DotClear, mais si l'installation d'un plugin pouvait être aussi simple.... copier / coller l'adresse d'un fichier, puis la lancer et le tour est joué : répertoires créés, fichiers copiers, plugin installé, admin installé, il n'y a plus qu'à aller sur la page de l'admin correspondante pour voir comme l'utiliser et le paramétrer... plus simple côté utilisateur : tu meurs... ce n'est que l'avis d'un utilisateur...

Bof, la, c'est pas bien compliqué non plus et c'est un peu mieux maitrisé :
tu fais le upload d'un dossier (tres pratique pour les contribs) et le plugin est installé (mais pas activé)
Dans l'administration, si necessaire, tu as un lien vers la page d'admin du plugin (ca, c'est ce qu'il me semble necessaire de rajouter, Arnaud avait l'air d'accord), mais dans beaucoup de cas,ca n'est meme pas necessaire, il y a juste à activer.

Ca n'empeche pas par la suite d'ajouter l'upload d'un zip depuis l'admin ou de faire l'equivalent d'un spip_loader,mais bon, normalement,le gars qui a installé spip a compris comment on servait se d'un FTP.
Et puis les installations directes depuis une URL, ca peux etre dangereux.
Pour un zip,il y a moins de risque, mais tu vas avoir des zips avec /plugin/monplugin, d'autres avec /monplugin ... enfin, de temps en temps, ca arrive.
Dernier point qui ne facilite pas forcement les choses, c'est les droits necessaire pour la creation de repertoires.
Pour l'instant, il n'y a que dans /cache que c'est necessaire. A priori, un plugin, c'est un truc qui n'a besoin que d'etre lu.

Voila, c'est sur qu'il faut aller au plus simple pour l'utilisateur, meme si c'est l'admin du site, mais c'est bien aussi d'etre sur qu'il sait ce qu'il fait...
@++

20

Nicolas Steinmetz wrote:

Pourquoi ne pas avoir un fichier meta.php

Et pourquoi pas avoir plutôt un fichier desc.xml qui contiendrait toute ces
données textuelles plutôt qu'un fichier php ?

En terme d'organisation cela pourrait être propre mais en terme de
traitement, je ne sais pas si ce serait plus lourd / moins lourd qu'un
simple fichier php...

Vos avis ?

Nicolas