Joomla! Documentation™

Pour signaler une anomalie dans l'outil de suivi des anomalies Joomla, vous devez créer un élément dans le traqueur. Une fois l'élément créé, les développeurs confirmeront son existence et agiront en conséquence. Si vous souhaitez aider en testant les correctifs pour Joomla, veuillez suivre les instructions détaillées ici.

Rapports d'anomalies

Créer un compte sur GitHub

Vous aurez besoin de créer un compte sur GitHub. En effet, l'outil de suivi des anomalies Joomla! nécessite un compte GitHub pour l'authentification.

Accéder à l'outil de suivi des anomalies pour Joomla!

• Joomla! Issue Tracker- Ouvert

Vérifier si le bogue que vous souhaitez signaler a déjà fait l'objet d'un rapport.

Une série de filtres affiche les éléments du tracker et peut être accédée en cliquant sur le bouton "Outils de recherche" en haut de la liste. Si le problème que vous rencontrez n'est pas déjà signalé, cliquez sur le bouton "Nouvel élément" dans la zone de navigation principale.

Un nouvel écran s'affiche. Plus vous y apporterez d'informations et plus le travail des développeurs en sera simplifié.

Complétez autant de données que possible. Vous pouvez activer les conseils pour chacun des champs en utilisant le bouton "Mode de Vue" sur le côté droit de l'écran pour basculer de Pro. vers Aide.

• Priorité : utilisez la valeur par défaut "Moyenne", sauf si vous vous y connaissez suffisamment pour faire un autre choix.
• Version : indiquez ici les versions concernées par l'anomalie.
• Catégories : cette sélection est plus délicate. Choisissez "Administration" si vous ne savez pas plus précisément.
• Titre : un bref résumé de l'anomalie.
• Description : détails quant à l'anomalie. Veuillez consulter la section ci-dessous pour plus d'informations.
• Téléchargements : les utilisateurs peuvent ajouter des images aux rapports d'anomalies. Les informations sur les exigences liées aux chargements sont énumérées dans le formulaire de rapport.

Proposer un résumé

Décrire en quelques mots les anomalies rencontrées. Si c'est votre premier rapport d'anomalie, il est conseillé d'utiliser un rapport existant comme exemple.

Exemples:

• Front-end : tel ou tel avertissement.
• Back-end : impossible de sauvegarder l'article lorsque "nomDuPlug-ins" est publié.

Remarque : appliquez-vous quant au descriptif de votre résumé car c'est la première chose que les développeurs à la recherche d'une anomalie à régler vont découvrir en parcourant le traqueur.

Fournir des détails sur l'anomalie

Afin de recueillir le plus d'information possible, le champ pour la description propose cinq sous-sections.:

• Procédure afin de reproduire l'anomalie (Steps to reproduce the issue) : étapes détaillées sur la façon dont une autre personne peut reproduire l'anomalie.
• Résultat attendu (Expected result) : ce que vous pensez qu'il aurait dû normalement se produire lorsque vous reproduisez les étapes ci-dessus.
• Résultat actuel (Actual result) : ce qu'il se passe dans les faits, actuellement, lorsque vous reproduisez les étapes ci-dessus.
• Informations système (System information) : informations sur la configuration de votre environnement. Ceci peut comprendre le navigateur que vous utilisez, la version PHP de votre serveur, ou le type de base de données utilisé sur votre site. Pour vous aider à ne rien oublier, vous pouvez copier/coller ces données à partir de votre site dans l'espace d'administration menu 'Système -> Informations système'.
• Informations additionnelles (Additional comments) : toutes les informations supplémentaires non fournies ci-dessus qui seraient utiles pour aider à reproduire et résoudre l'anomalie.

Le format général serait alors quelque chose qui ressemblerait à ceci :

1. "Voici "exactement" ce que j'ai fait."
2. "Voici ce qui s'est passé."
3. "Voici ce que je pense qu'il aurait dû se passer."
4. "Autres informations, solutions envisageables, proposition de patch du code."

Plus vous fournissez de détails, mieux c'est. Il est également important de reproduire le bogue sur un site Joomla! d'exemple ou de fournir des instructions claires permettant de retrouver une configuration identique à la vôtre. Rappelez-vous que d'autres n'auront pas accès à la base de données de votre site, vous devez donc être en mesure d'expliquer à quelqu'un comment faire pour reproduire l'anomalie avec des données facilement disponibles -- comme avec un site d'exemple.

Exemple A

Ce que j'ai fait

J'ai commencé avec un site d'exemples. Tout se passait bien. J'ai activé "nomDuPlug-in". J'ai essayé de sauvegarder un article à partir du back-end.

Ce qui s'est passé

J'obtiens un écran vide et l'article n'est pas enregistré.

Ce qui aurait dû se passer

Les articles auraient dû être correctement sauvegardés.

Autres informations

Voici les plug-ins également activés pendant l'anomalie. SEF est activé (ou désactivé). Mon site est dans un sous-dossier. J'ai également remarqué que... etc. Je pense que tels et tels fichiers sont à l'origine de l'anomalie (si vous savez, bien entendu, de quoi vous parlez).

Exemple B

Ce que j'ai fait

En back-end. J'ai cliqué sur le menu "nomDuMenu".

Ce qui s'est passé

La page qui s'ouvre est vide.

Ce qui aurait dû se passer

Le menu aurait dû s’ouvrir correctement.

Autres informations

Tous les autres menus fonctionnent sans problème, etc.

Exemple Réel

• Ce que j'ai fait

1. J'ai installé un site d'exemples.
2. J'ai créé en back-end un article non publié avec comme section : FAQ et comme catégorie : Général.
3. Dans les paramètres de l'article, j'ai réglé 'Afficher le Titre' et 'Icône E-mail' sur "Masquer".
4. J'ai enregistré l'article et accédé au front-end du site. Je me suis connecté en front-end en qualité d'administrateur et cliqué sur l'élément de menu : Pages d'exemple -> Catégorie Blog.

• Ce qui s'est passé : le nouvel article s'affiche mais il n'y a pas d'icône à cliquer pour que l'utilisateur puisse modifier l'article en front-end.
• Ce qui aurait dû se passer : l'icône de modification devrait s'afficher, permettant à l'utilisateur de modifier l'article en front-end.
• Autres informations : cela se produit uniquement avec le template rhuk_milkyway. En modifiant ce code [code proposé] dans le fichier [nom et hiérarchie de fichier], ligne(s) #, le problème semble résolu au regard de mes paramètres.

Proposer un 'pull request' directement sur le répertoire Joomla! de GitHub

Si vous souhaitez proposer un correctif directement dans le code de Joomla!, vous pouvez le faire en faisant un "pull request" directement sur le code du répertoire Joomla! présent sur GitHub.com, que vous pouvez retrouver ici: https://github.com/joomla/joomla-cms

Ce processus nécessite des connaissances particulières sur les systèmes de Gestion de Contrôle de Source (SCM - Source Control Management) et de Git en particulier. Si vous connaissez le SCM Git et son fonctionnement, le processus est relativement simple.:

• Ouvrez gratuitement un compte sur GitHub.com
• Faites un 'Fork' du répertoire Joomla!
• Passez à la branche "staging" si vous souhaitez proposer une correction pour la version actuelle de Joomla! 3.x ou à une autre branche si vous souhaitez proposer une correction pour la prochaine version de Joomla!
• Mettez à jour/ajoutez les fichiers concernés dans la bonne branche de Joomla! et cliquez sur le bouton "review & compare" pour commencer la procédure de "pull request". Retrouvez d'autres informations sur le sujet à l'adresse : https://help.github.com/articles/using-pull-requests

Trucs et Astuces

Des rapports d'anomalies bien rédigés sont incroyablement utiles. Cependant, il existe de nombreuses tâches à accomplir avant de pouvoir travailler sur le traqueur. Votre aide est grandement appréciée, et notamment afin de conserver toute l'utilité de cet outil. Ainsi, merci de veiller avant toute chose à:

• Lire la FAQ pour voir si votre anomalie a déjà une réponse connue.
• Rechercher et vérifier sur le tracker si votre anomalie n'est pas déjà présente.
• Demander d'abord sur les forums Joomla 3.x si vous n'êtes pas sûr que le problème rencontré soit une anomalie.
• Rédiger des rapports spécifiques les plus complets possible et permettant de reproduire facilement les anomalies. Pensez à fournir autant d'informations que possible, avec des extraits de code, des exemples de tests à entreprendre, etc. Un exemple simple permettant d'illustrer l'anomalie ainsi que les tests relatifs.
• N'utilisez pas le système de suivi pour poser des questions de support. Utilisez les forums Joomla! à cette fin.
• N'utilisez pas les trackers pour faire des demandes de fonctionnalités à grande échelle. Nous préférons discuter de tout changement majeur dans le cœur de Joomla! sur les forums des développeurs avant de les mettre en œuvre.
• Ne rouvrez pas les problèmes qui ont été marqués comme "comportement attendu". Cette marque signifie que la décision a été prise que nous ne pouvons pas ou ne corrigerons pas ce problème particulier. Si vous n'êtes pas sûr de la raison, veuillez poser la question sur les forums des développeurs.
• N'utilisez pas le tracker pour des discussions longues, car elles risquent d'être perdues. Si un élément particulier du tracker suscite la controverse, veuillez déplacer la discussion vers les forums des développeurs.

Signalement de problèmes de sécurité

Signalez toutes les questions concernant la sécurité à l'adresse security[at]joomla[dot]org. C'est une liste privée ouverte uniquement aux développeurs reconnus de Joomla! et ses archives ne sont pas publiques.

En cas de vulnérabilité confirmée dans Joomla! lui-même, les mesures suivantes seront prises:

• Envoi à l'expéditeur d'un accusé de réception du rapport et qu'un correctif sera à venir. Une ébauche de feuille de route sera produite avec une demande faite au rapporteur de garder ces informations, y compris le rapport, confidentielles jusqu'à ce que l'annonce soit officielle.
• Arrêter tous les développements en cours aussi longtemps que nécessaire afin de produire un correctif, comprenant des patchs pour la version en cours ainsi que pour les deux versions précédentes.
• Déterminer une date pour l'annonce de la vulnérabilité et du correctif. Pour essayer d'atténuer les effets d'une possible "compétition" entre ceux qui vont appliquer les correctifs et ceux qui cherchent à exploiter les failles, nous n'annoncerons pas les failles de sécurité immédiatement.
• Annonce publique de la vulnérabilité et d'une date pour le correctif. Cela implique souvent la diffusion d'une nouvelle version de Joomla! mais, dans certains cas, il peut tout simplement s'agir de patchs à appliquer sur la version courante.