No software is ever truly perfect, and every project comes with challenges. WordPress is no exception—but at Greyd, we see this as an opportunity. An opportunity to refine, optimize, and keep WordPress powerful and reliable for millions of users worldwide.
Here’s the great thing about WordPress: as an open-source project, anyone can contribute to making it better, and that includes you! One of the most valuable contributions you can make is reporting bugs, ensuring that WordPress remains a stable and reliable platform for millions of users worldwide.
But let’s be honest. Reporting a bug isn’t always straightforward. It’s not just about saying, “Hey, something’s broken.” It’s about pinpointing the issue, making sure it’s not caused by a plugin or theme, and then submitting a report that developers can actually use to fix the problem. So, let’s break it down in a way that makes sense for you.wide.
Step 1: Is It Really a WordPress Bug?
Before you report a bug, you need to be sure that WordPress itself is the culprit. Since most WordPress websites rely on plugins and custom themes, the issue might not be with WordPress core at all. Here’s how to check:
The Plugin Test
- Deactivate all plugins on your site
- Is the problem gone? If yes, it’s a plugin issue, and you should reach out to the plugin developer. (Tip: check out Step 3 further down in this article. It’s extremely helpful when you provide information that way.)
- If the problem persists, move on to the next step.
The Theme Test
- Switch to a default WordPress theme, like Twenty Twenty-Four.
- if the issue disappears, your theme is the problem, and the theme developer needs to fix it. (Tip: also for theme tests, check out Step 3 further down in this article. It’s extremely helpful when you provide information that way.)
- If the issue is still there, congratulations! You’ve likely found a genuine WordPress bug!
Step 2: Where Do You Report It?
Now that you’re sure it’s a WordPress bug, the next step is figuring out where to report it. WordPress uses two main platforms for bug tracking: GitHub and Trac.
If the Bug is in the Block or Site Editor (Gutenberg)
This means the issue is related to the new editing experience, and it should go to the Gutenberg GitHub repository:
- Visit GitHub Issues for Gutenberg. If you don’t have an account there yet, creating one is a short and simple process.
- Search to see if someone has already reported it.
- Pay attention to labels like [Block] or [Feature], which categorize issues.
- If the bug isn’t listed, create a new issue by clicking the green “New issue” button and selecting Bug Report.
If the Bug is in WordPress Core (but not the Block Editor)
For issues in other parts of WordPress (admin dashboard, REST API, etc.), head to WordPress Trac:
- Visit WordPress Trac.
- Click on Tickets to see if it’s already reported.
- If not, create a new ticket and provide details.
- Select the right Component to help developers categorize it.
Tips for Searching Exisiting Bug Reports
When looking for existing bug reports, it’s worth trying different ways to describe the issue. Sometimes, we frame a problem based on our own perspective, which might not match how others have reported it. If you don’t find anything relevant, that’s okay—just go ahead and submit your bug report.
If someone later comments that your report is a duplicate or that there’s already a ticket for it, don’t take it as a rejection. It can feel frustrating after putting in the effort, but this is part of the process. Maybe the right search terms weren’t obvious, or the existing ticket wasn’t easy to find. That’s completely normal and happens to everyone. What matters is contributing to the project, and submitting a bug report—even if it turns out to be a duplicate—is still valuable.
Step 3: Writing a Bug Report That Gets Attention
Here’s the secret sauce: if you want a bug fixed, you need to write a report that developers can actually use. Think of it like telling a mechanic what’s wrong with your car. Saying, “It makes a weird noise” isn’t helpful. Instead, you’d describe when the noise happens, how long it lasts, and what seems to trigger it. The same applies to bug reports.
A great bug report should include:
- A clear and descriptive title;
- A step-by-step explanation of how to reproduce the bug;
- What you expected vs. what actually happened;
- Screenshots or videos (if relevant);
- Error messages or logs (if any);
- Your WordPress version, PHP version, and hosting environment.
The better your report, the easier it is for contributors to understand the issue and find the right solution in less time.
Conclusion
Reporting a bug isn’t just a chore; it’s a way to contribute to the WordPress ecosystem and make it better for everyone. By taking the time to diagnose the issue, report it in the right place, and provide useful details, you’re playing an important role in the future of WordPress. And who knows? The next time you encounter an issue, someone else might have already reported it and saved you the trouble!
So, the next time you spot a bug, don’t just sigh and move on. Take a few minutes to report it. You’ll be making WordPress better for everyone, including yourself.
