すべてのアプリケーションにはバグがあります。あなたが気づこうが気づくまいが、それらは存在します。そして、人間がコードを書く限り、ソフトウェアの中にエラーは存在し続けるでしょう。しかし、些細なものであれ重大なものであれ、バグはアプリケーション開発の終わりを告げるものではありません。 — 実際はその正反対です。特に、オープンソース・プロジェクトにおいては、コミュニティの参加が開発の継続に不可欠です。フィードバックを与えてくれるユーザがいなければ、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.
Reporting security issues
secrity at the
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本体のバグにのみ適用されるものであり、プラグインのバグに対しては適用外です。
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 (below).
- 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).
- 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).
- 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).
- 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).
- 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 (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.
- あなたの発見したバグや要望を 公開または解決されたバグのリストから探す。
- 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 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:
- Read Before You Report a Bug (above), and verify that you have a new bug that is appropriate to report.
- Read this article on How to Report Bugs Effectively, and the Trac Ticket documentation.
- 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).
- Click 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
- 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.
- Select the component of WordPress where the bug was found
- 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.
- By what version this issue should be resolved, at the latest. Do not change this. This is an option that WordPress developers will set.
- 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 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).
- 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.
- 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:
- Look through the Needs Patch Report on Trac (which lists bugs that have not been marked with the "has_patch" keyword), the Lacks Attachment Report on Trac (which lists bugs that do not have a patch file attached), or other Trac reports for bugs that look interesting.
- Send an email message to the wp-hackers mailing list/en and ask how you can help.
- There is also sometimes bug triage on the #wordpress-dev IRC/en channel
- Occasionally there are bug days on #wordpress-bugs. You can read about what happens in a bug day in WordPress Bug Hunts/en, and subscribe to either the wp-hackers/en or wp-testers/en mailing list to find out when they happen.
- Consider joining the wp-trac email list to follow the discussions about each Trac Ticket.
- Read Finding Bugs to Fix (above), and find a bug to fix in Trac.
- 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.
- 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.
- 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 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.
- 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.
- A response is needed from the reporter. Further investigation is unlikely without a response to the questions from someone experiencing the problem.
- A solution to the ticket has been attached, and it is ready for review and/or committing.
- Someone needs to test the solution.
- Another person is needed to express an opinion about the problem or the solution.
- A response is wanted from a developer (not commonly used)
- 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).
- 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.
- 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.
- 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.
- 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.
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.
- 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!