• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。（詳細）

【このWikiはいつでも誰でも編集できます】

バグの報告

提供: WordPress Codex 日本語版
移動先: 案内、 検索
英語版は次のURLに移動しました。最新版はReporting Bugs をご覧ください。 なお、以下にある以前の日本語訳は残しますが、内容が古くなっている可能性があります。
  1. REDIRECT [1]


すべてのアプリケーションにはバグがあります。人間がコードを書く限り、ソフトウェア中のエラーがなくなることはないでしょう。エラーには些細なものあれば、重大なもあります。WordPress のようなオープンソース・プロジェクトにおいては、新しい機能を計画するのと同じように、バグを確認するためにユーザーコミュニティの参加が不可欠です。

WordPress プロジェクトでは、純粋なバグでも新機能の要望でも、すべての種類のフィードバックを同じ方法で報告するようになっています。WordPress のバグや問題点を報告する方法を知るには、このページを読み進めてください。また、ドキュメンテーションなどの部分でプロジェクトに協力する手段を知りたい方は、WordPress への協力ページも読んでみてください。

私たちはセキュリティ問題を防止するための積極的な取り組みを行っていますが、絶対に問題が発生しないとは考えているわけではありません。もしリリース済みバージョンの WordPress にセキュリティ上の問題を発見した場合、security アット WordPress.org へメールを送ってください（訳注：メールアドレスに読み替える）。できるだけ早急に対処できるよう最善を尽くします。

修正の準備を整え、脆弱性による一般ユーザーの被害を最小限に抑えられるよう、セキュリティ問題を公表する前に提供元（この場合、WordPress の開発者）に告知するのは標準的な習慣です。

プラグインとテーマのバグの報告

WordPress で使っているプラグインやテーマのバグを発見した場合は、このページにある方法での報告を行わないでください。このページの説明は WordPress 本体のバグにのみ適用されるものであり、プラグインやテーマのバグに対しては適用外です。

プラグインの公式リポジトリである WordPress Plugin Repository にあるプラグインは、WordPress本体とは 別のバグ追跡システム を採用しています。このシステムの使い方については、別途に TracTickets の取扱説明書が用意されています。

公式リポジトリに属さないプラグインについては、プラグインに同梱されていたドキュメントを読んで、バグの報告先を調べてください。もし、バグ報告に関する情報が記載されていなかった場合、そのプラグインの開発者に直接連絡を取る必要があります。

バグの報告と解決の概要

WordPress のバグ報告と解決には、複数の手順があります。以下が概要となります。詳細はさらに続きを読んでください。

  1. ユーザーが（テーマやプラグインではなく）WordPress 本体のバグを発見する。
  2. それが実際にバグかどうか確認する。下記のバグを報告する前にをご覧ください。
  3. もしバグであることが確実になったら、チケットと呼ばれるバグ報告を WordPress のバグ追跡システムである Trac に送信する。下記のバグの報告をご覧ください。
  4. WordPress 開発者（この人もあなたのように、ボランティアかもしれません）がバグの存在を確認し、修正するべきと判断し、チケットにそのことを記録します。下記のTrac キーワード一覧とバグの解決をご覧ください。
  5. WordPress 開発者（あなた自身ということもありえます）が、このバグを修正することにします。チケットページの最後の方にあるAccept ticket（チケットを受理）をクリックしてバグの責任を負うことを選ぶことができますが、これば必須ではありません。それからその開発者はどうやってバグを修正するかを考え、ひとつまたは複数のパッチファイルを作成し、そのファイルを Trac にアップロードします。下記のバグのパッチ作業をご覧ください。また、バグ修正に協力したいけれどどのバグを直していいか分からない場合は、以下の修正するバグを見つけるをご覧ください。
  6. WordPress 開発グループのメンバー（ボランティアも含む）がパッチをテストし、バグが修正されているか、その他の部分に悪影響がないかを確認します。結果を知らせるため、チケットにコメントやキーワードを追加します。下記のTrac キーワード一覧をご覧ください。
  7. 公式な WordPress のソースコードを編集する権限がある主要開発者（公式サイトの Lead Developers 参照）のうちの誰かが SVN リポジトリへパッチをコミットします。主要開発者は、バグやパッチが信頼のおける人によって検証された場合にこの作業を行う可能性が高いでしょう。
  8. 最後に、パッチをコミットした人がバグチケットのステータスを closed に、解決法を fixed（修正済み） に変更します。下記のバグの解決プロセスをご覧ください。

バグの報告と解決の詳細

以下のセクションでは、上記で説明された内容についてさらに詳しく説明しています。

バグを報告する前に

WordPress のような大きなプロジェクトでは、多くのユーザがバグを報告しているため、あなたが発見したバグは既に報告されている可能性があります。このため、バグを報告する前にそれがまだバグ追跡システム内に存在しない問題であることを確認することは非常に重要です。WordPress のバグ報告にまだなじみがないようでしたら、経験がある他の開発者に話してみるのがよいでしょう。以下の手順に従ってください。

  1. 発見したバグや要望を 公開または解決されたバグのリストから探す。
    • 発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、追加情報を寄与できる場合は、既存のバグノートに追加してください。
    • 発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
    • 最近チケットが作成され、closed になった問題に関して解決方法に納得がいかない場合、チケットを再度開いてその理由のコメントを追加できます。
  2. Trac でチケットを再度開く前にバグについて話し合いたい場合（例: プラグインやテーマのせいで発生する現象なのか、それとも本当に WordPress コアのバグなのか解明する）は、質問を WordPress Support Forum（または日本語サポートフォーラム）や #wordpress IRC channel/en に投稿したり、Testers・Hackers メーリングリストで話し合うと良いでしょう。

バグの報告

公式 WordPress バグトラッカーは Trac と呼ばれています。Edgewall Software の製品で、オープンソースバグトラッキングシステムである Trac を使っています。Trac で良いバグ報告を行うには、以下のステップに従ってください。

  1. 上記のバグを報告する前にセクションを読んで、報告するにふさわしい新しいバグを発見したかどうかを検証する。
  2. How to Report Bugs Effectively、Trac Ticket ドキュメンテーションを読む。
  3. サポートフォーラム（または日本語サポートフォーラム）のユーザー名とパスワードを使って WordPress Trac にログインする。アカウントを持っていない場合は、新規登録する。開発者が詳しい情報を必要としている場合があり、ログインしないとチケットを作成できないため、このステップはバグに関してのコミュニケーションには欠かせません。
  4. Trac で New Ticket をクリックし、バグ報告ページへ移動する。
  5. チケット新規作成ページで以下の情報を記入する。
    Short Summary（概要）
    概要はチケットのタイトルになり、検索結果に表示されることになるので、短くかつ説明的で正確になものにしましょう。
    Full Description（説明）
    バグまたは新機能要望の完全な説明を記入しましょう。問題の説明、同様の問題を再現するための手順、（もしあれば）実際のバグが見られる URL など、そして、この問題を修正する価値がある理由を含めてください。また、OS、サーバーの種類、PHP・MySQL・WordPress のバージョンなどあなたの環境についても説明しましょう。説明が良いものであればあるほど、バグがすばやく解決される可能性が高くなるでしょう。
    Ticket Properties（チケットの属性）
    Priority（優先度）
    問題の優先度について決定します。これはバグの修正にどれだけ緊急度を要するかを示します。たいていは開発者が決定してくれるので、重大なバグでないかぎりデフォルトの状態のままにしておくのが良いでしょう。
    Component（コンポーネント）
    バグのある WordPress の部分を選択します。
    Severity（重要度)
    問題の 重要度。はっきりしない場合は 'Normal のままにしておきましょう。
    Assign to（担当者）
    バグのあるコードの担当開発者を知っている場合は、その人の Trac ユーザー名を入力します。自分のユーザー名を入れて、バグ修正を担当することもできます。これはオプションですが、記入することで開発者がすぐにバグに注意を払ってくれるかもしれません。
    Milestone（マイルストーン）
    遅くともこのマイルストーンまでに問題を解決するべきというバージョン。WordPress 開発者が設定するオプションのため、変更はしないでください。
    Version（バージョン）
    バグが見つかった WordPress のバージョン。管理画面のフッターでバージョンを確認できます。
    Keywords（キーワード）
    開発者がバグを発見し、影響がある部分を確認しやすくするためのキーワード。例えば投稿機能の場合は 'posting' など。また、バグの状態に関する標準キーワードもあります（以下の Trac キーワードを参照）。
    CC
    バグの情報や更新状況を送るユーザー。情報を追いたい場合は、自分のユーザー名を入れてください。チケットに変更が加えられたときやコメントが追加された時にメールで通知されます。通知があった場合には無視せず、チケットの内容を確認してください。開発者はチケット以外で連絡を取ることができませんが、ここで追加情報を必要としているかもしれません。
    注1: Trac の Preferences ページでメールアドレスを設定してください。サポートフォーラムのプロフィールにアドレスを入れても、Trac の CC メッセージは 届きません。
    注2: メールアドレスを設定しているバグの報告者には自動的にメールが届きますので、CC に入力する必要はありません。
  6. プレビュー後、Submit Ticket をクリックします。それから、「おつかれさま！」と自分の肩を叩いてあげてください。

修正するバグを見つける

WordPress コアのバグを修正したいけれど、どれに手を付けていいか分からない…という場合、以下を読んでみてください。

バグのパッチ作業

PHP や MySQL をよく知っていて WordPress の開発に協力したい場合は、バグのパッチ作成をお勧めします。以下のステップに従ってください。

  1. 上記の修正するバグを見つけるを読み、Trac で修正するバグを見つけます。
  2. 登録（日本語）したユーザー名とパスワードを使ってWordPress Subversion (SVN) レポジトリ に接続します。SVN を使ったことがない場合は、Subversion の使い方/en を読んでください。すべてのパッチは SVN レポジトリの最新コードに対して当てられるべきです。
  3. WordPress コアファイルを編集してバグを修正する方法を探します。仕上げる前に、wp-hackers メーリングリストで、提案したい解決方法を話し合った方が良いかもしれません。
  4. バグが直っているか、WordPress の他の部分に悪影響を与えていないかを検証するため、修正のテストを行います。
  5. 修正を含むパッチファイルを作成します。基本的にはこれは SVN の元ファイルと修正部分の diff です。詳しくは How to Patch WordPress by Owen Winkler をご覧ください。また、Linux/Mac コマンドラインユーザー向けには、Mark Jaquith's Toolbox が、Windows Tortoise SVN ユーザー向けには Westi のブログ上に説明があります。
  6. このパッチファイルを Trac の Attach file ボタンを使ってアップロードし、has-patch というキーワードを追加します。例えばパッチのテストが必要な場合は、needs-testing など、その他の Trac キーワード（下記）も必要に応じて加えましょう。

Trac キーワード

Trac には、よく使われる定義済みのキーワードが複数あります。このうち一部は Trac Reports で検索できます。

reporter-feedback（要報告者フィードバック）
報告者からのフィードバックが必要。同様の問題が起きている人からの質問に対する反応がない限り先に進めない状態。
has-patch（パッチあり）
チケットの解決策がパッチとしてアップロードされていて、レビューまたはコミット待ちの状態。
needs-testing（要テスト）
解決策のテストが必要。
2nd-opinion（要意見）
問題または解決策に関する第三者の意見が必要。
dev-feedback（要開発者フィードバック）
開発者からのフィードバックが必要（あまり使われないキーワード）
tested（テスト済み）
パッチがテスト済み。このキーワードを追加する場合は、パッチのファイル名・テスト実施の状況・テストを行った WordPress のバージョンをコメントに記入すること（公式リリースバージョンでない場合は、SVN リビジョン番号も含める）。
commit（コミット可）
パッチが開発コミュニティで信頼されているメンバーによってレビューおよびテストされ、WordPress コアファイルに追加できる状態。
needs-patch（要パッチ）
チケットのレビュー後、解決が望ましいと判断され、特にパッチが必要とマークされた状態。または投稿されたパッチがうまく動作せず、やり直しが必要な状態。
needs-unit-tests（要ユニットテスト）
チケットのレビュー後、解決が望ましいと判断され、コミットの前に機能や既存のパッチのユニットテストを行いたいと開発者が考えている状態。変更を行うことで他の問題が発生するリスクが高い場合に使われる。
needs-doc（要ドキュメンテーション）
コードのインラインドキュメンテーションが必要。個別ファイル用のプレースホルダー、またはコミットの前にドキュメンテーションが必要な新規機能のパッチを含むチケット。

バグの解決プロセス

Trac のチケットはまず open 状態からスタートし、（うまくいけば）最終的には closed になります。チケットがクローズされる場合、以下のいずれかになります。

  • バグがすでに他で報告済みの場合、たいていは duplicate としてクローズされます。
  • バグが最新の Subversion コード（テスト環境でない場合はこのコードをお使いではないでしょう）中ですでに修正済みの場合、fixed としてクローズされます。
  • 報告したバグが実際にはバグではなく意図された動作の場合、invalid としてクローズされます。
  • 他の人が説明した状況を再現できない場合、worksforme としてクローズされます。
  • バグではなく開発者がコアには入れるつもりがない機能の要望だった場合、wontfix としてクローズされます。

報告する前に、バグがこれらに当てはまらないことを検証してください。

注

  • バグの処理には協力が必要な場合があります。問題を解決するために開発者への協力をする心づもりをしておいてください。
  • 報告した問題が "Not a bug（バグではない）" や "Won't fix（修正しない）" という解決方法に落ち着いたとしても、気を悪くしないでください。あなたにとってバグと思われることは、そういう「機能」かもしれないということは十分あり得ます。これらの解決方法は単に「現在は修正するつもりはない」ということですので、将来優先的に直される可能性もあります。
  • WordPress の開発へのご協力ありがとうございます！

最新英語版： WordPress Codex » Reporting Bugs （最新版との差分）

「http://wpdocs.osdn.jp/wiki/index.php?title=バグの報告&oldid=11323」から取得