![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 4 months ago
Last modified 5 weeks ago
#8202 assigned enhancement
Expose Trac data via structured JSON API endpoints
| Reported by: | juanmaguitar | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Trac | Keywords: | |
| Cc: |
Description
Following Matt's suggestion, this ticket tracks adding structured JSON API endpoints to WordPress Trac to support triage workflows.
A proof-of-concept Chrome extension (WP Trac Triager) already demonstrates triage-assistance features built on top of this data (video demo, blog post).
Phased approach
Phase 1 (this ticket) — Implement JSON API endpoints that expose Trac data in a structured, machine-readable format. This is useful on its own: any tool, browser extension, or AI agent can consume the data directly without parsing Trac HTML.
Phase 2 (separate ticket) — Implement native Trac UI enhancements that consume these endpoints. A separate ticket will allow proper discussion around the UI design and UX.
Architecture
PHP scripts on the Trac server querying the SQLite DB directly via PDO, following the existing trac-notifications pattern (Trac_Notifications_SQLite_Driver). Responses cached via HTTP Cache-Control headers. No Python Trac plugin, no XML-RPC.
Proposed Endpoints
ticket/ (cache: 5 min)
The central endpoint. Single call returns structured JSON with:
- Metadata — id, summary, status, type, reporter, owner, milestone, priority, severity, component, keywords, resolution, opened/modified dates
- Comments (last N) — id, author, date, text
- Changelog (keyword + milestone changes) — field, author, date, old/new values, linked comment ID
- Attachments — filename, author, date, size
?trac=core|meta&ticket=12345
contributors/ (cache: 24h)
Unified contributor map: username → { name, profile_url, role, authority_level }. Merges three currently separate sources:
wpTracContributorLabels(committers, lead devs — currently insite-specific.html)- Component maintainer profiles (100+ profiles from make/core/components)
- Role hierarchy (Project Lead → Lead Developer → Core Committer → Component Maintainer → Individual Contributor)
keywords/ (cache: 24h)
Keyword definitions: keyword → { category, label, description, usage, critical }. Sourced from the Core Handbook. Categories: patch, testing, feedback, design, docs, review, screenshots, status.
components/ (cache: 24h)
Component-to-maintainers mapping: component → [{ username, name, profile_url, role }]. Sourced from make/core/components. Optional filter: ?component=Media.
releases/ (cache: 24h)
Release schedule: version → { milestones: [{ name, date, type }] }. Types: alpha, beta, RC, final.
Phase 2 — UI Enhancements (separate ticket)
Once the API is in place, a follow-up ticket will propose native Trac UI features including: sticky ticket summary, role badges and comment highlighting, keyword change timeline, milestone history with punt detection, component maintainers, release schedule countdown, keyword explanations, and authority legend. See the video demo for a preview of these features.
Resources
Change History (7)
This ticket was mentioned in Slack in #core-test by juanmaguitar. View the logs.
4 months ago
This ticket was mentioned in Slack in #core-test by juanmaguitar. View the logs.
3 months ago
#5
follow-up:
↓ 6
@
8 weeks ago
@dd32 I started looking at this to see if the trac-notification changes could maybe also power new tools in the wporg MCP to interact with Trac. This is a first pass at extending Trac_Notifications_DB to get a single ticket and a basic ticket search with some caching. Could you take a look if that makes sense when you get a chance?
Are there docs on how these changes make it into these Trac instances?
#6
in reply to: ↑ 5
@
8 weeks ago
Replying to obenland:
@dd32 I started looking at this to see if the
trac-notificationchanges could maybe also power new tools in the wporg MCP to interact with Trac.
In all honesty, I'm not a super-fan of using the trac-notifications API for access to the Trac DB. It's a very crude backdoor into the Trac DB to work around the fact that we had to switch from MySQL backed trac to Sqlite.
(edit: I do realise i suggested this above)
The main reason is that the process is trac-notifications plugin -> Trac public Python -> Shell out to PHP-CLI -> Process request -> return JSON to Python -> dump to client.
I'd prefer someone work with Systems to restore Trac access, or @darthhexx's Trac-native-MCP plugin be enabled.
Are there docs on how these changes make it into these Trac instances?
Not really.. but commit to trac-notifications and deploy wporg and it should get there.
For this, we can probably skip adding directly to Trac, and add to api.wordpress.org with a lightweight caching layer in front of Trac, using the
trac-notificationsapi behind the scenes to fetch from Trac.Having it separate from Trac will allow adding a
trac unavailableflag and return instantly / return stale data, will be better than having Trac returning 429's/503's directly increasing load.Separately, @darthhexx Would your Trac MCP plugin assist here at all?