バグの報告

セキュリティに関する問題の報告

私たちはセキュリティの問題を未然に防ぐために積極的に取り組んでいますが、セキュリティの問題が絶対に起きないとは考えていません。WordPress のリリースにセキュリティの問題を発見したと思われる場合、セキュリティに関する FAQ で問題の報告方法についてご覧ください。

セキュリティの問題を公表する前にベンダー (この場合は WordPress のセキュリティチーム) に通知するのが標準的な慣行であり、修正プログラムを準備し、脆弱性による被害を最小限に抑えることができます。

Top ↑

バグレポートと解決の概要

WordPress のバグを報告し解決するプロセスには多くのステップがあります。ここではその概要を説明します:

  • (テーマやプラグインではなく) WordPress のコアにあると思われるバグをユーザーが見つけた場合。
  • ユーザーは、それが実際にまだ報告されていないバグであることを確認します。
  • ユーザーが WordPress のバグトラッカーである Tracticket と呼ばれるバグレポートを提出します。
  • WordPress 開発者 (あなたのようなボランティアです) が、バグが実際に存在し、修正されるべきであると確認し、そのようにコメントします。
  • WordPress 開発者 (あなたかもしれません) がバグを修正することを決定します。開発者はバグを修正する方法を考え、パッチを作成し、パッチを Trac にアップロードします。
  • WordPress 開発コミュニティのメンバーがパッチをテストし、バグが修正されているか、他に何も壊れていないかを確認します。また、バグとパッチに対して自動テストを実行したり、新しいテストを書いたりします (または新しいテストを書くように提案します)。
  • 公式の WordPress ソースコードを修正する権限を持つ WordPress 開発者の一人が、SVN リポジトリのコアコードにパッチをコミットします。そのバグやパッチが信頼できる人によって検証されたものであれば、そのようなことをする可能性は高くなります。WordPress の開発は主に信頼と功績のシステムで運営されています。
  • パッチをコミットした人はバグを修正済みとして閉じます。

Top ↑

バグを報告する前に

WordPress のような大規模なプロジェクトでは、非常に多くのユーザーがバグを報告するため、あなたのバグがすでに報告されている可能性が高いです。このため、バグを報告する前に、そのバグがすでにシステムに登録されていないか確認することが非常に重要です。WordPress でバグを報告するのが初めての場合は、経験豊富な開発者に相談してから報告するのもよい方法です。

1. バグが実際に WordPress コアに起因していることを確認してください。

エラーメッセージがコアファイルを指しているからといって、そこに問題があるとは限りません。Debug Bar のようなプラグインを使って問題を突きとめたほうがいいかもしれません。このデバッグファイルのような簡単なスクリプトを使えば、エラーの原因がどこにあるのかを正確に突きとめることができます。(このファイルは wp-content/mu-plugins ディレクトリに置くことができます。存在しない場合は作成してください)。

もう一つの重要な戦略は、プラグインやテーマを追加していない、新しい WordPress インストールでバグを再現してみることです。これは常に可能ではないかもしれませんが、新しいインストールでもバグが見つかれば、問題はコアにある可能性が高いです。

2. バグや機能強化の要望を検索してください。

  • あなたの問題がすでに報告されている場合、重複したバグを報告しないでください。さらに貢献できる情報がある場合は、既存のバグにメモを追加してください。
  • あなたの問題が他の問題と類似しているが、まったく同じではない場合、類似した問題にメモを追加するか、新しい問題を報告するかを決めることができます。一般的に、現在進行中の未解決の issue に貢献できる情報があれば、その issue にメモを追加してください。別の十分な問題がある場合、または以前に解決した問題が再発した場合は、新しいバグを報告してください。いずれにせよ、あなたが問題を投稿すれば、コアの貢献者がアドバイスを提供してくれるでしょう。
  • あなたの問題が最近報告され、その後クローズされ、あなたがその解決策に同意しない場合でも、あなたの理由をコメントとして投稿できます。
  • クローズされたバグを再オープンしないことがベストです。そのバグがすでにリリースされた WordPress のバージョンで修正済みとしてクローズされた場合 (Milestone フィールドを参照)、新しいチケットを開いてください。
  • Version フィールドは、バグが最初に発見されたバージョンに関連します。新しいバージョンで同じバグが見つかった場合は、コメントでその旨を書いてください。ただし、バージョン番号は変更しないでください。

3. バグを報告する前に、可能性のあるバグについて議論することを検討してください。

Top ↑

バグを報告する

Trac は WordPress の公式バグトラッカーの名前です。Edgewall Software によるオープンソースのバグトラッキングソフトウェア Trac を使用しています。Trac について詳しくは、バグトラッカー (Trac) を参照してください。良いバグレポートを作成するには:

  1. バグを報告する前に行うべきことについては、上記のセクションを参照してください。
  2. サポートフォーラムのユーザー名とパスワードを使って WordPress Trac にログインします。サポートフォーラムのアカウントを持っていない場合は、登録してください。
  3. Trac の New Ticket をクリックして、バグレポートページにアクセスします。
  4. タイトル、概要、その他のフィールドを記入してください。詳しくは チケットのプロパティを参照してください。
  5. プレビュー後、Submit Ticket をクリックしてください。

あなたがチケットを提出したからといって、あなたのやることが終わったわけではありません。開発者はチケットをレビューする際に、より多くの情報を必要とするかもしれません (そして、チケットに reporter-feedback というタグをつけて、特にあなたに詳細な情報を求めるかもしれません)。

また、提案された修正によってあなたが遭遇した問題が解決されるかどうかを確認することも役立ちます。バグの処理にはあなたの協力が必要な場合がありますので、開発者が問題を解決することを手助けできるよう準備してください。バグの修正にご協力いただける場合は、バグの修正セクションをご覧ください。

Trac 設定にメールアドレスを入力していれば、チケットが更新されたときに自動的に電子メールが送信されます。

原文 / 日本語訳

最終更新日: