Your clients report bugs on the WordPress site. Your developers fix them in GitHub. The gap between those two worlds is where bugs get lost, context gets mangled, and time gets wasted.
BugPost Pro bridges that gap. When a bug report is submitted on your site, it automatically creates a GitHub Issue with the full context — page URL, browser details, console errors, screenshot, and the reporter's description. No copy-pasting. No context lost in translation.
Why GitHub for WordPress Bug Tracking
If your team already uses GitHub for code, it makes sense to track bugs there too. Here is why:
- One tool, one workflow. Developers do not need to check a separate dashboard. Bugs live alongside the code they relate to.
- Full context on every issue. Each auto-created issue includes browser info, console errors, page URL, and a screenshot. No more "can you send me more details?" comments.
- Two-way status sync. Close the issue in GitHub and the report updates in WordPress. Resolve it in WordPress and the issue closes in GitHub.
- Label mapping. BugPost categories (Bug, Error, Performance) automatically map to GitHub labels for easy filtering.
What You Need
- A GitHub account (free works)
- A repository for bug issues (can be your code repo or a dedicated one)
- BugPost Pro installed and activated
Step-by-Step Setup
Step 1: Create a Personal Access Token
1. Go to GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens.
2. Click Generate new token.
3. Name it something like "BugPost" and set an expiration (or "No expiration" for convenience).
4. Under Repository access, select the repo you want to use.
5. Under Permissions, grant Issues: Read and write.
6. Click Generate token and copy it immediately (you will not see it again).
Step 2: Connect BugPost to GitHub
1. In WordPress admin, go to BugPost → Settings.
2. Scroll to GitHub Integration.
3. Paste your Personal Access Token.
4. Enter the repository in owner/repo format (e.g., acme/website-bugs).
5. Click Test Connection. You should see a success message with the repo name.
Step 3: Enable Auto-Create
1. Check Automatically create a GitHub issue when a new bug report is submitted.
2. Optionally set up the Label Map — one mapping per line in the format BugPost Category:GitHub Label. For example:
Bug:bugPerformance:performanceFeature Request:enhancement
If no mapping exists, the category name (lowercased) is used as the label automatically.
3. Click Save Settings.
Step 4: Set Up Two-Way Sync (Optional but Recommended)
This step lets status changes in GitHub flow back to WordPress, and vice versa.
1. In your GitHub repo, go to Settings → Webhooks → Add webhook.
2. Set the Payload URL to the webhook URL shown in your BugPost GitHub settings.
3. Set Content type to application/json.
4. Paste the Webhook Secret from your BugPost settings into the Secret field.
5. Under Which events would you like to trigger this webhook?, choose Let me select individual events and check Issues.
6. Click Add webhook.
Important: The webhook secret shown in BugPost is auto-generated and is not the same as your Personal Access Token. Never use your PAT as a webhook secret.
What Happens When a Bug Is Reported
With auto-create enabled, here is the flow:
- A user submits a bug report on your site via the BugPost widget.
- The report is saved to your WordPress database with all captured context.
- BugPost sends a request to the GitHub API to create an issue in your repo.
- The GitHub issue includes the report title, full description, page URL, browser and OS details, console errors, and a link to the screenshot in your WordPress admin.
- The issue is labeled based on the category mapping.
- A link to the GitHub issue appears on the report in your WordPress admin.
Two-Way Sync in Action
With the webhook set up:
- Close the issue in GitHub → the report status in WordPress updates to "Closed."
- Reopen the issue in GitHub → the report status reverts to "In Progress."
- Change the status in WordPress (via Kanban board or edit screen) → the GitHub issue updates accordingly.
Your team works in GitHub. Your clients see status updates. Nobody has to manually sync anything.
Tips
Consider a dedicated bugs repo
If your code repo is private and you want to share issue links with clients, create a separate public or shared repo like yourorg/client-bugs. This keeps client-reported issues separate from your internal development issues.
Use label mapping for triage
Map BugPost priorities to GitHub labels too (e.g., Critical:priority-critical). This lets you use GitHub's label filters to quickly find high-priority client bugs.
You can also create issues manually
If auto-create is off, each report in your WordPress admin has a "Create GitHub Issue" button. Useful if you only want to escalate certain reports to GitHub.
Bridge the Gap Between Clients and Code
BugPost Pro auto-creates GitHub Issues from client bug reports with full context, screenshots, and two-way status sync.
See Pricing