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 — 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.
All types of feedback — whether they're genuine bugs or feature requests — are submitted the same way. Read on to learn how to submit bugs and issues for WordPress.
Reporting security issues
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 security at the WordPress.org domain and we'll do our best to address it as soon as possible.
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.
A note about plugin bugs
Instructions on this page apply only to bugs in the WordPress core, and do not apply to bugs in plugins.
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.
The bug reporting and resolution process
- User finds a bug.
- User asks around to make sure it is actually a bug. This might even mean posting to the Testers or Hackers mailing list or checking with the #wordpress IRC channel. Also, read Before you submit a bug for more details.
- User submits the bug, called a ticket, to Trac, the WordPress bug tracking system. Detailed instructions on that process are provided in the Submitting your bug section below.
- Various code monkeys find the ticket and confirm that the bug does actually exist.
- Someone decides to write a fix, called a patch, and may even accept the assignment by clicking on the Accept ticket option near the bottom of the ticket (you have to be logged in to Trac to see this)
- After the patch is developed, the author uploads the patch to the ticket using the Trac 'Attach file' button. This person will typically add bg|has-patch to the keywords. If the patch needs testing, the patch author might also put bg|needs-testing in the keywords (you should always test patches you write but sometimes the patch is with a part of the system you're not so familiar with, so this comes in useful sometimes). Also, they might add the keyword bg|2nd-opinion if they want another volunteer to express a technical opinion about the patch. For those interested in patching WordPress, read How to Patch WordPress by Owen Winkler.
- Someone else, normally a bug gardener, then verifies the patch actually corrects the bug and adds bg|commit to the ticket's keywords.
- A committor, Matt Mullenweg or Ryan Boren, comes along and 'commits' the patch to the core code in the svn repository. They're more likely to do this is the bug and patch has been verified by someone they know has experience with the core, like a bug gardener.
- And finally, the bug ticket status is set to closed and the resolution is set to fixed.
Before you submit a bug
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.
- Search for your bug or feature request in the list of open and resolved bugs.
- 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.
- 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.
- Read the following guidelines on 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 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 check your bug falls into none of these categories before submission.
Submitting your 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 for creating a good bug report in Trac, and also refer to the Trac Ticket documentation :
- Wordpress Trac will authenticate your login using your support forum username and password. If you do not already 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 from you after you submit.
- Once you've logged in to Trac, click New Ticket to view the bug reporting page. Prior to submitting a bug, view the existing tickets to make sure your bug is not already listed.
- To submit a new bug, fill in the following fields on the new ticket page:
- Your email or username
- Since you are logged in, this should already display your support forum username.
- Short Summary
- Make the summary short but informative and accurate, this is the description that will be displayed in search results.
- Fill in a full description of your bug or feature request. The more information here the easier it will be for developers to correct the issue and the less questions there will be back to you requesting further information. Include everything you know about the bug, such as error reports and try to include an example of the bug in action (ie. a URL), and the steps it takes to reproduce it. Also include information about your platform, such as operating system, PHP version, MySQL version etc. The better your description, the better the chances of having the bug resolved in a neat and quick fashion.
- Ticket Properties
- select the relevant component of Wordpress where the bug was found
- The version of Wordpress where the bug was found. You can find the version number of Wordpress in the footer of the admin panel.
- 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.
- 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.
- As with severity, 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 bugs priority.
- By what version this issue should be resolved, at the latest. Again this is usually an option that Wordpress developers will alter and decide on, unless the bug is severe.
- Assign to
- If you know of the developer who is responsible for the code that the bug is in, place their username or email address here. This is optional and could speed up developer attention to the bug.
- Who the bug should be copied to, as with assigning the bug to a developer, if you wish to attach other developers to the bug.
- Click Submit Ticket (after previewing it). 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 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.
- 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!