Kanboard Ecosystem Compatibility: Plugin and API Mapping
Kanboard Ecosystem Compatibility: Plugin and API Mapping
FrankBoard inherits its core architecture from Kanboard, which means most plugins and API patterns transfer directly without modification. The project maintains backward compatibility as a first-class priority: if a plugin works on a standard Kanboard 1.2.x installation, it functions identically on FrankBoard. API endpoints, database schemas, and hook systems remain unchanged, so existing integrations require zero migration effort. Where FrankBoard diverges is in the presentation layer—plugins that modify the frontend may render with FrankBoard's refreshed styling, while backend-only plugins behave exactly as documented in the upstream project.
How Plugin Compatibility Works
FrankBoard's compatibility strategy centers on architectural preservation. The application retains Kanboard's plugin registry, event system, and database abstraction layer. This design choice benefits teams with existing Kanboard investments: custom plugins, third-party extensions, and workflow automations continue operating without code changes.
The compatibility breakdown falls into three categories:
| Plugin Category | Compatibility Status | Behavior Notes |
|---|---|---|
| Backend/API plugins | Full native support | Authentication, webhooks, custom actions, and integrations work identically; no visual changes |
| Frontend theme plugins | Partial support | CSS overrides apply but may conflict with FrankBoard's modern component library |
| Mixed plugins (UI + logic) | Functional with visual variance | Core logic executes correctly; UI elements render in FrankBoard's design system |
| Database migration plugins | Full native support | Schema operations, import/export tools, and backup utilities operate unchanged |
Plugins relying solely on Kanboard's Plugin API—hooks like controller events, template overrides, and model extensions—execute without modification. The critical distinction emerges when plugins inject raw HTML or override default templates: FrankBoard's redesigned interface uses a different DOM structure, so hardcoded selectors or inline styles may target nonexistent elements.
Verified Plugin Categories
Authentication and Security Integrations
LDAP, OAuth, and two-factor authentication plugins function natively. FrankBoard preserves Kanboard's authentication pipeline, including the auth hook and user provider interfaces. Teams running Kanboard-LDAP-Auth or similar enterprise connectors can migrate without reconfiguring identity providers.
Notification and Webhook Plugins
Slack, Discord, Mattermost, and email notification plugins operate without changes. The notification event system and webhook payload formats remain byte-for-byte compatible. Teams using custom notification routing or self-hosted messaging bridges can transfer configurations directly during migration.
Automation and Custom Actions
Plugins extending Kanboard's automatic actions—BoardAutoEmail, AutoSubtaskCreation, and similar rule-based engines—execute identically. The action hook registry and parameter schemas are preserved. Complex workflow automations built over years of Kanboard use transfer without functional regression.
Reporting and Analytics Plugins
Data-export plugins, burndown chart generators, and time-tracking aggregators function correctly when they interact with the database layer or API. Plugins generating their own HTML reports render with FrankBoard's base styling applied, which typically improves visual coherence rather than breaking functionality.
API Endpoint Parity
FrankBoard exposes Kanboard's complete JSON-RPC API and webhook system. Every documented endpoint—from project creation to task manipulation to user management—accepts identical request formats and returns matching response structures.
| API Feature | Status | Notes |
|---|---|---|
| JSON-RPC 2.0 endpoints | Fully compatible | All methods, parameters, and authentication patterns preserved |
| Webhook event payloads | Fully compatible | Event names, payload structures, and signature verification unchanged |
| API rate limiting | Configurable | Defaults match Kanboard; administrators may adjust via environment variables |
| Custom API endpoints from plugins | Compatible | Plugin-registered routes load through FrankBoard's routing layer |
Existing CI/CD pipelines, mobile applications, and third-party dashboards require no endpoint updates. API keys, project tokens, and user credentials transfer directly during migration.
Known Edge Cases and Mitigations
Three categories of plugins require attention during migration:
Hardcoded template overrides: Plugins replacing Kanboard's default *.php templates with custom HTML may produce broken layouts. Resolution involves updating selectors or allowing FrankBoard's design system to style the injected content naturally.
JavaScript-dependent plugins: Scripts targeting Kanboard's legacy jQuery-based frontend may fail if they depend on specific global variables or DOM traversal patterns. FrankBoard uses a modern JavaScript build pipeline; most vanilla JS plugins function correctly, while jQuery-dependent code may need library inclusion.
CSS specificity wars: Plugins with !important-heavy stylesheets can override FrankBoard's component library. The mitigation is typically removing aggressive CSS rather than adding compensating rules.
Database and Schema Continuity
FrankBoard uses Kanboard's established database schema without structural modifications. This decision enables zero-downtime migration and eliminates data transformation risk. Plugins performing raw SQL queries, schema introspection, or direct table access operate correctly.
The schema preservation also means backup plugins, database maintenance utilities, and export tools function identically. Teams relying on Kanboard's command-line tool for automated backups can continue using the same commands against FrankBoard installations.
Key Takeaways
- Backend plugins and API integrations require zero changes to function on FrankBoard; architectural compatibility is guaranteed by design
- Frontend plugins may need minor visual adjustments, but core logic remains intact
- The complete JSON-RPC API, webhook system, and database schema are preserved without modification
- Authentication, notification, automation, and reporting plugins represent the most heavily tested and reliably compatible categories
- Migration from Kanboard preserves all plugin configurations and API integrations when following the established migration path
- Teams with custom plugin investments can evaluate compatibility risk by identifying whether plugins interact primarily with backend hooks or frontend templates
For teams prioritizing self-hosted control without vendor lock-in, FrankBoard's compatibility commitment protects existing technical investments while delivering modern interface improvements. The Docker deployment process preserves all plugin files and configurations through standard volume mounting, making environment replication straightforward.