Expose Trac data via structured JSON API endpoints

[juanmaguitar]

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 in site-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

• ​Extension repo (proof of concept)
• ​Video demo
• ​Blog post with context

[dd32]

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-notifications api behind the scenes to fetch from Trac.

Having it separate from Trac will allow adding a trac unavailable flag 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?

[obenland]

@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?

[dd32]

Replying to obenland:

@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.

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.