Si vous souhaitez apporter votre contribution à DokuWiki et vous joindre à son développement, lisez cette page.
Un guide du développeur (en) est en cours de rédaction. Il contient quelques pointeurs pour vous aider à comprendre le code source.
Vous pouvez récupérer la dernière version du code source en développement sur le dépôt Darcs, ou avec l'image quotidienne. Vous pouvez aussi naviguer dans le code ou utiliser l'interface Web de Darcs.
L'intégralité du code source est bien documentée, et le guide de référence de l'API généré automatiquement est disponible :
Le développement est coordonné via la liste de diffusion ( fil RSS) – si changer le code de base de DokuWiki vous intéresse, rejoignez cette liste ! Certaines décisions sont parfois prises en direct sur IRC également.
À vrai dire la nature de votre contribution dépend totalement de vous – commencez parce qui vous démange le plus. Jetez un œil au bugtracker si vous cherchez des idées sur ce qui manque à DokuWiki.
Pensez aussi à regarder help wanted, qui liste des points qui pourraient être améliorés, et pour lesquels des patchs seraient plus que bienvenus.
Je ne suis pas très strict sur la manière dont le code doit être présenté, mais certaines conventions doivent être respectées pour ajouter du code à DokuWiki.
L'indentation de votre code devrait être de 2 ou 4 espaces pour marquer les blocs logiques. Merci de ne pas utiliser de tabulation. La même indentation doit être utilisée tout le long d'un même fichier : vérifiez combien d'espaces sont utilisées dans le code existant pour adopter la même convention.
Les accolades ouvrantes doivent commencer sur la même ligne que le mot-clef qui la précède, l'accolade fermante doit être alignée avec la première lettre de ce mot-clef. Par exemple :
if ($foo == "bar"){ call_bar(); }elseif($foo == "baz"){ call_baz(); }else{ call_other(); }
Les lignes doivent se terminer avec un caractère de fin de ligne (à la façon UNIX). Essayez d'éviter les espaces en fin de ligne : vous pouvez consulter mon fichier .vimrc pour voir comment les détecter facilement avec VIM.
Chaque fonction et chaque classe doit avoir un commentaire pour PHPDocumentor, qui indique au moins le but de la fonction et son auteur. Il est agréable d'avoir une description pour les paramètres et la valeur de retour, mais elle n'est obligatoire que lorsqu'elle n'est pas évidente. Si vous améliorez une fonction existante, ajoutez simplement une nouvelle ligne d'auteur.
Exemple:
/** * Check for foo in bar * * Checks if there is a foo in bar * * @author Joe Schmoe <joe@example.com> * @param string $in your input * @returns boolean true if foo in bar */ function is_foo($in){ ... }
Ces commentaires sont utilisées pour la documentation de l'API générée automatiquement.
Vous devez omettre la balise fermante de PHP (?>) dans tous les fichiers, pour ne pas envoyer prématurément de texte en sortie. Cette pratique peut sembler étrange mais elle est en fait mentionnée dans le manuel de PHP:
Note: La balise fermante d'un bloc PHP à la fin d'un fichier est optionnelle, et parfois, il est utile de l'omettre lors de l'utilisation de la fonction include() ou de la fonction require(), car les espaces non désirés n'apparaîtront pas à la fin des fichiers, et ainsi, vous pourrez toujours ajouter des en-têtes à la réponse plus tard. C'est utile également si vous voulez utiliser la mise en tampon de la sortie et que vous ne voulez pas voir d'espaces blanches ajoutées à la fin des parties générées par les fichiers inclus.
Tout ajout de code doit être accompagné d'un jeu de tests, comme décrit dans UnitTesting.
Les patches sont à envoyer sur la liste de diffusion, où à andi [at] splitbrain [dot] org. Il faut mieux créer votre patch avec Darcs, car il sera plus facile à intégrer. Si vous ne pouvez pas du tout utiliser Darcs, créez vos patches au format diff unifié (diff -u) à partir de la dernière image quotidienne disponible.
Voici une liste de documents qui devraient vous aider à comprendre le fonctionnement interne de DokuWikis.