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.
Before you submit
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.
Submitting your bug to Mosquito
- 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.
- 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 Account → 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.
- 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!)
- 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.
- 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!