当サイト、Codex 日本語版は今後積極的な更新は行わない予定です。後継となる新ユーザーマニュアルは、https://ja.wordpress.org/support/ にあります。
万が一、当サイトで重大な問題を発見した際などは、フォーラムWordSlack #docs チャンネルでお知らせください。</p>


提供: WordPress Codex 日本語版
移動先: 案内検索
(3 版)

2008年4月4日 (金) 03:36時点における版

すべてのアプリケーションにはバグがあります。あなたが気づこうが気づくまいが、それらは存在します。そして、人間がコードを書く限り、ソフトウェアの中にエラーは存在し続けるでしょう。しかし、些細なものであれ重大なものであれ、バグはアプリケーション開発の終わりを告げるものではありません。 — 実際はその正反対です。特に、オープンソース・プロジェクトにおいては、コミュニティの参加が開発の継続に不可欠です。フィードバックを与えてくれるユーザがいなければ、WordPressが今日のような発展を遂げることは、大変困難なものとなったでしょう。

すべての種類のフィードバック — それが真にバグであろうと、機能への要望であろうと — は同じ方法で報告されます。WordPressにバグや問題点を報告する方法を学ぶには、以下をお読みください。

Reporting security issues

私たちはセキュリティ問題を防止すべくあらかじめ取り組んでいますが、(傲慢にも)それらが絶対に発生しないとは考えていません。もしあなたが、リリース中のWordPressにセキュリティ上の問題を発見した場合、secrity at the WordPress.org ドメインにメールを送ってください(訳注:メールアドレスに読み替える)。そうすれば、私たちは可能な限り早急に対処できるよう最善を尽くします。


A note about plugin bugs


プラグインの公式リポジトリである WordPress Plugin Repository にあるプラグインは、WordPress本体とは 別のバグ追跡システム を採用しています。このシステムを使用するには Separate instructions が役立ちます。


Before you submit


  1. あなたの発見したバグや要望を 公開または解決されたバグのリストから探す。
    • あなたが発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、あなたが更なる情報を寄与できる場合は、既存のバグノートに追加してください。
    • あなたが発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
  2. 次のガイドライン 効果的なバグ報告の方法 を読んでください。これは非常に情報に富んだ記事で、ここに挙げられている手続きはバグ報告システムをより効果的にするのに大いに役立つでしょう。

Submitting your bug to Mosquito

Mosquito is the name of the official WordPress bug tracker. It uses the open source bug tracking software Mantis. Follow these steps for creating a good bug report in Mosquito:

  1. If you do not already have an account on Mosquito, create one. This is essential for communication about your bug, since the developers may need more information from you after you submit.
  2. Once you've logged in, click Report Issue to view the bug reporting page. Fill out the following fields:
    General categorization of the bug.
    How consistently the bug appears. For feature requests, this should be N/A.
    The significance of the issue. Options are:
    A feature request.
    Very non-critical; not an error per se, just a little better way of doing things.
    Anything to do with text changes, spelling or grammar errors.
    Extremely minor error in functionality, which differs only slightly from the way it should work.
    Minor error in functionality, non-fatal.
    Major error in functionality, but still non-fatal.
    A fatal, critical error which prevents WordPress from functioning at all after the issue is encountered.
    A fatal, critical error which prevents other bugs from being fixed, or which is a significant enough roadblock to prevent developers or testers from being able to continue until it is fixed.
    The urgency with which the issue should be addressed.
    Platform information 
    Advanced Report only. If your bug pertains to the way pages render in a particular browser, you should fill these fields in:
    Enter your browser name and version here. Be specific! If it has a build date or specific revision number, include that. Otherwise, specify the exact point release.
    Operating system on which you are running the above browser.
    OS Version 
    Version of the operating system you're using. Be specific! Include service pack numbers, security updates, etc. If it has a build date or specific revision number, include that. Otherwise, specify the exact point release.
    Note: You can set up platform profiles in your Mosquito account for future availability under the Select Profile dropdown menu. Click My AccountProfiles to configure your saved profiles.
    Product Version 
    Select the version of WordPress you found the bug in.
    Product Build 
    Advanced Report only. Enter the specific WordPress version in which you found the bug. If you are testing a nightly, copy and paste the version string found in the footer of any Admin screen. If you are using a Subversion release, enter the revision number.
    A useful, descriptive sentence or phrase which describes the problem succinctly. Summaries should be like poetry: The goal is to maximize the amount of information you convey in the summary, while distilling it down into only the most essential words. If you're really good, you can work in words that imply circumstances and other information about a bug without explicitly saying it.
    A more detailed description of the symptoms of the bug. (If you wrote a really good Summary, this should feel like a lot of rehashing.)
    Steps to Reproduce 
    Advanced Report only. A detailed account of all steps required to reproduce your bug. Once you're finished compiling your steps, be sure to follow them yourself and make sure you can reproduce it yourself using the steps you wrote.
    Additional Information 
    Use this field to specify the variables (settings, plugins, etc.), or just give additional information that's not actually a description of the bug.
    Upload File 
    If you have a patch to submit (yay!), use this to upload your diff. Then pat yourself on the back.
    View Status 
    Very rarely needed, but very important. If you are submitting a potential security vulnerability, the knowledge of which could make WordPress blogs everywhere vulnerable to attack, select Private. There is important protocol to follow when submitting security-related issues for software of any kind, and it involves containing knowledge of a potential vulnerability until developers have had a sufficient opportunity to distribute a fix. This helps minimize users' vulnerability until a fix is available.
    Report Stay 
    Check this if you have another bug to report immediately after you submit this one. (Be sure you've already searched for the next bug!)
  3. Click Submit Report. Then pat yourself on the back. (Even if you've already done so.)
  4. As the bug's Reporter, you will automatically be notified by email any time a change is made to this report, or a Bugnote is added. Don't ignore these emails; any time a change is made, be sure to check the report for updates. Developers may need further information from you, and this is their only way of getting in contact with you.


  • The processing of your bug may require your participation. Please be willing and prepared to aid the developers in resolving the issue.
  • Don't be upset if your bug gets resolved as "Not a bug" or "Won't fix." What seems like a bug to you may very well be a "feature."
  • Thank you for contributing to the development of WordPress!