Created
November 17, 2013 19:31
-
-
Save Shelob9/7517200 to your computer and use it in GitHub Desktop.
What makes a good WordPress bug report. From 2013 WordCamp Orlando contributor sessions with Andrew Nacin and Mark Jaquith.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| What makes a good bug report: | |
| * Steps to reproduce, with earliest step Shouldn’t need to know code | |
| * Description of the bug. What you saw vs what you expected. | |
| * Error messages or error codes. | |
| * | |
| * PHP errors- | |
| * | |
| * What warning on page | |
| * What went in log | |
| * Errors could be in javascript/apache/nginx | |
| * Browser- try it in incognito | |
| * Environment | |
| * PHP version, MySQL Apache or nginx version- Norcross system profiler plugin | |
| * Does it happen with no plugins and default theme | |
| * Screenshots for UI issues, before and after for UI patches. | |
| * Possibly screencast | |
| * Clearly and concise. Get to point first, then details. | |
| * Related ticket number | |
| * One bug per ticket | |
| * Permalinks | |
| * Multisite or not? | |
| * WP_DEBUG or equivalent enabled? | |
| * User role logged in as when the issue happened. Or changed roles in database. | |
| Not all of these needed, depends on the situation. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment