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

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

「バグの報告」の版間の差分

提供: WordPress Codex 日本語版
移動先: 案内検索
(ページ Reporting Bugsバグの報告 へ移動: ページ名を日本語化(Project:ページ名対応表参照))
(最新版に更新、未翻訳。和訳済み部分はコメントアウト英文を差し替えただけ。)
1行目: 1行目:
{{Old}}
+
{{NeedTrans||
 +
 
 +
* 最新英語版に差し替えました。
 +
* 翻訳済みだった部分は、コメントアウトされていた英文を最新版に差し替えただけです。履歴の差分表示か英文と見比べて、必要に応じて和訳を更新してください(言い回しの違いは直さなくて構いません)。
 +
}}
  
 
すべてのアプリケーションにはバグがあります。あなたが気づこうが気づくまいが、それらは存在します。そして、人間がコードを書く限り、ソフトウェアの中にエラーは存在し続けるでしょう。しかし、些細なものであれ重大なものであれ、バグはアプリケーション開発の終わりを告げるものではありません。 — 実際はその正反対です。特に、オープンソース・プロジェクトにおいては、コミュニティの参加が開発の継続に不可欠です。フィードバックを与えてくれるユーザがいなければ、WordPressが今日のような発展を遂げることは、大変困難なものとなったでしょう。
 
すべてのアプリケーションにはバグがあります。あなたが気づこうが気づくまいが、それらは存在します。そして、人間がコードを書く限り、ソフトウェアの中にエラーは存在し続けるでしょう。しかし、些細なものであれ重大なものであれ、バグはアプリケーション開発の終わりを告げるものではありません。 — 実際はその正反対です。特に、オープンソース・プロジェクトにおいては、コミュニティの参加が開発の継続に不可欠です。フィードバックを与えてくれるユーザがいなければ、WordPressが今日のような発展を遂げることは、大変困難なものとなったでしょう。
<!--Every application has bugs. Whether you see them or not, they're there. And as long as humans write code, there will continue to be errors in software. Some errors are trivial, some are critical, but no bug heralds the end of an application's development &mdash; in fact quite the contrary: In open source projects in particular, community participation is essential to continued development. Without users like you providing feedback, WordPress would be hard pressed to make improvements the way it does.-->
+
<!--Every application has [[Wikipedia:Computer bug|bugs]] -- as long as humans write code, there will continue to be errors in software. Some errors are trivial, while others are critical. Open-source projects like [[WordPress]] need the participation of their user communities to identify bugs in their software, as well as to plan for new features.-->
  
すべての種類のフィードバック &mdash; それが真にバグであろうと、機能への要望であろうと &mdash; は同じ方法で報告されます。WordPressにバグや問題点を報告する方法を学ぶには、以下をお読みください。
+
すべての種類のフィードバック &mdash; それが真にバグであろうと、機能への要望であろうと &mdash; は同じ方法で報告されます。WordPressにバグや問題点を報告する方法を学ぶには、以下をお読みください。... you may also want to read [[WordPress への協力|Contributing to WordPress]] to find out how to contribute to the documentation and other areas of the WordPress project.
<!--All types of feedback &mdash; whether they're genuine bugs or feature requests &mdash; are submitted the same way. Read on to learn how to submit bugs and issues for WordPress.-->
+
<!--All types of feedback &mdash; whether they're genuine bugs or feature requests &mdash; are reported the same way in the WordPress project. Read on to learn how to report bugs and issues for WordPress... you may also want to read [[Contributing to WordPress]] to find out how to contribute to the documentation and other areas of the WordPress project.-->
  
 +
<div id="Reporting_security_issues">
 
== Reporting security issues ==
 
== Reporting security issues ==
 +
</div>
  
 
私たちはセキュリティ問題を防止すべくあらかじめ取り組んでいますが、(傲慢にも)それらが絶対に発生しないとは考えていません。もしあなたが、リリース中のWordPressにセキュリティ上の問題を発見した場合、<code>secrity</code> at the <code>WordPress.org</code> ドメインにメールを送ってください(訳注:メールアドレスに読み替える)。そうすれば、私たちは可能な限り早急に対処できるよう最善を尽くします。
 
私たちはセキュリティ問題を防止すべくあらかじめ取り組んでいますが、(傲慢にも)それらが絶対に発生しないとは考えていません。もしあなたが、リリース中のWordPressにセキュリティ上の問題を発見した場合、<code>secrity</code> at the <code>WordPress.org</code> ドメインにメールを送ってください(訳注:メールアドレスに読み替える)。そうすれば、私たちは可能な限り早急に対処できるよう最善を尽くします。
<!--While we try to be proactive in preventing security problems, we do not (arrogantly) assume they'll never come up. If you believe you've found a security problem in a release of WordPress please send mail to <code>security</code> at the <code>WordPress.org</code> domain and we'll do our best to address it as soon as possible.-->
+
<!--While we try to be proactive in preventing security problems, we do not assume they'll never come up. If you believe you've found a security problem in a release of WordPress please send mail to <tt>security</tt> at the <tt>WordPress.org</tt> domain and we'll do our best to address it as soon as possible.-->
  
 
セキュリティ問題を公表する前に、ベンダー(この場合、WordPressの開発者たち)に告知するのは模範的な手続きです。これにより、修正の準備が整い、脆弱性による公の被害を最小限に抑えることができます。
 
セキュリティ問題を公表する前に、ベンダー(この場合、WordPressの開発者たち)に告知するのは模範的な手続きです。これにより、修正の準備が整い、脆弱性による公の被害を最小限に抑えることができます。
<!--It is standard practice to notify the vendor (the WordPress developers, in this case) of a security problem before publicizing so a fix can be prepared and public damage due to the vulnerability is minimized. -->
+
<!--It is standard practice to notify the vendor (the WordPress developers, in this case) of a security problem before publicizing so a fix can be prepared and public damage due to the vulnerability minimized. -->
  
== A note about plugin bugs ==
+
<div id="Reporting_Bugs_in_Plugins_and_Themes">
 +
== Reporting Bugs in Plugins and Themes ==
 +
</div>
  
 +
If you find a bug in a Plugin or Theme you are using with WordPress, do '''NOT''' report it using the procedures in this article!
 
このページにある説明は、WordPress本体のバグにのみ適用されるものであり、プラグインのバグに対しては適用外です。
 
このページにある説明は、WordPress本体のバグにのみ適用されるものであり、プラグインのバグに対しては適用外です。
<!--Instructions on this page apply only to bugs in the WordPress core, and do not apply to bugs in plugins.-->
+
<!--If you find a bug in a Plugin or Theme you are using with WordPress, do '''NOT''' report it using the procedures in this article! Instructions in this article apply only to bugs in the WordPress core, and do not apply to bugs in plugins and themes.-->
  
 
プラグインの公式リポジトリである [http://dev.wp-plugins.org/ WordPress Plugin Repository] にあるプラグインは、WordPress本体とは [http://dev.wp-plugins.org/report 別のバグ追跡システム] を採用しています。このシステムを使用するには [http://dev.wp-plugins.org/wiki/TracTickets Separate instructions] が役立ちます。
 
プラグインの公式リポジトリである [http://dev.wp-plugins.org/ WordPress Plugin Repository] にあるプラグインは、WordPress本体とは [http://dev.wp-plugins.org/report 別のバグ追跡システム] を採用しています。このシステムを使用するには [http://dev.wp-plugins.org/wiki/TracTickets Separate instructions] が役立ちます。
<!--Plugins which reside in the official [http://dev.wp-plugins.org/ WordPress Plugin Repository] have a [http://dev.wp-plugins.org/report separate bug tracking system] from the WordPress core. [http://dev.wp-plugins.org/wiki/TracTickets Separate instructions] are available for using that system.-->
+
<!--Plugins which reside in the [http://dev.wp-plugins.org/ WordPress Plugin Repository] have a [http://dev.wp-plugins.org/report separate bug tracking system] from the WordPress core. [http://dev.wp-plugins.org/wiki/TracTickets Separate instructions] are available for using that system.-->
  
 
公式リポジトリに属さないプラグインについては、プラグインに同梱されていたドキュメントを読んで、バグの報告先を調べてください。もし、バグ報告に関する情報が記載されていなかった場合、そのプラグインの開発者に直接連絡を取る必要があります。
 
公式リポジトリに属さないプラグインについては、プラグインに同梱されていたドキュメントを読んで、バグの報告先を調べてください。もし、バグ報告に関する情報が記載されていなかった場合、そのプラグインの開発者に直接連絡を取る必要があります。
<!--For plugins which do not reside in the official repository, check the documentation that came with the plugin for instructions on where to submit bugs. If no bug submitting information came with your plugin, you'll need to contact the plugin author directly.-->
+
<!--For plugins which do not reside in the official repository, and for themes, check the documentation that came with the plugin or theme for instructions on where to report bugs. If no bug reporting information came with your plugin or theme, you'll need to contact the author directly.-->
  
== Before you submit ==
+
==Overview of Bug Reporting and Resolution==
 +
 
 +
There are several steps in the process of reporting and resolving a WordPress bug. Here is an overview; more details are in sections below.
 +
 
 +
# A user finds a bug that appears to be in the core of WordPress (not in a Theme or Plugin).
 +
# The user tries to make sure it is actually a bug.  See [[#Before You Report a Bug|Before You Report a Bug (below)]].
 +
# If it is determined to be a bug, the user submits the bug report, called a ''ticket'', to [http://trac.wordpress.org/ Trac], the WordPress bug tracking system.  See  [[#Reporting a Bug|Reporting a Bug (below)]].
 +
# A WordPress developer (who could be a volunteer like you) confirms that the bug does actually exist, and that it should be fixed, and marks it as such in the ticket. See [[#Trac Keywords|Trac Keywords list (below)]] and [[#Bug Resolutions|Bug Resolutions (below)]].
 +
# A WordPress developer (which could be you) decides to fix the bug. The developer may choose to take responsibility for the bug by clicking on the ''Accept ticket'' option near the bottom of the ticket, though this is not required. Then the developer figures out how to fix the bug, creates one or more patch files, and uploads them to Trac. See [[#Patching Bugs|Patching Bugs (below)]]. Also, if you want to help with fixing bugs, but don't know what bugs to fix, see [[#Finding Bugs to Fix|Finding Bugs to Fix (below)]].
 +
# Members of the WordPress development group (including volunteers) test the patch, to see if it fixes the bug and doesn't break anything else. They add comments and keywords to the ticket to indicate their results. See [[#Trac Keywords|Trac Keywords list (below)]].
 +
# One of the WordPress developers with authority to modify the official WordPress source code (Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) ''commits'' the patch to the core code in the SVN repository. They are more likely to do this if the bug and patch has been verified by someone they trust.
 +
# Finally, the person who commits the patch sets the bug ticket status  to ''closed'' and the resolution to ''fixed''. See [[#Bug Resolutions|Bug Resolutions (below)]].
 +
 
 +
<div id="Details_of_Bug_Reporting_and_Resolution">
 +
==Details of Bug Reporting and Resolution==
 +
</div>
 +
 
 +
The sections below add details to some of the steps outlined above.
 +
 
 +
<div id="Before_You_Report_a_Bug">
 +
=== Before You Report a Bug ===
 +
</div>
  
 
WordPressのような大きなプロジェクトでは、多くのユーザがバグを送信するため、あなたのバグは既に送信されている可能性があります。このため、バグを送信する前に、それが未知の問題であることを確認することは非常に重要です。
 
WordPressのような大きなプロジェクトでは、多くのユーザがバグを送信するため、あなたのバグは既に送信されている可能性があります。このため、バグを送信する前に、それが未知の問題であることを確認することは非常に重要です。
<!--With large projects like WordPress, so many users submit bugs that there's a good chance your bug has already been submitted. Because of this, it's very important to check to be sure it's not already in the system before you submit it.-->
+
If you are new to reporting bugs in WordPress, it is also a good idea to discuss the issue with more experienced developers before reporting it. Please follow the steps below.
 +
<!--With large projects like WordPress, so many users report bugs that there's a good chance your bug has already been reported. Because of this, it's very important to check to be sure it's not already in the system before you submit it. If you are new to reporting bugs in WordPress, it is also a good idea to discuss the issue with more experienced developers before reporting it. Please follow the steps below.-->
  
 
#あなたの発見したバグや要望を [http://trac.wordpress.org/report/1 公開または解決されたバグのリスト]から探す。
 
#あなたの発見したバグや要望を [http://trac.wordpress.org/report/1 公開または解決されたバグのリスト]から探す。
 
#*あなたが発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、あなたが更なる情報を寄与できる場合は、既存のバグノートに追加してください。
 
#*あなたが発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、あなたが更なる情報を寄与できる場合は、既存のバグノートに追加してください。
 
#*あなたが発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
 
#*あなたが発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
#次のガイドライン [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html 効果的なバグ報告の方法] を読んでください。これは非常に情報に富んだ記事で、ここに挙げられている手続きはバグ報告システムをより効果的にするのに大いに役立つでしょう。
+
#* If your issue was recently reported and then closed, and you do not agree with the resolution, you can also reopen the ticket and add a comment as to your reasoning.
<!--# Search for your bug or feature request in the [http://mosquito.wordpress.org/view_all_bug_page.php list of open and resolved bugs].
+
# To discuss a bug before reporting it in Trac (e.g. to figure out if it is really a bug in the core of WordPress and not in a plugin or theme), you can post a question on the [http://wordpress.org/support/ WordPress Support Forum], discuss your issue on the [[WordPress IRC Live Help|#wordpress IRC channel]]/[[:en:WordPress IRC Live Help|en]], or have an email discussion on the [[Mailing Lists#Testers|Testers]]/[[:en:Mailing Lists#Testers|en]] or [[Mailing Lists#hackers|Hackers]]/[[:en:Mailing Lists#hackers|en]] mailing list.
#* If your issue has already been addressed there, please do not report a duplicate bug. If you have further information to contribute, add a Bugnote to the bug that already exists.
+
<!--# Search for your bug or feature request in Trac by using [http://trac.wordpress.org/search Search] or a [http://trac.wordpress.org/query Query].
#* If your issue is similar, but not quite the same as another issue, you may decide whether to add a Bugnote to the similar issue, or submit a new report. It can be difficult to decide whether your issue warrants a new submission, but in general if you just have more information to contribute to a current, open issue, simply add a Bugnote to that issue. If you have a different enough issue, or if you are experiencing a recurrence of an issue that was previously resolved, submit a new bug.
+
#* If your issue has already been reported, please do not report a duplicate bug. If you have further information to contribute, log in and add a note to the existing bug.
# Read the following guidelines on [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively]. This is a very informative article, and following the practices outlined there will go a long way toward making the bug reporting system more effective.-->
+
#* If your issue is similar, but not quite the same as another issue, you may decide whether to add a note to the similar issue, or report a new one. It can be difficult to decide whether your issue warrants a new submission, but in general if you just have more information to contribute to a current, open issue, simply add a note to that issue. If you have a different enough issue, or if you are experiencing a recurrence of an issue that was previously resolved, report a new bug.
 +
#* If your issue was recently reported and then closed, and you do not agree with the resolution, you can also reopen the ticket and add a comment as to your reasoning.
 +
# To discuss a bug before reporting it in Trac (e.g. to figure out if it is really a bug in the core of WordPress and not in a plugin or theme), you can post a question on the [http://wordpress.org/support/ WordPress Support Forum], discuss your issue on the [[WordPress IRC Live Help|#wordpress IRC channel]], or have an email discussion on the [[Mailing Lists#Testers|Testers]] or [[Mailing Lists#hackers|Hackers]] mailing list. -->
 +
 
 +
<div id="Reporting_a_Bug">
 +
=== Reporting a Bug ===
 +
</div>
 +
 
 +
[http://trac.wordpress.org/ Trac] is the name of the official WordPress bug tracker. It uses the open source bug tracking software [http://projects.edgewall.com/trac/ Trac] which is a product from [http://www.edgewall.com/ Edgewall Software]. Follow these steps to create a good bug report in Trac:
 +
 
 +
# Read [[#Before You Report a Bug|Before You Report a Bug (above)]], and verify that you have a new bug that is appropriate to report.
 +
# Read this article on [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively], and the [http://trac.wordpress.org/wiki/TracTickets Trac Ticket documentation].
 +
# Log into [http://trac.wordpress.org/ WordPress Trac] using your [http://wordpress.org/support/ support forum] username and password. If you don't have an account at the support forums, [http://wordpress.org/support/register.php register] so that you can login to Trac. This is essential for communication about your bug, since the developers may need more information (and you cannot create a ticket without logging in).
 +
# Click '''[http://trac.wordpress.org/newticket New Ticket]''' in Trac to reach the bug reporting page.
 +
# Fill in the following fields on the new ticket page:
 +
#; Short Summary: Make the summary short but informative and accurate, as this is the ticket title that will be displayed in search results.
 +
#; Full Description: Fill in a full description of your bug or feature request. Include a description of the problem, steps someone else would have to take to reproduce the problem, maybe an example of the bug in action (i.e. a URL), and a description of why it is a problem worthy of being corrected. Also include information about your platform, such as operating system, web server software, PHP version, MySQL version, and WordPress version. The better your description, the better the chances of having the bug resolved promptly.
 +
#; Ticket Properties:
 +
#:; Priority: You will need to decide on a priority for the issue -- this is how urgent the bug is. Unless it is a critical bug, this is best left to the default as developers will usually rank the bug's priority.
 +
#:; Component: Select the component of WordPress where the bug was found
 +
#:; Severity : The ''significance'' of the issue. Select a severity based on how critical you consider the issue to be. If in doubt, leave this option as ''Normal''.
 +
#:; Assign to: If you know of the developer who is responsible for the code that the bug is in, place their Trac username here. You can also take responsibility for the bug yourself, by putting your own Trac user name here. This is optional and could speed up developer attention to the bug.
 +
#:; Milestone: By what version this issue should be resolved, at the latest. Do not change this. This is an option that WordPress developers will set.
 +
#:; Version: The version of WordPress where the bug was found. You can find the version number of WordPress in the footer of the admin panel.
 +
#:; Keywords: Keywords that will make it easier for developers to find the bug, and identify the areas it affects. An example might be 'posting' for a bug involving the posting mechanism in WordPress. Also, there are some standard keywords used to flag your bug's status (see [[#Trac Keywords|Trac Keywords]] below).
 +
#:; CC: Who bug information and updates should be sent to. If you want to be kept informed, enter your own Trac user name here. You will then be notified by email any time a change is made to this report, or a note to the bug 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. '''Note''': you need to go to the Trac ''Settings'' page to set your email address. Putting it into your Support Forum profile will [http://trac.wordpress.org/ticket/8890 not] get it into Trac for purposes of CC messages. Note: If you are the bug's reporter, you will already get messages (if your email is known), so no need for CC.
 +
# Click '''Submit Ticket''' (after previewing it). Then pat yourself on the back.
 +
 
 +
<div id="Finding_Bugs_to_Fix">
 +
=== Finding Bugs to Fix ===
 +
</div>
 +
 
 +
If you want to fix bugs in the core parts of WordPress, but don't know which ones to fix, here are some suggestions on how to find bugs to fix:
 +
* Look through the [http://trac.wordpress.org/report/13 Needs Patch Report on Trac] (which lists bugs that have not been marked with the "has_patch" keyword), the [http://trac.wordpress.org/report/18 Lacks Attachment Report on Trac] (which lists bugs that do not have a patch file attached), or other [http://trac.wordpress.org/report Trac reports] for bugs that look interesting.
 +
* Send an email message to the [[Mailing Lists#Hackers|wp-hackers mailing list]]/[[:en:Mailing Lists#Hackers|en]] and ask how you can help.
 +
* There is also sometimes bug triage on the <tt>#wordpress-dev</tt> [[IRC]]/[[:en:IRC|en]] channel
 +
* Occasionally there are bug days on <tt>#wordpress-bugs</tt>. You can read about what happens in a bug day in [[WordPress Bug Hunts]]/[[:en:WordPress Bug Hunts|en]], and subscribe to either the [[Mailing Lists#Hackers|wp-hackers]]/[[:en:Mailing Lists#Hackers|en]] or [[Mailing Lists#Testers|wp-testers]]/[[:en:Mailing Lists#Testers|en]] mailing list to find out when they happen.
 +
* Consider joining the [http://lists.automattic.com/mailman/listinfo/wp-trac wp-trac email list] to follow the discussions about each [http://trac.wordpress.org/report Trac Ticket].
 +
 
 +
<div id="Patching_Bugs">
 +
=== Patching Bugs ===
 +
</div>
 +
 
 +
If you are familiar with [[用語集#PHP|PHP]] and [[用語集#MySQL|MySQL]], and would like to help in the development of WordPress, then you are encouraged to patch WordPress bugs. Here are the steps to follow:
 +
 
 +
#Read [[#Finding Bugs to Fix|Finding Bugs to Fix (above)]], and find a bug to fix in [http://trac.wordpress.org Trac].
 +
#Connect to the [http://wordpress.org/download/svn/ WordPress Subversion (SVN) Repository] using the username and password you acquired when [http://wordpress.org/support/register.php registering]. Read [[Using Subversion]]/[[:en:Using Subversion|en]] if you are unfamiliar with SVN.  All patches should be submitted against the latest code in the SVN repository.
 +
# Figure out how to fix the bug, by modifying WordPress core files. You may want to discuss your proposed solution on the [[Mailing Lists#Hackers|wp-hackers mailing list]]/[[:en:Mailing_Lists#Hackers|en]] before finalizing it.
 +
# Test your fix, verifying that the bug has been fixed, and that nothing else in WordPress is broken in the process.
 +
# Create a ''patch file'' (or files) containing your fix. This is basically a ''diff'' of the fixed file(s) and the originals from SVN. See [http://asymptomatic.net/2005/12/03/586/how-to-patch-wordpress How to Patch WordPress by Owen Winkler] for detailed instructions. There are also instructions for Linux/Mac command-line users in [http://markjaquith.wordpress.com/2005/11/02/my-wordpress-toolbox/ Mark Jaquith's Toolbox] and Windows Tortoise SVN users in [http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/ Westi's Blog].
 +
# Upload it to the ticket using the [http://trac.wordpress.org/ Trac] ''Attach file'' button, and add ''has-patch'' to the keywords. If the patch needs testing, you might also put ''needs-testing'', or one of the other Trac keywords; see [[#Trac Keywords|Trac Keywords (below)]] for more information.
 +
 
 +
<div id="Trac_Keywords">
 +
=== Trac Keywords ===
 +
</div>
 +
 
 +
There are a number of keywords with defined meaning used in [http://trac.wordpress.org Trac] that are commonly used; some are also searched for by [http://trac.wordpress.org/report Trac Reports].
 +
 
 +
;reporter-feedback
 +
: A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.
 +
;has-patch
 +
: A solution to the ticket has been attached, and it is ready for review and/or committing.
 +
;needs-testing
 +
: Someone needs to test the solution.
 +
;2nd-opinion
 +
: Another person is needed to express an opinion about the problem or the solution.
 +
;dev-feedback
 +
: A response is wanted from a developer (not commonly used)
 +
;tested
 +
: The patch has been tested. When adding this tag please comment with the patch filename that was tested, how the patch was tested, and which version of WordPress was used (including the SVN revision number, if it is not an officially released version).
 +
;commit
 +
: The patch has been reviewed and tested by a trusted member of the development community; therefore the patch is ready to be added to the WordPress core files.
 +
;needs-patch
 +
: The ticket has been reviewed, found to be desirable to solve, and marked as especially needing a patch, or the submitted patch doesn't work and needs to be redone.
 +
;needs-unit-tests
 +
: The ticket has been reviewed, found to be desirable to solve and we would like some unit tests written to test the functionality and any patch that may exist before committing a change as the risk of causing other issues is high.
 +
;needs-doc
 +
: Inline documentation for the code is needed.  These are either place holder tickets for individual files or tickets with patches for new functions which need documenting before they are committed.
 +
 
 +
<div id="Bug_Resolutions">
 +
=== Bug Resolutions ===
 +
</div>
  
== Submitting your bug to Mosquito ==
+
A ticket in Trac starts its life in the ''open'' status, and (hopefully) is eventually ''closed''. When a ticket is closed, it is marked with one of the following status designations:
  
[http://mosquito.wordpress.org/ Mosquito] is the name of the official WordPress bug tracker. It uses the open source bug tracking software [http://mantisbt.org/ Mantis]. Follow these steps for creating a good bug report in Mosquito:
+
* If your bug has been reported elsewhere, it will likely be closed with ''duplicate''.  
 +
* If the bug has already been fixed in the latest subversion code (which is probably not what you're running unless you have a local test blog), then it will be closed with ''fixed''.
 +
* If it is decided that your bug isn't in fact a bug, but is the intended behaviour, it will be closed with ''invalid''.
 +
* If no-one else can replicate the symptoms you describe, it will be closed with ''worksforme''.
 +
* If your bug is a feature request that the developers don't want in the core, it will be marked as ''wontfix''.
  
# If you do not already have an account on Mosquito, [http://mosquito.wordpress.org/signup_page.php create one]. This is essential for communication about your bug, since the developers may need more information from you after you submit.
+
Please verify that your bug doesn't fall into one of these categories before submission.
# Once you've logged in, click '''[http://mosquito.wordpress.org/bug_report_advanced_page.php Report Issue]''' to view the bug reporting page. Fill out the following fields:
+
#; Category : General categorization of the bug.
+
#; Reproducibility : How consistently the bug appears. For feature requests, this should be '''N/A'''.
+
#; Severity : The ''significance'' of the issue. Options are:
+
#:; ''Feature'' : A feature request.
+
#:; ''Trivial'' : Very non-critical; not an error ''per se'', just a little better way of doing things.
+
#:; ''Text'' : Anything to do with text changes, spelling or grammar errors.
+
#:; ''Tweak'' : Extremely minor error in functionality, which differs only slightly from the way it should work.
+
#:; ''Minor'' : Minor error in functionality, non-fatal.
+
#:; ''Major'' : Major error in functionality, but still non-fatal.
+
#:; ''Crash'' : A fatal, critical error which prevents WordPress from functioning at all after the issue is encountered.
+
#:; ''Block'' : 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.
+
#; Priority : 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:
+
#:; ''Platform'' : 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.
+
#:; ''OS'' : 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 Account''' &rarr; '''Profiles''' 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.
+
#; Summary : 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.
+
#; Description : 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!)
+
# Click '''Submit Report'''. Then pat yourself on the back. (Even if you've already done so.)
+
# 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.
+
  
 +
<div id="Notes">
 
== Notes ==
 
== Notes ==
 +
</div>
  
 
* The processing of your bug may require your participation. Please be willing and prepared to aid the developers in resolving the issue.
 
* 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."
+
* 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". These resolutions just mean "not going to fix now", maybe in the future it will be a priority to solve.
 
* Thank you for contributing to the development of WordPress!
 
* Thank you for contributing to the development of WordPress!
  
{{原文|Reporting Bugs|13458}}
+
{{原文|Reporting Bugs|73284}}<!-- 11:59, 2 June 2009 Bono 版 -->
  
 
[[Category:WordPress について]]
 
[[Category:WordPress について]]

2009年6月17日 (水) 23:03時点における版

このページ「バグの報告」は未翻訳です。和訳や日本語情報を加筆してくださる協力者を求めています

  • 最新英語版に差し替えました。
  • 翻訳済みだった部分は、コメントアウトされていた英文を最新版に差し替えただけです。履歴の差分表示か英文と見比べて、必要に応じて和訳を更新してください(言い回しの違いは直さなくて構いません)。

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

すべての種類のフィードバック — それが真にバグであろうと、機能への要望であろうと — は同じ方法で報告されます。WordPressにバグや問題点を報告する方法を学ぶには、以下をお読みください。... you may also want to read Contributing to WordPress to find out how to contribute to the documentation and other areas of the WordPress project.

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

セキュリティ問題を公表する前に、ベンダー(この場合、WordPressの開発者たち)に告知するのは模範的な手続きです。これにより、修正の準備が整い、脆弱性による公の被害を最小限に抑えることができます。

Reporting Bugs in Plugins and Themes

If you find a bug in a Plugin or Theme you are using with WordPress, do NOT report it using the procedures in this article! このページにある説明は、WordPress本体のバグにのみ適用されるものであり、プラグインのバグに対しては適用外です。

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

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

Overview of Bug Reporting and Resolution

There are several steps in the process of reporting and resolving a WordPress bug. Here is an overview; more details are in sections below.

  1. A user finds a bug that appears to be in the core of WordPress (not in a Theme or Plugin).
  2. The user tries to make sure it is actually a bug. See Before You Report a Bug (below).
  3. If it is determined to be a bug, the user submits the bug report, called a ticket, to Trac, the WordPress bug tracking system. See Reporting a Bug (below).
  4. A WordPress developer (who could be a volunteer like you) confirms that the bug does actually exist, and that it should be fixed, and marks it as such in the ticket. See Trac Keywords list (below) and Bug Resolutions (below).
  5. A WordPress developer (which could be you) decides to fix the bug. The developer may choose to take responsibility for the bug by clicking on the Accept ticket option near the bottom of the ticket, though this is not required. Then the developer figures out how to fix the bug, creates one or more patch files, and uploads them to Trac. See Patching Bugs (below). Also, if you want to help with fixing bugs, but don't know what bugs to fix, see Finding Bugs to Fix (below).
  6. Members of the WordPress development group (including volunteers) test the patch, to see if it fixes the bug and doesn't break anything else. They add comments and keywords to the ticket to indicate their results. See Trac Keywords list (below).
  7. One of the WordPress developers with authority to modify the official WordPress source code (Matt Mullenweg, Ryan Boren, Mark Jaquith or Peter Westwood) commits the patch to the core code in the SVN repository. They are more likely to do this if the bug and patch has been verified by someone they trust.
  8. Finally, the person who commits the patch sets the bug ticket status to closed and the resolution to fixed. See Bug Resolutions (below).

Details of Bug Reporting and Resolution

The sections below add details to some of the steps outlined above.

Before You Report a Bug

WordPressのような大きなプロジェクトでは、多くのユーザがバグを送信するため、あなたのバグは既に送信されている可能性があります。このため、バグを送信する前に、それが未知の問題であることを確認することは非常に重要です。 If you are new to reporting bugs in WordPress, it is also a good idea to discuss the issue with more experienced developers before reporting it. Please follow the steps below.

  1. あなたの発見したバグや要望を 公開または解決されたバグのリストから探す。
    • あなたが発見した問題が既に扱われていたら、重複してバグを報告しないでください。もし、あなたが更なる情報を寄与できる場合は、既存のバグノートに追加してください。
    • あなたが発見した問題と既に報告されている問題が、似てはいるがまったく同じではない場合、類似の問題のバグノートに追加するか、あるいは新規に提出するかは、あなたが判断して構いません。あなたの問題が新たに提出されるべきものかを判断するのは難しいかもしれませんが、既存の問題に対して、あなたが更なる情報を寄与するだけの場合、単純にその問題のバグノートに追加するのが普通です。もし、あなたの問題が十分に異なるものであったり、既に解決されたはずの問題が再発したりした場合は、新しいバグとして報告してください。
    • If your issue was recently reported and then closed, and you do not agree with the resolution, you can also reopen the ticket and add a comment as to your reasoning.
  2. To discuss a bug before reporting it in Trac (e.g. to figure out if it is really a bug in the core of WordPress and not in a plugin or theme), you can post a question on the WordPress Support Forum, discuss your issue on the #wordpress IRC channel/en, or have an email discussion on the Testers/en or Hackers/en mailing list.

Reporting a Bug

Trac is the name of the official WordPress bug tracker. It uses the open source bug tracking software Trac which is a product from Edgewall Software. Follow these steps to create a good bug report in Trac:

  1. Read Before You Report a Bug (above), and verify that you have a new bug that is appropriate to report.
  2. Read this article on How to Report Bugs Effectively, and the Trac Ticket documentation.
  3. Log into WordPress Trac using your support forum username and password. If you don't have an account at the support forums, register so that you can login to Trac. This is essential for communication about your bug, since the developers may need more information (and you cannot create a ticket without logging in).
  4. Click New Ticket in Trac to reach the bug reporting page.
  5. Fill in the following fields on the new ticket page:
    Short Summary
    Make the summary short but informative and accurate, as this is the ticket title that will be displayed in search results.
    Full Description
    Fill in a full description of your bug or feature request. Include a description of the problem, steps someone else would have to take to reproduce the problem, maybe an example of the bug in action (i.e. a URL), and a description of why it is a problem worthy of being corrected. Also include information about your platform, such as operating system, web server software, PHP version, MySQL version, and WordPress version. The better your description, the better the chances of having the bug resolved promptly.
    Ticket Properties
    Priority
    You will need to decide on a priority for the issue -- this is how urgent the bug is. Unless it is a critical bug, this is best left to the default as developers will usually rank the bug's priority.
    Component
    Select the component of WordPress where the bug was found
    Severity 
    The significance of the issue. Select a severity based on how critical you consider the issue to be. If in doubt, leave this option as Normal.
    Assign to
    If you know of the developer who is responsible for the code that the bug is in, place their Trac username here. You can also take responsibility for the bug yourself, by putting your own Trac user name here. This is optional and could speed up developer attention to the bug.
    Milestone
    By what version this issue should be resolved, at the latest. Do not change this. This is an option that WordPress developers will set.
    Version
    The version of WordPress where the bug was found. You can find the version number of WordPress in the footer of the admin panel.
    Keywords
    Keywords that will make it easier for developers to find the bug, and identify the areas it affects. An example might be 'posting' for a bug involving the posting mechanism in WordPress. Also, there are some standard keywords used to flag your bug's status (see Trac Keywords below).
    CC
    Who bug information and updates should be sent to. If you want to be kept informed, enter your own Trac user name here. You will then be notified by email any time a change is made to this report, or a note to the bug 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. Note: you need to go to the Trac Settings page to set your email address. Putting it into your Support Forum profile will not get it into Trac for purposes of CC messages. Note: If you are the bug's reporter, you will already get messages (if your email is known), so no need for CC.
  6. Click Submit Ticket (after previewing it). Then pat yourself on the back.

Finding Bugs to Fix

If you want to fix bugs in the core parts of WordPress, but don't know which ones to fix, here are some suggestions on how to find bugs to fix:

Patching Bugs

If you are familiar with PHP and MySQL, and would like to help in the development of WordPress, then you are encouraged to patch WordPress bugs. Here are the steps to follow:

  1. Read Finding Bugs to Fix (above), and find a bug to fix in Trac.
  2. Connect to the WordPress Subversion (SVN) Repository using the username and password you acquired when registering. Read Using Subversion/en if you are unfamiliar with SVN. All patches should be submitted against the latest code in the SVN repository.
  3. Figure out how to fix the bug, by modifying WordPress core files. You may want to discuss your proposed solution on the wp-hackers mailing list/en before finalizing it.
  4. Test your fix, verifying that the bug has been fixed, and that nothing else in WordPress is broken in the process.
  5. Create a patch file (or files) containing your fix. This is basically a diff of the fixed file(s) and the originals from SVN. See How to Patch WordPress by Owen Winkler for detailed instructions. There are also instructions for Linux/Mac command-line users in Mark Jaquith's Toolbox and Windows Tortoise SVN users in Westi's Blog.
  6. Upload it to the ticket using the Trac Attach file button, and add has-patch to the keywords. If the patch needs testing, you might also put needs-testing, or one of the other Trac keywords; see Trac Keywords (below) for more information.

Trac Keywords

There are a number of keywords with defined meaning used in Trac that are commonly used; some are also searched for by Trac Reports.

reporter-feedback
A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.
has-patch
A solution to the ticket has been attached, and it is ready for review and/or committing.
needs-testing
Someone needs to test the solution.
2nd-opinion
Another person is needed to express an opinion about the problem or the solution.
dev-feedback
A response is wanted from a developer (not commonly used)
tested
The patch has been tested. When adding this tag please comment with the patch filename that was tested, how the patch was tested, and which version of WordPress was used (including the SVN revision number, if it is not an officially released version).
commit
The patch has been reviewed and tested by a trusted member of the development community; therefore the patch is ready to be added to the WordPress core files.
needs-patch
The ticket has been reviewed, found to be desirable to solve, and marked as especially needing a patch, or the submitted patch doesn't work and needs to be redone.
needs-unit-tests
The ticket has been reviewed, found to be desirable to solve and we would like some unit tests written to test the functionality and any patch that may exist before committing a change as the risk of causing other issues is high.
needs-doc
Inline documentation for the code is needed. These are either place holder tickets for individual files or tickets with patches for new functions which need documenting before they are committed.

Bug Resolutions

A ticket in Trac starts its life in the open status, and (hopefully) is eventually closed. When a ticket is closed, it is marked with one of the following status designations:

  • If your bug has been reported elsewhere, it will likely be closed with duplicate.
  • If the bug has already been fixed in the latest subversion code (which is probably not what you're running unless you have a local test blog), then it will be closed with fixed.
  • If it is decided that your bug isn't in fact a bug, but is the intended behaviour, it will be closed with invalid.
  • If no-one else can replicate the symptoms you describe, it will be closed with worksforme.
  • If your bug is a feature request that the developers don't want in the core, it will be marked as wontfix.

Please verify that your bug doesn't fall into one of these categories before submission.

Notes

  • 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". These resolutions just mean "not going to fix now", maybe in the future it will be a priority to solve.
  • Thank you for contributing to the development of WordPress!

最新英語版: WordPress Codex » Reporting Bugs最新版との差分