Développement de plugins : un peu plus de rigueur et de discipline ?

Si, en matière de plugins, toute contribution est la bienvenue, il n’en demeure pas moins que respecter quelques critères de qualité sera la garantie d'un accueil bien plus « chaleureux ». Oui, mais voilà : ces fameux critères, quels sont-ils ? Hop ! Passage en revue des troupes.

L’objectif n'est pas de traumatiser les auteurs de plugins, non. Il s'agit simplement de garantir aux utilisateurs de DotClear des plugins présentant une qualité de code et une philosophie quasi équivalentes à celles de DotClear lui-même.

Pour que vous ne soyez pas pris au dépourvu, voici une petite compilation des critères qui pourraient être retenus pour l’évaluation des développements. C’est parti.

• Le plugin doit se conformer aux exigences en terme de versions PHP et MySQL retenues pour DotClear (cf. paragraphe « Pré-requis » de la documentation d’installation). Notez qu'une librairie de compatibilité PHP existe déjà dans la distribution de DotClear (cf. inc/libs/lib.compat.php). Vous pouvez vous en inspirer en cas de besoin.
• Le code PHP doit suivre les conventions utilisées dans DotClear. Voir la page dédiée.
• Le code PHP doit être correctement documenté et devrait suivre la syntaxe des commentaires propre à DotClear (cf. Documentation du code PHP).
• Le plugin doit utiliser les classes, et classes dérivées, connection et recordset pour ses accès à la base de données.
• Le plugin doit recourir autant que possible aux fonctions utilitaires déjà mises à disposition par DotClear (Cf. inc/libs/).
• Le fichier functions.php du plugin doit contenir une classe primaire nommée selon le plugin pour éviter les collisions.
• Le plugin doit fonctionner avec des URLs en mode querystring et pathinfo.
• Le plugin doit fonctionner avec un encodage UTF-8 et ISO-8859-1
• Le plugin devrait utiliser un sous répertoire dans share/, du même nom que le plugin, pour stocker d'éventuelles informations liées à son fonctionnement.

• Les méthodes du fichier functions.php générant des sorties doivent offrir la possibilité de reformater celles-ci.
• Les sorties doivent être en XHTML Strict.
• Les sorties ne doivent pas utiliser de CSS inline.
• En cas d’utilisation de classes CSS, ces dernières devraient reprendre autant que possible le nom du plugin afin d’éviter d'éventuelles collisions.

• Le plugin devrait offrir une procédure d’installation simple, à défaut, il doit offrir une aide à l'installation simple.
• Le plugin devrait prévoir une prise en charge de la désactivation.
• Le plugin doit inclure une aide à l’utilisation et à l’insertion dans le template, lisible depuis la page d’administration.
• Le plugin doit être localisé (au minimum en EN et FR)
• L’auteur du plugin doit fournir une adresse email valide lors du référencement du plugin.

• L’auteur doit s'assurer que les éléments graphiques du plugin ne violent pas un quelconque copyright.
• La licence s’appliquant au plugin doit être clairement mentionnée :
  • Pour un plugin utilisant des composants internes de DotClear, la licence appliquée sera la GNU GPL.
  • Pour un plugin totalement autonome, le choix de la licence sera laissé à l’auteur, mais devra se porter sur une licence libre ou OSI.

Toujours là ? C’est bien. De toute manière, vous aurez noté qu’il y a rien de terrible ni d’insurmontable dans cette ébauche des critères.

Avant de se quitter, je vous rappelle que ceci n’est donné qu’à titre indicatif. Néanmoins, vous disposez désormais d’une base de travail supplémentaire.

Zou ! Au boulot !