バグや問題の報告

From Joomla! Documentation

This page is a translated version of the page Filing bugs and issues and the translation is 100% complete.

Other languages:
català • ‎Deutsch • ‎English • ‎español • ‎eesti • ‎français • ‎Bahasa Indonesia • ‎italiano • ‎日本語 • ‎Nederlands • ‎português • ‎русский • ‎svenska • ‎Türkçe • ‎中文(台灣)‎

Joomla! bug trackersでバグを報告するには、tracker itemを作成する必要があります。tracker itemが作成されれば、開発者が有効性を確認し、それに応じて行動します。Joomlaのパッチのテストを助けていただけるのでしたら、こちらの詳細説明に従ってください。

バグの報告

GitHubアカウントの登録

GitHubでアカウントの登録を行ってください。Joomla! Issue Trackerは認証にGitHubアカウントを使用しています。

Joomla! issue trackerにアクセス

既にバグが報告されているかの確認

表の上の「Search Tools」ボタンをクリックすると、一連のフィルタにアクセスできるようになります。検索窓をマウスオーバーでその中身を確認できます。発生している問題がまだ報告されていない場合は、メインナビゲーションエリアの「New Item」ボタンをクリックしてください。

新たな画面が表示されますので、そこに多くの情報を書き込むほど、開発者が助かります。

できるだけ多くのデータを書き込んでください。右上の「View Mode」でProとHelpを切り替えると、各フィールドのヒントの表示を切り替えることができます。

  • Priority : 他の選択肢を選ぶのに充分なだけのコードの知識がある場合を除き、デフォルトの「Medium」を選択してください。
  • Build :問題の発生しているバージョンを入力してください。
  • Categories :ここは最もトリッキーです。よくわからない場合は「Administration」を使用してください。
  • Title :問題の簡単な要約です。
  • Description : 問題の詳細です。 詳しくは、以下のセクションを参照してください。
  • Uploads : ユーザーは報告のために画像をアップロードすることができます。アップロードの条件は、レポートフォームに記載されています。

要約の書き方

あなたが抱えている問題を少しの言葉で表現してください。初めてバグを報告するときは、既存のものを参考にしてみてください。

例えば:

  • Front-end: Warning such and such.
  • Back-end: Unable to save article when "nameofplugin" is published.

注:開発者が問題点を修正するためにtrackerを通読しているときに、最初に目にするものです。ですので、要約が説明になっているよう気をつけてください。

バグに関する詳細の書き方

できるだけ多くの情報を提供するために、入力欄には5つのサブセクションのあるテンプレートが表示されています。:

  • Steps to reproduce the issue : 他の人がその問題を再現するための詳細な手順。
  • Expected result :上記の手順を踏んだ際に、どのようになってほしかったのか。
  • Actual result : 上記の手順で実際にはどうなったのか。
  • System information : システムが構成されている環境の情報。使用しているブラウザ、サーバーのPHPバージョン、サイトで使用しているデータベースの種類を含みます。この情報は、管理者セクションにログインして、サイトのシステムインフォメーションからコピーすることができます。
  • Additional comments : 上記に記載されていない追加情報も問題の解決やトラブルシューティングに役立ちます。

一般的な形式は次のようになります:

  1. "やったことを正確に"
  2. "何が起きたのか。"
  3. "どうなると思っていたのか。"
  4. "その他の情報、考えられる解決策、提案されたコードパッチ。"

詳細は多いほど良いです。また、サンプルのJoomla!サイトを使用したり、簡単で明確な手順を用いてバグの再現確認をすることも重要です。他の人があなたのサイトのデータベースにアクセスできないことを忘れないでください。そのため、他の人にバグを見るための方法を教える必要があります。 -- the sample site

例A

何をしたのか 
Started with sample website. Everything was ok. I enabled "nameofplugin". Try to save any article from back end.(サンプルウェブサイトで始めました。きちんと動いていました。"nameofplugin"を有効にしました。バックエンドで記事を保存しようとしました。)
何が起きたのか 
I get a blank screen and article is not saved.(空白の画面が表示され、記事は保存されませんでした)
どうなって欲しかったのか 
Articles should save correctly.(記事がきちんと保存される)
その他の情報 
These are the plugins enabled at the same time. SEF is on (or Off). My site is in a sub-folder. I also remark that... etc. Files such and such are the issues IMHO (何を言っているのか分かるなら).

例B

何をしたのか 
Navigate to Back-end. Click on "menu_name" Menu.(バックエンドへ移動し、「menu_name」メニューをクリックしました。)
何が起きたのか
Page opened is blank.(開いたページは空白でした)
どうなって欲しかったのか 
Menu should have opened correctly.(メニューがきちんと開く)
その他の情報 
Any other menu works OK. etc.(他のメニューはきちんと動いています。など)

実際の例

  • 何をしたのか
  1. Started with the sample website.(サンプルサイトで開始した)
  2. Added an unpublished article from the back end, with Section=FAQ, Category=General.(バックエンドで非公開記事を追加した。Section=FAQ, Category=General)
  3. In the advanced parameters for the article, set Show Title to "No" and Print, PDF, and Email Icons to "Hide".(記事の高度なパラメータで、Show Title を "No"、PrintとPDFとEmail Iconsを"Hide"にした。)
  4. Save the article and navigate to front end. Login to the front end as admin and navigate to the Example Pages -> Category Blog menu item.(記事を保存し、フロントエンドへ移動した。adminとしてログインし、Example Pages -> Category Blogメニューへと移動した。)
  • 何が起きたのか : The newly added article shows but there is no edit icon for the front-end user to click on.(最後に追加した記事は表示されたが、フロントエンドユーザーがクリックするeditアイコンがない)
  • どうなって欲しかったのか: The edit icon should show, allowing a front end user to edit this article.(editアイコンが表示され、フロントエンドユーザーが記事を編集できるようになる)
  • その他の情報 : This only happens with the rhuk_milkyway template. By changing this code [code proposed] in file [name and hierarchy of file], line(s) #, the issue looks solved on my settings.(rhuk_milkywayテンプレートでのみ発生します。[ファイルの名前と階層]ファイルの#行目を[コードの提案]に変更することで、私の設定での問題は解決したように思う。)

Joomla!のGitHubリポジトリで直接pull requestを行う

Joomla!のコードを直接書き換えることでの修正を望む場合、GitHub.com上のJoomla!のコードのリポジトリで"pull request"を行うことでできるかもしれません。こちらです→: https://github.com/joomla/joomla-cms

この方法には、ソース管理システムと特にGitに関するある程度の知識が必要です。 Git SCMとは何か、それがどのように機能するのかを知っていれば、簡単です。:

  • 無料のGitHub.comアカウントにsign upしてください。
  • Joomla! リポジトリをForkします。
  • 現在リリースされているJoomla! 3.xを修正する場合は"staging" branchへ、次のバージョンへ修正したい場合は"3.x-dev" branchに切り替えてください。
  • Joomla!の正しいbranchで関連ファイルを追加/更新し、"pull request"の発行プロセスを開始するために、"review &compare"ボタンをクリックします。さらに詳しくは https://help.github.com/articles/using-pull-requests をご覧ください。

追加のヒントとコツ

よく書かれたバグレポートは非常に役立ちます。しかしながら、バグトラッキングシステムが機能するには限界があります。ですので、できるだけ使いやすく機能するようにご協力ください。:

  • FAQ を読んで、あなたの問題がよくある問題なのか確認してください。
  • あなたの問題が既に提出されているのか、the trackerを検索してください。
  • 遭遇したことがバグか確信が持てないときは、まず Joomla 3.x のバグレポートフォーラムで尋ねてください。
  • バグレポートは、具体的に、再現可能なように、きっちり書いてください。コードスニペットやテストケースまで、可能な限り多くの情報を書いてください。簡単なテストケースでバグの説明をコンパクトにまとめたものが、最も良いバグレポートです。
  • トラッカーシステムをサポートの質問に使用しないでください。 Joomla! forums やIRCチャンネルの #joomla を使用してください。
  • トラッカーを大きなスケールの将来へのリクエストに使用しないでください。Joomla!のコアの大きな変更は、実際に動き出す前に developers forums で議論しています。
  • "not a bug"とマークされた問題を再度オープンにしないでください。このマークは、問題を直せない、もしくは、直さないと決定したことを意味しています。何故なのか疑問に思ったら、developer forumsで尋ねてみてください。
  • 議論が迷子になる可能性がありますので、長い議論はtrackerで行わないでください。論争の多いtracker itemがあれば、 developer forums へ移動させてください。

セキュリティーの問題の報告

セキュリティーに関する問題は、security [at] joomla [dot] orgに報告してください。このリストは、長く信頼されているJoomla!の開発者のみに公開されており、一般には公開されていません。

Joomla!自体に脆弱性が確認された場合には、次のことを行います。:

  • 報告を受けたこと、修正が予定されていることを報告者に連絡します。大まかな予定を示し、我々がアナウンスを行うまで、問題を秘密にするよう報告者に依頼します。
  • 現在やその前のリリースのパッチを含む修正のため、他の開発を停止します。
  • 惰弱性と修正を公にアナウンスする日程を決定します。更新プログラムを適用するユーザーとその脆弱性を悪用しようとするユーザーの間の起こりうる「軍拡競争」を軽減するために、セキュリティ上の問題を直ちに発表することはしません。
  • 脆弱性および修正点を決定していた公開日に公表します。おそらく、Joomla!を新しくリリースするでしょうが、現在のリリースのパッチになるかもしてません。