Avertissement

Cet article fait désormais partie de la documentation de Dotclear 1.2 et ne sera plus mis à jour ici. La version « de référence » devient celle-ci

Si vous êtes auteurs de plugins, vous avez probablement suivi la discussion liée à l'annonce de la nightly 731 sur le forum avec intérêt. En tout cas, vous auriez dû... D'abord parce qu'il est fait cas du nouveau mode de gestion des paramètres de configuration de DotClear, mais également parce que l'aspect qualité lors du développement d'un plugin a été rapidement mentionné. C'est sur ce dernier point que je compte un peu revenir dans ce billet.

Dans la discussion du forum, il transparait clairement qu'un système centralisé de référencement des plugins serait également l'occasion de mettre en place une démarche qualité concernant les extensions proposées. 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, je me permets de vous livrer ici une petite compilation des critères qui pourraient être retenus pour l'évaluation des développements. Ce n'est pas un réel scoop, puisque la liste qui suit n'est pas la liste officielle définitive, mais un simple ensemble de points déjà discutés par l'équipe actuelle.

Vous êtes attentifs ? C'est parti.

Code PHP en général et commentaires

  • 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. Un document décrivant celles-ci est disponible sur le Trac.
  • 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.

Code PHP pour les sorties, XHTML et CSS

  • 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.

"Confort" de l'utilisateur

  • 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.

Licence et copyrights

  • 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. Les critères définitifs seront sûrement annoncés en temps voulu. Néanmoins, vous disposez désormais d'une base de travail supplémentaire.

Zou ! Au boulot !