Bonsoir à tous,
J’ai vu passer dans les tickets sur le core un ticket parlant du site code.plugins.spip.net
Y a-t-il une règle particulière pour l’ajout de plugins sur ce site ? Des conditions ? Où pourra-t-on avoir tous les plugins (utilisés) de plugins.spip.net ?
Si vous êtes d’accord, je peux me charger d’ajouter les plugins listés sur la page d’accueil de http://plugins.spip.net dans un premier temps.
Amicalement,
Ybbet
Hello,
Ben ce site permet de créer une documentation automatique des plugins à partir du PHPDoc.
Donc il n’y a aucun intérêt aujourd’hui à rajouter pleins de plugins dans le site si ceux-ci ne sont pas correctement documentés.
Par contre, oui, ça serait bien d’en rajouter au fur et à mesure que l’on en documente de façon complète.
Oui, c’est sûr que s’il n’y a pas de phpdoc, ça perd son sens. Mais cela pourrait aider à trouver les erreurs ou les manques en documentation technique.
C’est pour cela aussi que j’ai proposé de mettre les plugins les plus utilisés, tels que crayons, Bonux, accès restreint, etc.
Autre exemple, sur mes plugins, je ne suis pas sûr d’avoir du PHPdoc partout. La documentation automatique m’aiderait à visualiser rapidement les oublis.
Oui oui tout à fait, ça aide à repérer les manques.
Je fais aussi comme ça.
Le seul truc c’est de pas tous les mettre d’un coup car sinon on ne sera pas trop qui est bon et qui est en cours.
Ce qu’on pourrait faire c’est les mettre petit à petit non ?
Tiens d’ailleurs en relisant ton premier mail je me dis qu’on a pas de lien entre plugins SPIP et le PHPDoc. On a le contraire PHPDoc vers Plugins SPIP ou Contrib par contre.
Je sais pas si ça aurait un sens de le rajouter dans Plugins SPIP ?
Hello.
Notez aussi que la documentation n'est générée qu'une seule fois pour 1 prefixe de plugin, généralement le trunk, et que ce n'est pas forcément
lui qui est proposé en téléchargement.
MM.
Ouep mais les liens vers le source et la documentation contrib sont elles aussi liées à la version.
On pourrait ajouter un attribut de la balise paquet comme pour la doc, la demo et le source.
C’est vrai qu’on a un attribut developpement pour un lien vers une url représentant le développement du plugin qui n’est guère utilisé aujourd’hui car on utilise principalement le lien source qui pointe lui vers le svn.
Donc, Matthieu, le code n’est pas mis à jour? :-/
Heu, les documentations des plugins sont générées tous les jours (du moins pour les plugins qui ont reçu un commit, et lorsque le cron fonctionne ^^ (il a été absent quelques mois sans que j'y prête attention)).
Ce que je voulais dire, c'est que j'ai fait le choix de mettre la documentation du code *de dévoloppement* (pour SPIP comme des plugins),
et du coup, pour les plugins, c'est le trunk/ qu'on prend. Et je n'ai autorisé de n'avoir qu'une seule documentation par prefixe de plugin ; on ne peut pas avoir la doc de la branche/v2 (stable et zippée) et le trunk/ (c'est un choix que j'ai fait ; c'est pas une limitation de l'outil).
Donc le lien que tu verrais sur plugins.spip ne serait pas forcément le code de la version qui est fournie zippée. C'était le sous-entendu. C'est plus clair ? (Et pour les plugins n'ayant pas de trunk/branches, la question ne se pose donc pas encore).
MM.
Yep, tu es très clair. 
Je m'étais habitué à ce fonctionnement avec code.spip.net