bbGuild sits at the centre of the extension family (bbDKP, bbAccounts, events calendar, Discord, game plugins) and in-game tools, but it has no deliberate, documented way for anything to consume its data. Today integration relies on ad-hoc coupling and a single player_detail_display event. We need a proper API surface. Two complementary facets:
1. phpBB event surface (in-process, for sibling extensions)
A documented set of dispatcher events around the key domain actions and render points — guild/roster/player rendering, character add/edit/claim, sync completed, portal module render, etc. — with stable @event names, @var payloads and @SInCE tags. Lets bbDKP / bbAccounts / Discord / events hook in without touching bbGuild internals. Extends the existing avathar.bbguild.player_detail_display pattern into a real, versioned surface.
2. Exposed read API (out-of-process, for external consumers)
JSON controller routes (under app.php) exposing guild, roster, character, achievement and stats data for external consumers: in-game mods (the planned bbDKP Lua companion — revives the 2012 bbDKP API idea), the Discord integration, the events calendar, or other sites.
- Read-only to start; respect u_bbguild permissions / guest visibility.
- Token or key-scoped access for non-public data; rate-limited.
- Stable, versioned response shapes.
Why it matters
This is the decoupling layer for the whole family — a residue that lets the complex ecosystem of sibling extensions and tools evolve independently without breaking bbGuild or each other. Currently underappreciated in the roadmap; it belongs in 2.3.0 (integrations) alongside Discord and Gameworld, which are its first real consumers.
Scope
- Design the event catalogue (names/payloads) + document it.
- Design + implement the read API routes, auth model, and versioning.
- Reference implementation consumer (e.g. the Discord ext or the bbDKP Lua mod).
Component: core. Prior art: the 2012 'bbDKP api' forum proposal. Companion to the Discord + Gameworld integration work in 2.3.0.
bbGuild sits at the centre of the extension family (bbDKP, bbAccounts, events calendar, Discord, game plugins) and in-game tools, but it has no deliberate, documented way for anything to consume its data. Today integration relies on ad-hoc coupling and a single player_detail_display event. We need a proper API surface. Two complementary facets:
1. phpBB event surface (in-process, for sibling extensions)
A documented set of dispatcher events around the key domain actions and render points — guild/roster/player rendering, character add/edit/claim, sync completed, portal module render, etc. — with stable @event names, @var payloads and @SInCE tags. Lets bbDKP / bbAccounts / Discord / events hook in without touching bbGuild internals. Extends the existing avathar.bbguild.player_detail_display pattern into a real, versioned surface.
2. Exposed read API (out-of-process, for external consumers)
JSON controller routes (under app.php) exposing guild, roster, character, achievement and stats data for external consumers: in-game mods (the planned bbDKP Lua companion — revives the 2012 bbDKP API idea), the Discord integration, the events calendar, or other sites.
Why it matters
This is the decoupling layer for the whole family — a residue that lets the complex ecosystem of sibling extensions and tools evolve independently without breaking bbGuild or each other. Currently underappreciated in the roadmap; it belongs in 2.3.0 (integrations) alongside Discord and Gameworld, which are its first real consumers.
Scope
Component: core. Prior art: the 2012 'bbDKP api' forum proposal. Companion to the Discord + Gameworld integration work in 2.3.0.