[spip-dev] Aide et FAQ de Plugins SPIP

Dev
1

Hello,

La documentation étant à la mode dans le microcosme SPIP ces derniers temps, je relance un peu le sujet concernant le nouveau site Plugins SPIP.

Pour rappel la documentation de Plugins SPIP est accessible via un bouton Aide dans le bandeau.
Ce bouton envoie vers le premier article “A propos de Plugins SPIP” dont le but est juste de faire découvrir pourquoi ce site à été initié.
Ensuite, un menu permet de naviguer dans les autres articles d’aide (contenu du site, objets plugin et paquet, rédaction des xml…).

Parmi ces articles, on trouve une FAQ qui est dans un état embryonnaire.

Donc, je vous invite tous à lire et relire ses articles, à faire vos commentaires via le formulaire de signalements et, en particulier, à proposer des questions supplémentaires dans la FAQ pour faciliter l’accessibilité et la compréhension du site.

En outre, j’aimerais aussi lancer la traduction du site dont une partie passera par la traduction des articles précités (l’autre partie concernant la traduction des plugins). Si vous êtes intéressé, faites m’en part aussi via le formulaire de Signalements que j’espère changer à terme par des tickets.

2

J’en profite pour te demander comment tu comptes traduire l’aide en ligne de plugonet qui est justement hébergée sur plugins.spip.net.
Ce qui est d’ailleurs une manière de relancer le débat sur le meilleur moyen d’étendre l’aide en ligne. Vaut-il mieux :

  • des fichiers embarqués par le plugin
  • il semble que ces fichiers sont du pur HTML ? Pas moyen d’écrire ces extensions d’aide sous forme de squelette pour pouvoir utiliser balises et filtres de SPIP ?
  • si on peut utiliser les filtres de SPIP, est-ce que les fichiers d’aide ne devrait pas utiliser des chaînes de langue ? Du coup, tout est traduisible avec trad_lang- des fichiers stockés sur un site web
  • un site web dédié à chaque plugin ?
  • peut-on avoir un site qui centralise ?
  • est-ce possible de générer dans ce cas cette aide via des articles SPIP ou un nouvel objet SPIP avec gestion des traductions ?

Bref, faut-il repenser le système d’aide en ligne pour SPIP 3 ?

Amicalement

Joseph

3

hello,

  • il semble que ces fichiers sont du pur HTML ? Pas moyen d’écrire ces extensions d’aide sous forme de squelette pour pouvoir utiliser balises et filtres de SPIP ?

Non

  • si on peut utiliser les filtres de SPIP, est-ce que les fichiers d’aide ne devrait pas utiliser des chaînes de langue ? Du coup, tout est traduisible avec trad_lang

Non, je ne vois pas comment découper intelligemment les chaines de langue pour un tel texte.

  • des fichiers stockés sur un site web
  • un site web dédié à chaque plugin ?

Non

  • peut-on avoir un site qui centralise ?

Oui, ma proposition est de le mettre sur Plugins SPIP, ce qu’Yffic a déjà fait pour sjCycle 2

  • est-ce possible de générer dans ce cas cette aide via des articles SPIP ou un nouvel objet SPIP avec gestion des traductions ?

Ben j’ai répondu.
Par contre, ce que je souhaiterais c’est que le fichier d’aide des plugins soit distinct de celui de spip.

4

Je ne serais pas aussi péremptoire sur ces questions.

Les entrées de l'aide en ligne sont gérées par un mécanime mettant en correspondance le nom des champs de saisie d'un squelette de formulaire et une chaîne à trouver dans l'article d'aide associé à ce formulaire. Cette correspondance est décrite dans le fichier ci-dessous:

http://core.spip.org/projects/spip/repository/entry/branches/spip-2.1/ecrire/inc/aider.php

qui va conduire par exemple à chercher "<h2>arttitre.*</h2>" dans l'article contenant l'aide en ligne associé à ce squelette:

http://www.spip.net/ecrire/?exec=articles_edit&id_article=2658

Ce nom "arttitre" peut donc être vu comme un item de langue d'un module homonyme du nom du squelette, qui pourrait donc être un fichier de langue inclus dans la distribution. Il n'y a donc pas un problème technique sur le découpage de ces textes en item de langue, mais un choix: veut-on une distribution légère avec une aide centralisée (ce qui économise de la place mais pose le pb qu'il faudrait idéalement autant de fichiers d'aide que de numéro de version de distribution), ou une distribution qui embarquerait son aide sous forme de fichiers de langue, ce qui alourdirait chaque distribution mais garantirait (du moins pour la langue de référence) l'adéquation de la doc au code effectivement exécuté.

La méconnaissance par la communauté de la possibilité d'enrichir l'aide en ligne laisse penser que le modèle actuel n'est pas le bon, et qu'il vaudrait mieux passer au modèle de développement où l'écriture d'un squelette SPIP ou d'un script PHP est immédiatement suivie de la rédaction de sa doc dans le fichier homonyme du répertoire lang/: c'est facile pour le développeur, ça évite aux traducteurs d'avoir 2 zones de travail à gérer (les fichiers de langue d'une part, le site de la doc de l'autre), et ça reporte le pb de gestion de version sur l'outil qui ait fait pour ça: SVN.

Une solution mixte serait qu'une distribution n'inclut pas les fichiers de langue, mais embarquerait un code PHP qui irait pointer sur le numéro SVN du fichier de langue correspondant au numéro de version de la distribution exécutée. Autrement dit, help_server ne pointerait plus sur spipnet mais sur Trac. Ce serait l'idéal à mon avis, mais il y a du boulot.

Committo,Ergo:Sum

5

Salut ESJ :wink:

La méconnaissance par la communauté de la possibilité d'enrichir l'aide en ligne laisse penser que le modèle actuel n'est pas le bon,

oui :slight_smile:

et qu'il vaudrait mieux passer au modèle de développement où l'écriture d'un squelette SPIP ou d'un script PHP est immédiatement suivie de la rédaction de sa doc dans le fichier homonyme du répertoire lang/: c'est facile pour le développeur, ça évite aux traducteurs d'avoir 2 zones de travail à gérer (les fichiers de langue d'une part, le site de la doc de l'autre), et ça reporte le pb de gestion de version sur l'outil qui ait fait pour ça: SVN.

Euh... (pardon si j'ai pas compris)... ne pourrait-on pas plutôt utiliser un site SPIP, avec son interface de rédaction habituelle ?? Si je veux participer à la rédaction de l'aide, moi qui ne suis ni "développeur", ni "traducteurs", comment dois-je faire ?

-- Romy

6

Yep,

La méconnaissance par la communauté de la possibilité d’enrichir l’aide en ligne laisse penser que le modèle actuel n’est pas le bon,

oui :slight_smile:

Non. Moi ça me fait dire plutôt que le système est à l’abandon c’est tout.
Pas forcément qu’il est mauvais.
Je reste persuader que les articles de spip sont le meilleur vecteur de l’aide car ils permettent d’utiliser la puissance rédactionnelle de spip.
Par contre, une url du type aide.spip.net aiderait surement à une meilleure visibilité ainsi qu’une méthode/plugin d’hébergement/génération de l’aide qui simplifie la mise en oeuvre et étend facilement l’utilisation.

Euh… (pardon si j’ai pas compris)… ne pourrait-on pas plutôt utiliser un site SPIP, avec son interface de rédaction habituelle ?? Si je veux participer à la rédaction de l’aide, moi qui ne suis ni « développeur », ni « traducteurs », comment dois-je faire ?

Ben là Romy tu viens de dire le contraire de plus haut non ?

7

> La méconnaissance par la communauté de la possibilité d'enrichir l'aide en ligne laisse penser que le modèle actuel n'est pas le bon,

oui :slight_smile:

Non. Moi ça me fait dire plutôt que le système est à l'abandon c'est tout.
Pas forcément qu'il est mauvais.

Eric, voyons, on n'abandonne pas un truc qui marche bien, tsss...

Je reste persuader que les articles de spip sont le meilleur vecteur de l'aide car ils permettent d'utiliser la puissance rédactionnelle de spip.

Quels articles ?

Ben là Romy tu viens de dire le contraire de plus haut non ?

Alors c'est que je ne comprends rien !

Ca fait plusieurs années que j'aimerais participer à la mise à jour de l'aide rédacteur sans savoir comment faire. Quand j'ai une réponse, c'est : « ouhla, atta, c'est compliqué ! Il faut d'abord que [... ici, plein de considérations techniques qui me dépassent ...] Bon attends, n'y touche pas pour l'instant ! Ah nan surtout pas ! Tu vas tout péter ! »

Ah oui, c'est la montagne du versionnage qu'on veut d'abord soulever :
http://core.spip.org/issues/2253

J'attends encore ?

De toute façon, je n'ai pas le choix :slight_smile:

Ou je décide que j'en ai marre d'attendre bêtement et j'ouvre un nouveau site dédié, ce qui fédéra peut-être les bonnes volontés en attente et permettra au moins d'aider le gens, puisque -- hum :slight_smile: -- c'était le but initial ?

-- Romy

8

Bon, j'ajoute mon grain de sel, même si je n'ai pas tout suivi de la discussion, particulièrement sur ce qu'à tenté d'expliquer Emmanuel sur le fonctionnement actuel de cette aide (par contre j'ai compris sa suggestion d'utiliser svn).

Pour ma part (je ne sais pas si c'est finalement ce que vous suggérez d'ailleurs, ni même si c'est ce qui se passe), je suis plus favorable à un mécanisme qui se base sur des articles SPIP et des traductions de ces articles. Cela me semble plus simple à gérer pour ce genre de documentation qui n'est pas simplement quelques phrases & mots dans une interface (ce que gère très bien les chaînes de langues), mais qui est plus construite, et éventuellement avec des images, des captures d'écran.

Il faut également un fonctionnement plus intuitif, #AIDER{arttitre} est par exemple très confus pour moi : pourquoi va t'il chercher cette aide sur spip.net et pas ailleurs (sachant qu'on peut maintenant donner plusieurs adresses de serveurs d'aides je crois) ?

Enfin, et je crois que c'est ce que dit Eric, un plugin qui permettrait à un site de devenir "serveur d'aide" peut aussi être une solution intéressante. Une autre question que je me pose du coup, c'est : un site spécifique peut il être son propre serveur d'aide dans ce cas ? (Le webmestre créant alors sur le site les articles d'aides du site lui-même) ; peut il surcharger l'aide fournie par SPIP s'il en change le fonctionnement ?

Je dérive un peu, mais je vois du coup que ce n'est pas anodin cette aide en ligne du tout :slight_smile:

9

Bon je vais essayer d’expliquer !

Je reste persuader que les articles de spip sont le meilleur vecteur de l’aide car ils permettent d’utiliser la puissance rédactionnelle de spip.

Quels articles ?

Ceux de l’aide de SPIP qui sont… tagada… sur spip.net qui comme chacun est ouvert !

Alors c’est que je ne comprends rien !

Ca fait plusieurs années que j’aimerais participer à la mise à jour de l’aide rédacteur sans savoir comment faire. Quand j’ai une réponse, c’est : « ouhla, atta, c’est compliqué ! Il faut d’abord que [… ici, plein de considérations techniques qui me dépassent …] Bon attends, n’y touche pas pour l’instant ! Ah nan surtout pas ! Tu vas tout péter ! »

Euh ben depuis autant de temps tu as un compte sur spip.net et tu peux aller modifier ce que tu veux dans fr-aide.html (nom de la rubrique).
C’est pas le support rédactionnel de l’aide qui est compliqué c’est la mise en place d’un serveur hébergeant l’aide. Mais les rédacteurs eux n’ont pas plus de souci que de rédiger des articles avec juste la petite contrainte du titre h2.
La seule emmerde que je vois actuellement sur le site c’est qu’il n’y a pas de versioning de l’aide donc modifier l’aide actuelle reviendrait à choisir une version particulière comme cible de cette aide.

En outre, ce qui est vrai c’est qu’il n’existe pas d’url simple pour aller directement sur cette aide : une url aide.spip.net serait déjà plus lisible.
Ensuite, je serais assez favorable à un serveur d’aide qui permette d’héberger l’aide de spip et celles des plugins à partir du moment ou l’arbo est bien définie. Mais peut etre que ça poserait des problèmes à la longue.

10

C'est-à-dire qu'il faut le saisir en HTML ?? comme je vois là :

<h2>intersimple/Interface simplifiée / complète</h2>

Il y a d'autres trucs en HTML, bizarres (à préserver ou à nettoyer ?) :

<font face="Verdana,Arial,Sans,sans-serif" size="3"><b>SPIP, Système de publication pour l'internet</b></font>

<A HREF="./?exec=aide_index&aide=confart" TARGET="_top">

Est-ce que je peux supprimer les paragraphes « Interface simplifiée / interface complète » et autres trucs qui n'existent plus ?

-- Romy

11

C'est pas le support rédactionnel de l'aide qui est compliqué

Là déjà je suis pas trop d'accord: un traducteur doit savoir que les articles de spipnet figurant dans la rubrique "aide" ont un format spécial, savoir des balise H2 dont le premier "mot" ne doit pas être traduit car c'est en fait ce qu'ailleurs on appelle un item de langue. Je trouve ça quand même compliqué.

c'est la mise en place d'un serveur hébergeant l'aide.

Mais cette centralisation est-elle vraiment nécessaire ? Je ne comprends pas comment tu peux à la fois avoir conçu, à raison, SVP comme étant multo-dépot, et à côté de ça demander que l'aide soit centralisée: ce serait plus normal d'avoir la doc sur le dépôt où est développé le code.

Mais les rédacteurs eux n'ont pas plus de souci que de rédiger des articles avec juste la petite contrainte du titre h2.

Et la gestion des URL inter-traductions. Le seul argument en faveur des articles à mon avis c'est la gestion des images: une chaîne de langue pourrait contenir des balises "img", mais à quelle URL absolue faudrait-il alors les installer. C'est la seule question à mon avis.

La seule emmerde que je vois actuellement sur le site c'est qu'il n'y a pas de versioning de l'aide donc modifier l'aide actuelle reviendrait à choisir une version particulière comme cible de cette aide.

Bah oui, et c'est pour ça que je dis qu'il suffit d'utiliser l'outil std pour ça: SVN.
Quand je modifie les fonctionnalités du squelette Truc, je m'empresse de modifer le fichier lang/truc_fr.php.
Avec une petite modif dans le fichier aide_index, on peut aller taper dans le bon numéro de ce fichier à partir du numéro SVN de la distrib.
Si on a un distrib sans numéro SVN, on doit pouvoir se débrouiller avec le numéro de version dans le fichier XML si celui a bien été incrémenté à chaque chgt de fonctionnalité.

En outre, ce qui est vrai c'est qu'il n'existe pas d'url simple pour aller directement sur cette aide : une url aide.spip.net serait déjà plus lisible.

Pour les articles de description générale oui, mais pour l'aide en ligne ponctuelle ça ne me parait pas indispensable.

Ensuite, je serais assez favorable à un serveur d'aide qui permette d'héberger l'aide de spip et celles des plugins à partir du moment ou l'arbo est bien définie. Mais peut etre que ça poserait des problèmes à la longue.

Bah oui les arbres, ça pousse dans tous les sens, ça ne me parait pas viable sur le long terme.

Committo,Ergo:Sum

12

Bon, après lecture je dirais :

C’est pas le support rédactionnel de l’aide qui est compliqué

Là déjà je suis pas trop d’accord: un traducteur doit savoir que les articles de spipnet figurant dans la rubrique « aide » ont un format spécial, savoir des balise H2 dont le premier « mot » ne doit pas être traduit car c’est en fait ce qu’ailleurs on appelle un item de langue. Je trouve ça quand même compliqué.

Oui, c’est vrai que ce h2 est pas très intuitif.
Mais ça me parait assez facilement surmontable avec un raccourci qui dit : ce lien est en fait un index de type table des matières. Enfin, faut réfléchir à la meilleure mise en oeuvre.

c’est la mise en place d’un serveur hébergeant l’aide.

Mais cette centralisation est-elle vraiment nécessaire ? Je ne comprends pas comment tu peux à la fois avoir conçu, à raison, SVP comme étant multo-dépot, et à côté de ça demander que l’aide soit centralisée: ce serait plus normal d’avoir la doc sur le dépôt où est développé le code.

Là je ne parle pas de centralisation.
Il peut y avoir plusieurs serveurs, sauf que pour un créer un actuellement c’est une galère : modifier de façon absconse le htaccess, rajouter une page avec une boucle simple mais peut explicite et pas du tout configurable, recopier une fonction qui nettoie le html produit… Ca c’est compliqué et je pense qu’un plugin « serveur d’aide » serait d’un grand secours.

Et la gestion des URL inter-traductions.

Euh là je ne comprends pas. C’est correctement géré actuellement non ?

Le seul argument en faveur des articles à mon avis c’est la gestion des images: une chaîne de langue pourrait contenir des balises « img », mais à quelle URL absolue faudrait-il alors les installer. C’est la seule question à mon avis.

Mais une question : comment tu rédiges ton aide ? Editeur ? Interface de rédaction d’un article spip + un générateur de fichier de langue ? C’est ça ma question principale : comment, si on ne choisit pas d’utiliser SPIP pour écrire l’aide on la rédige ?

Bah oui, et c’est pour ça que je dis qu’il suffit d’utiliser l’outil std pour ça: SVN.
Quand je modifie les fonctionnalités du squelette Truc, je m’empresse de modifer le fichier lang/truc_fr.php.
Avec une petite modif dans le fichier aide_index, on peut aller taper dans le bon numéro de ce fichier à partir du numéro SVN de la distrib.

Oui enfin c’est pas svn qui gère ça mais plutôt la notion de branches pour avoir une aide SPIP 2.1 et une aide SPIP 3.0. A ce titre, une arborescence adaptée dans un site SPIP et un outil pour dupliquer les articles feraient la même chose.

Après, pour les plugins, et même pour spip, on a pas encore creusé la piste du fichier paquet.xml pour fournir des informations sur la configuration d’une aide en ligne. Ce serait déjà plus pratique à mon avis que la globale actuelle et ça permettrait même d’indexer l’aide depuis la page du plugin sur Plugins SPIP.

13

Bon, après lecture je dirais :

Il peut y avoir plusieurs serveurs, sauf que pour un créer un actuellement c'est une galère : modifier de façon absconse le htaccess, rajouter une page avec une boucle simple mais peut explicite et pas du tout configurable, recopier une fonction qui nettoie le html produit... Ca c'est compliqué et je pense qu'un plugin "serveur d'aide" serait d'un grand secours.

Mais c'est bien pour ça qu'une chaîne de langue dans un fichier de nom standardisé serait plus simple.

Et la gestion des URL inter-traductions.

Euh là je ne comprends pas. C'est correctement géré actuellement non ?

Seulement si les rédacteurs et traducteurs ont lu ça:

encore un truc un peu compliqué.
Cela dit, il ne me semble pas que cela soit utilisé dans l'aide en ligne, seulement dans les articles généraux.

Le seul argument en faveur des articles à mon avis c'est la gestion des images: une chaîne de langue pourrait contenir des balises "img", mais à quelle URL absolue faudrait-il alors les installer. C'est la seule question à mon avis.

Mais une question : comment tu rédiges ton aide ? Editeur ? Interface de rédaction d'un article spip + un générateur de fichier de langue ? C'est ça ma question principale : comment, si on ne choisit pas d'utiliser SPIP pour écrire l'aide on la rédige ?

Pour la rédaction, c'est comme n'importe quelle chaîne de langue. Je ne saisis pas où tu y vois un pb, hormis les balises img comme je disais.

Bah oui, et c'est pour ça que je dis qu'il suffit d'utiliser l'outil std pour ça: SVN.
Quand je modifie les fonctionnalités du squelette Truc, je m'empresse de modifer le fichier lang/truc_fr.php.
Avec une petite modif dans le fichier aide_index, on peut aller taper dans le bon numéro de ce fichier à partir du numéro SVN de la distrib.

Oui enfin c'est pas svn qui gère ça mais plutôt la notion de branches pour avoir une aide SPIP 2.1 et une aide SPIP 3.0. A ce titre, une arborescence adaptée dans un site SPIP et un outil pour dupliquer les articles feraient la même chose.

Bah oui mais pourquoi développer cet outil alors qu'il existe SVN ?

Après, pour les plugins, et même pour spip, on a pas encore creusé la piste du fichier paquet.xml pour fournir des informations sur la configuration d'une aide en ligne. Ce serait déjà plus pratique à mon avis que la globale actuelle et ça permettrait même d'indexer l'aide depuis la page du plugin sur Plugins SPIP.

Ben en fait quand je disais de prendre le répertoire "lang" de l'adresse du dépot du plugin, ça revient à peu près à ça, sauf que qu'au lieu de prendre l'attribut "developpement" de la balise "paquet" tu prendrais un nouvel attribut nommé "aide", pourquoi pas. Mais est-ce vraiment utile de multiplier les attributs ? Les fichiers de langue sont sur le dépot, forcément. Maintenant si on veut mettre la doc en ligne à une URL d'article SPIP, alors oui un attribut nouveau serait nécessaire pour pointer sur un site sous Spip, et non sous SVN.

Committo,Ergo:Sum

14

Soit,

15

Et la gestion des URL inter-traductions. Le seul argument en faveur des articles à mon avis c'est la gestion des images: une chaîne de langue pourrait contenir des balises "img", mais à quelle URL absolue faudrait-il alors les installer. C'est la seule question à mon avis.

URLs relatives... ?

Oui, j'y pensais aussi: SPIP a un répertoire prive/images, on pourrait convenir que tout plugin à un répertoire "img". Mais il resterait à inventer un raccourci pour chaîne de langues pour les référencer, car dans les articles de spipnet on écrit "<imgNNN>" sans pb.

Si las accros du codage écrivaient de la documentation au fur et à
mesure ça se saurait :slight_smile:

Justement, ce serait bien de leur faire perdre cette mauvaise habitude.

Perso, même pour les chaines de langue j'ai du
mal (le truc est de parser les fichiers à la fin pour récupérer les
chaines et voir celles qui sont traduites ou pas, et en PHP j'utilise
plus souvent _L que _T...)

Il y a un outil qui fait ça très bien, surtout dans sa dernière version:

Committo,Ergo:Sum

16

Pas trop, c'est vrai. Mais y a-t-il tellement de raccourcis dans les fichiers d'aide en ligne ? Je n'ai pas l'impression.

Committo,Ergo:Sum

17

Pour l’aide il faudrait probablement introduire une notion de paquet d’aide. Ainsi, on pourrait gérer plusieurs branches : un paquet aidespip-2 et un paquet aidespip-3.

De plus, on a dégraissé l’écureuil : plusieurs fonctions sont implémentées dans des plugins séparés : mots, brèves, forums etc. Autrement dit, l’aide devrait aussi être découpées en paquet correspondant à ces plugins. L’aide concernant les brèves ne devraient pas être affichés sur un site ou le plugin breve n’est pas actif !! Une bonne aide en ligne est une aide qui ne porte que sur les fonctionnalités installées sur le site, afin d’éviter de polluer le rédacteur de choses qui ne le concernent pas.

Un plugin doit ainsi pouvoir indiquer un paquet d’aide supplémentaire à prendre en compte. Il s’agit bien de généraliser le système actuel d’extension de l’aide en ligne pour construire sur un SPIP donné une aide en ligne correspondant uniquement au paquet concerné. Le système de paquet d’aides permet aussi de gérer plusieurs versions d’une aide.

Ce qui vient un peut compliquer le système, c’est que l’arborescence des paquets d’aide est partagée par les différents paquets. Autrement, les différents paquets d’aide doivent pouvoir venir de brancher sur cette arborescence et pouvoir la compléter au besoin. Le problème est analogue dans une certaine mesure aux pipelines qui fournissent des points d’entrée. Un site central est une bonne idée pour mutualiser cette dernière.

Il faut aussi simplifier le travail du rédacteur. Autrement dit, c’est à l’interface de rédaction de s’assurer de la cohérence des identifiants entre les différentes traductions.

Enfin, il faut peut-être prévoir d’étendre le mécanisme d’autorisation aux éléments visibles de l’aide en ligne. Pour plus d’ergonomie, l’aide d’installation n’a pas besoin d’être visible pour les rédacteurs. De même que l’aide concernant certaines fonctionnalités n’a pas à être visible si ces dernières n’ont pas été activées dans la configuration.

Si cela peut être utile, je veux bien rédiger pendant le week end un article de synthèse de la situation actuelle et des éventuelles évolutions qui pourrait servir de base à une discussion plus structurée.

Cordialement

Joseph

18

Le 18/11/2011 11:02, Eric a écrit :

Oui, ma proposition est de le mettre sur Plugins SPIP, ce qu'Yffic a déjà fait pour sjCycle 2

Heu... C'est pas encore finalisé... Il reste à régler
- le problème des puces (lignes commençant par un "-" )
- la traduction anglaise ne fonctionne pas encore (Plugins SPIP ne renvoie toujours pas mon article)
- le fait que pour l'instant les aides de tous les plugins sont renvoyées même s'ils ne sont pas installés. C'est peut-être optimisable ? Voir Plugins SPIP

--
Yffic Cloarec
Le Fourneau, Centre national des arts de la rue [en Bretagne]
http://www.lefourneau.com / http://www.cliclarue.info

19

Le 18 novembre 2011 12:24, Yffic <yffic@lefourneau.com> a écrit :

Le 18/11/2011 11:02, Eric a écrit :

Oui, ma proposition est de le mettre sur Plugins SPIP, ce qu’Yffic a déjà fait pour sjCycle 2

Euhhh, question naïve : on fait comment pour écrire l’aide d’un nouveau plugin ? ça se passe où ? faut demander des codes à quelqu’un ?

Heu… C’est pas encore finalisé… Il reste à régler

C’est un problème en effet. SPIP ne doit pas afficher l’aide en ligne d’un plugin non installé. Sinon, le rédacteur n’y comprends rien.
Et puis, si bp de plugins utilisent enfin l’aide en ligne, ca va polluer l’aide de pleins de fonctions inutiles.

Il faudrait pouvoir gérer séparément l’aide de chaque plugin.

Amicalement

Joseph

20

Yop,

Le 18 novembre 2011 13:40, Joseph <joseph@larmarange.net> a écrit :

Euhhh, question naïve : on fait comment pour écrire l’aide d’un nouveau plugin ? ça se passe où ? faut demander des codes à quelqu’un ?

J’y ai pas trop réfléchi mais je verrais bien un rédacteur générique pour l’aide en ligne.

Bon on revient au sujet initial ?

++
Eric