Bundles Cms Laravel Package

Technical Evaluation

Architecture Fit

• Symfony/Laravel Compatibility: Kunstmaan CMS is built on Symfony, not Laravel. While it leverages PHP and Doctrine, Laravel’s ecosystem (e.g., Eloquent, Blade, Laravel Mix) is fundamentally different. Direct integration with Laravel would require abstraction layers (e.g., Symfony Bridge, custom adapters) or a hybrid architecture (e.g., microservices).
• Modularity: Kunstmaan’s bundle-based architecture (Symfony bundles) is highly modular, but Laravel’s service providers and facades would need translation. Key components (e.g., ACL, workflow, media manager) could be partially adopted via custom wrappers.
• Database Schema: Uses Doctrine ORM, which is compatible with Laravel via doctrine/dbal or laravel-doctrine. However, Kunstmaan’s entity structure (e.g., Node, Media, Page) would require migration or duplication.
• Frontend Backend Split: Kunstmaan’s admin panel is tightly coupled with Symfony’s Twig and KnpMenu. Laravel’s Blade and Inertia.js/Vue/React would need custom middleware or a separate admin UI layer.

Integration Feasibility

• High-Level Integration:
  • Possible: Adopt specific Kunstmaan features (e.g., ACL, media manager, workflow) via custom Laravel packages.
  • Challenging: Full CMS replacement would require rewriting core logic (e.g., page assembly, versioning) in Laravel.
• Key Dependencies:
  • Symfony Components: SecurityBundle, Twig, Doctrine, KnpMenu → Would need polyfills or alternatives (e.g., Laravel’s spatie/laravel-acl for permissions).
  • JavaScript Dependencies: Kunstmaan uses jQuery, Bootstrap, CKEditor → Could be replaced with Laravel’s ecosystem (e.g., Alpine.js, Tailwind, TinyMCE).
• API-First Approach: Best fit for headless CMS use case—expose Kunstmaan as a GraphQL/REST API and consume it in Laravel.

Technical Risk

Key Questions for Stakeholders

1. Is Symfony coexistence acceptable, or must the solution be pure Laravel?
2. What’s the priority: Adopt specific features (e.g., ACL) or full CMS replacement?
3. Will the admin panel be rebuilt, or can Kunstmaan’s UI be embedded (e.g., iframe, subdomain)?
4. What’s the migration timeline? (Big-bang vs. phased adoption.)
5. Are there existing Symfony services that could help with integration?
6. How critical is real-time content updates? (Kunstmaan’s workflow may need Laravel event listeners.)
7. Budget for custom development (e.g., adapters, middleware, UI layers).

Integration Approach

Stack Fit

Migration Path

Phase 1: Feature Adoption (Low Risk)

1. Extract and Wrap Kunstmaan Components:
   • ACL: Use kunstmaan/admin-bundle as a composer dependency + build a Laravel ACL service (e.g., spatie/laravel-acl + custom rules).
   • Media Manager: Expose via Laravel Filesystem or Spatie Media Library.
   • Workflow: Implement Laravel Policies + database state tracking.
2. API Layer:
   • Deploy Kunstmaan as a separate Symfony app with API Platform or custom REST controllers.
   • Consume APIs in Laravel via Guzzle HTTP client.

Phase 2: Hybrid Architecture (Medium Risk)

1. Shared Database:
   • Use Doctrine DBAL in Laravel to read/write Kunstmaan entities.
   • Sync schemas via migrations or entity listeners.
2. Shared Auth:
   • Use Laravel Sanctum for frontend auth + Symfony Security for Kunstmaan admin.
   • Sync users via database events or message queues.
3. Admin Panel:
   • Option A: Embed Kunstmaan admin in an iframe or subdomain (admin.yoursite.com).
   • Option B: Rebuild admin UI in Inertia.js (Vue/React) + consume Kunstmaan APIs.

Phase 3: Full Replacement (High Risk)

1. Rebuild Core Features:
   • Replace Kunstmaan’s page assembly with Laravel service providers + Blade templates.
   • Replace versioning with Laravel soft deletes + database snapshots.
   • Replace workflow with Laravel Policies + state machines (e.g., spatie/laravel-state-machine).
2. Frontend:
   • Migrate Twig templates to Blade/Inertia.js.
   • Replace CKEditor with TinyMCE or Laravel Livewire.

Compatibility

Sequencing

1. Assess Priority Features:
   • Start with non-UI components (e.g., ACL, media, workflow) → easier to wrap.
   • Delay admin UI until core functionality is stable.
2. Database-First Approach:
   • Migrate entities and schema before logic.
3. API-First for Decoupling:
   • Expose Kunstmaan as an API to decouple from Laravel’s frontend.
4. Incremental UI Migration:
   • Replace frontend templates (Twig → Blade) gradually.
   • Rebuild admin panel last (highest effort).

Operational Impact

Maintenance

| Aspect | Impact | Mitigation