[spip-dev] structure plugin.xml

Dev
1

Salut,

Plus ça va, plus je me dis que plugin.xml a des insuffisances qui vont nous pourrir pendant un moment.

– Il y a des bouts de code HTML pour faire à la main des liens vers des pages de config, plutôt par exemple que d'avoir une balise dédié à cela. On se retrouve avec des liens «désactiver», «désinstaller» mis à la main dans le truc, des liens vers des pages internes de l'espace privé en relatif...

Pour des chevaliers de la séparation du fond et de la forme, je nous trouve assez légers. Le champ <descriptif> de plugin.xml est, de facto, actuellement inutilisable en dehors de l'espace privé. On ne peut pas en faire grand chose, par exemple, dans un flux RSS, parce que ce flux RSS contiendra des cochonneries.

Donc, à mon avis:

=> Il faut s'astreindre à ne pas avoir de liens vers des pages internes dans le descriptif. Un descriptif, c'est un descriptif. Il faut pouvoir l'utiliser ailleurs sans soucis. Pour le moment ça n'est vraiment pas le cas.

=> Ajouter un champ vers une page interne d'utilisation. Et avec ça on se fait le petit bouton aligné à droite comme pour Autorité. Genre:
<lien_config></lien_config>

=> <lien><lien> pour la doc officielle est une horreur: vous en avez fait du texte libre, ce qui rend ultra-risqué tout traitement automatiquement de ce champ. Il faudrait décider que <lien></lien est forcément une URL toute conne. Ca nous permettrait, comme pour la config, de faire un petit logo.

=> Mettre en œuvre un mécanisme de désactivation et de désinstallation séparé. Comme pour le reste: ce genre de chose n'a rigoureusement rien à faire dans descriptif, car ça n'est pas un descriptif et ça n'est pas exportable.

ARNO*

2

Salut,

Plus ça va, plus je me dis que plugin.xml a des insuffisances qui vont nous pourrir pendant un moment.

– Il y a des bouts de code HTML pour faire à la main des liens vers des pages de config, plutôt par exemple que d'avoir une balise dédié à cela. On se retrouve avec des liens «désactiver», «désinstaller» mis à la main dans le truc, des liens vers des pages internes de l'espace privé en relatif...

Pour des chevaliers de la séparation du fond et de la forme, je nous trouve assez légers. Le champ <descriptif> de plugin.xml est, de facto, actuellement inutilisable en dehors de l'espace privé. On ne peut pas en faire grand chose, par exemple, dans un flux RSS, parce que ce flux RSS contiendra des cochonneries.

Donc, à mon avis:

=> Il faut s'astreindre à ne pas avoir de liens vers des pages internes dans le descriptif. Un descriptif, c'est un descriptif. Il faut pouvoir l'utiliser ailleurs sans soucis. Pour le moment ça n'est vraiment pas le cas.

Descriptif est suceptible de contenir un bout de doc pour les plugins simples. Du coup on y passe propre pour permettre un peu de mise en forme, et cela a dérivé visiblement, à tort
Mais on peut sucrer tous les liens volontairement pour ne pas inciter ce gnere d'utilisation detournée.

=> Ajouter un champ vers une page interne d'utilisation. Et avec ça on se fait le petit bouton aligné à droite comme pour Autorité. Genre:
<lien_config></lien_config>

de toute façon, je ne trouve pas que ce soit une bonne idée d'avoir un lien vers la configuration ou autre depuis cet endroit.
On devrait plutot avoir un onglet plugins dans la page configuration, et permettre aux plugins de s'insérer là, il me semble.

=> <lien><lien> pour la doc officielle est une horreur: vous en avez fait du texte libre, ce qui rend ultra-risqué tout traitement automatiquement de ce champ. Il faudrait décider que <lien></lien est forcément une URL toute conne. Ca nous permettrait, comme pour la config, de faire un petit logo.

faisons cela

=> Mettre en œuvre un mécanisme de désactivation et de désinstallation séparé. Comme pour le reste: ce genre de chose n'a rigoureusement rien à faire dans descriptif, car ça n'est pas un descriptif et ça n'est pas exportable.

c'est déja le cas.
-> desactivation = decocher la checkbox
-> desinstallation = cliquer sur l'icone du paquet qui apparaît en bas à droite lorsqu'on affiche les détails d'un plugin installé.
La desintallation suppose que le plugin a implémenté les mécanismes d'install/upgrade/desinstall.
Les plugins qui font autrement que cela sont des mauvais élève, il n'y a aucun remord à avoir à sucrer leur lien.

Donc en résumé :
-> <lien> *doit* contenir une url exclusivement ; corrolairement, on peut mettre plusieurs balises lien
-> tous les <a> du descriptif seront sucrés à l'affichage du descriptif dans l'espace privé.

Cédric

3

cedric.morin@yterium.com a écrit :

-> desinstallation = cliquer sur l'icone du paquet qui apparaît en bas à droite lorsqu'on affiche les détails d'un plugin installé.

J'avais jamais compris à quoi sert ce paquet qui apparait mystérieusement
pour certains plugins.
J'espère qu'il y a une bulle d'info maintenant.

Sinon, les recommandations de Arno* m'apparaissent salutaires.

:slight_smile:

JL

4

JLuc a écrit :

cedric.morin@yterium.com a écrit :

-> desinstallation = cliquer sur l'icone du paquet qui apparaît en bas à droite lorsqu'on affiche les détails d'un plugin installé.

J'avais jamais compris à quoi sert ce paquet qui apparait mystérieusement
pour certains plugins.
J'espère qu'il y a une bulle d'info maintenant.

Il y a un "title" : "Supprime les données et désactive le plugin". Peut-être pas assez visible, mais bon ça joue son rôle de "title".

Le mécanisme est activé par <install> et le php correspondant, normalement tout est expliqué dans la doc technique. Typiquement, la partie "désinstallation" sert à vider ce qui a pu être mis en BDD, au lieu de juste "désactiver". Donc ça ne vaut logiquement pas pour tous les plugins.

http://doc.spip.org/@Plugin-xml#install
(j'ai mis quelques ancres dans la page)

Si ya des choses pas claires mais que vous avez comprises... ben faut les reformuler, c'est wiki :slight_smile:

5

Merci pour ces compléments..
@+
Yx
"RastaPopoulos" <vincent@ldd.fr> a écrit dans le message de news:
g7ri6p$b0t$1@ger.gmane.org...
JLuc a écrit :

cedric.morin@yterium.com a écrit :

-> desinstallation = cliquer sur l'icone du paquet qui apparaît en bas à
droite lorsqu'on affiche les détails d'un plugin installé.

J'avais jamais compris à quoi sert ce paquet qui apparait mystérieusement
pour certains plugins.
J'espère qu'il y a une bulle d'info maintenant.

Il y a un "title" : "Supprime les données et désactive le plugin".
Peut-être pas assez visible, mais bon ça joue son rôle de "title".

Le mécanisme est activé par <install> et le php correspondant,
normalement tout est expliqué dans la doc technique. Typiquement, la
partie "désinstallation" sert à vider ce qui a pu être mis en BDD, au
lieu de juste "désactiver". Donc ça ne vaut logiquement pas pour tous
les plugins.

http://doc.spip.org/@Plugin-xml#install
(j'ai mis quelques ancres dans la page)

Si ya des choses pas claires mais que vous avez comprises... ben faut
les reformuler, c'est wiki :slight_smile:

6

On pourrait peut-être calculer automatiquement les éléments qui sont
dans le fichier svn.revision à la racine des archives (ou inclure ses
infos)

<svn_revision><text_version>
Origine svn://zone.spip.org/spip-zone/_plugins_/_stable_/acces_restreint
le vendredi 1 août 2008, 13:31:19 (UTC+0200)
Revision: 21831
Dernier commit 2008-08-01 12:24:31 +0200 (Fri, 01 Aug 2008)
Voir http://trac.rezo.net/trac/spip-zone/browser/plugins/stable/acces_restreint
Archive: http://files.spip.org/spip-zone/acces_restreint_1_9.zip
</text_version>
<uri>http://trac.rezo.net/trac/spip-zone/browser/plugins/stable/acces_restreint</uri>
<archive>http://files.spip.org/spip-zone/acces_restreint_1_9.zip</archive>
<origine>svn://zone.spip.org/spip-zone/_plugins_/_stable_/acces_restreint</origine>
<date_production>vendredi 1 août 2008, 13:31:19 (UTC+0200)</date_production>
<revision>21831</revision>
<commit>2008-08-01 12:24:31 +0200 (Fri, 01 Aug 2008)</commit>
</svn_revision>
<archivelist>_plugins_/_stable_/acces_restreint;acces_restreint_1_9;acces_restreint_1_9</archivelist>

On pourrait commencer par le faire par les plugins "officiels" qui
téléchargeables automatiquement.

Qu'en dites-vous ?

.Gilles

7

Page blanche sur tentative de prévisualisation d'un article proposé sur
spip-contrib :
    http://www.spip-contrib.net/ecrire/?exec=articles&id_article=2666

Est-ce SPIP, le squelette de spip-contrib ou le serveur de spip-contrib ?

André Vincent

8

S'lt

pourrir pendant un moment.

Bien possible, on commence à avoir un probléme de passif historique
sur ce fichier.

=> Il faut s'astreindre à ne pas avoir de liens vers des pages internes dans
le descriptif. Un descriptif, c'est un descriptif. Il faut pouvoir
l'utiliser ailleurs sans soucis. Pour le moment ça n'est vraiment pas le
cas.

C'est lié au fait qu'au début on n'avait pas de possibilité d'ajouter
des boutons d'administration ou de lien vers un doc.
Maintenant nous avons des moyens ne plus avoir ce genre de truc dans
le descriptif.

=> Ajouter un champ vers une page interne d'utilisation. Et avec ça on se
fait le petit bouton aligné à droite comme pour Autorité. Genre:
<lien_config></lien_config>

Pas necessaire nous avons deja <bouton> et <onglet> qui permet
d'ajouter où l'on souhaite dans la barre de menu spip
http://doc.spip.org/@plugin-xml partie bouton et onglet

=> <lien><lien> pour la doc officielle est une horreur: vous en avez fait du
texte libre, ce qui rend ultra-risqué tout traitement automatiquement de ce
champ. Il faudrait décider que <lien></lien est forcément une URL toute
conne. Ca nous permettrait, comme pour la config, de faire un petit logo.

bah là, le nommage est de la balise est assez explicite, si les dev de
plugins ne suivent pas les recommandations on ne peut faire grand
chose

=> Mettre en œuvre un mécanisme de désactivation et de désinstallation
séparé. Comme pour le reste: ce genre de chose n'a rigoureusement rien à
faire dans descriptif, car ça n'est pas un descriptif et ça n'est pas
exportable.

deja existant, expliqué par esj

km