Ezpublish Kernel Laravel Package

Technical Evaluation

Architecture Fit

• Monolithic vs. Modular: The ezsystems/ezpublish-kernel is a core component of eZ Platform, a legacy CMS built on Symfony. It provides a repository layer (Doctrine ORM), MVC framework, and REST API, making it a highly integrated, monolithic solution for content management.

  • Fit for Laravel? Poor. Laravel follows a micro-service-friendly, modular architecture (e.g., Eloquent ORM, Lumen for APIs, separate service layers). eZ Publish’s kernel is tightly coupled with Symfony’s dependency injection, event system, and legacy eZ-specific abstractions (e.g., Content, Location).
  • Use Case Alignment:
    • Good for: Legacy eZ Platform migrations, hybrid Symfony/Laravel apps (via Symfony bridge), or projects requiring eZ’s content modeling.
    • Bad for: Greenfield Laravel apps needing decoupled, API-first content management.

• Key Abstractions:

  • Repository Layer: Doctrine-based but eZ-specific (e.g., ContentRepository, SearchService). Laravel’s Eloquent is not interchangeable.
  • MVC: Uses Symfony’s Controller, Templating, and Routing—incompatible with Laravel’s RouteServiceProvider, Blade, or Controller conventions.
  • REST API: Built on Symfony’s FOSRestBundle or ApiPlatform—not natively Laravel-compatible (though could be wrapped in a Laravel API layer).

Integration Feasibility

• Direct Integration: Not recommended. Laravel and eZ Publish kernels operate on fundamentally different philosophies:
  • Laravel’s service container vs. eZ’s Symfony DI + legacy eZ services.
  • Laravel’s Eloquent vs. eZ’s ContentRepository (no direct ORM mapping).
• Workarounds:
  1. Symfony Bridge:
     • Use symfony/bridge to embed Symfony (and eZ kernel) as a Laravel service provider.
     • Pros: Access eZ’s repository/REST layers via Symfony’s kernel.
     • Cons: Heavyweight, bloats Laravel’s dependency graph, maintenance overhead.
  2. API Proxy:
     • Expose eZ’s REST API (if available) and consume it via Laravel’s Http client.
     • Pros: Clean separation, scalable.
     • Cons: Performance latency, no real-time content sync.
  3. Hybrid App:
     • Run eZ Platform and Laravel as separate services, share data via GraphQL (eZ’s API) or database views.
     • Pros: Decoupled, future-proof.
     • Cons: Complex deployment, eventual consistency.

Technical Risk

Key Questions

1. Why Laravel?
   • Is the goal to replace eZ Platform, or extend it with Laravel’s features (e.g., Blade templates, queues)?
   • If replacing, evaluate headless CMS alternatives (e.g., Spatie Laravel Media Library + Strapi/Contentful).
2. Data Model Compatibility
   • Can eZ’s Content/Location model be mapped to Laravel’s Eloquent? (Unlikely without heavy customization.)
   • Is real-time sync needed, or can a cron-based export suffice?
3. Team Expertise
   • Does the team have Symfony/eZ Platform experience? Lack thereof will increase ramp-up time.
4. Long-Term Viability
   • eZ Platform is legacy; is the project locked into eZ’s roadmap (e.g., eZ Platform 8 → 9 migration)?
   • Consider forking or rewriting critical components if Laravel integration is critical.

Integration Approach

Stack Fit

Migration Path

1. Assessment Phase:
   • Audit content model dependencies (e.g., custom eZ field types, workflows).
   • Identify critical eZ features (e.g., versioning, multilingual) and map to Laravel alternatives.
2. Hybrid Integration (Recommended for Legacy Systems):
   • Option A: Symfony Bridge
     • Install ezsystems/ezpublish-kernel in a Laravel service provider.
     • Boot Symfony’s kernel only for eZ-specific routes.
     • Example:

       // app/Providers/EzPublishProvider.php
       use Symfony\Component\HttpKernel\KernelInterface;
       
       class EzPublishProvider extends ServiceProvider {
           public function register() {
               $this->app->singleton(KernelInterface::class, function ($app) {
                   return new EzPublishKernel('prod', false);
               });
           }
       }
       

     • Pros: Single codebase, shared session/auth.
     • Cons: Complex, Symfony’s autowiring may conflict with Laravel’s.
   • Option B: API-First
     • Deploy eZ Platform separately and consume its REST API in Laravel.
     • Use Laravel’s Http client or GraphQL for content queries.
     • Example:

       $content = Http::get('http://ez-platform/api/content/123')->json();
       

     • Pros: Decoupled, scalable.
     • Cons: Latency, eventual consistency.
3. Full Rewrite (Long-Term):
   • Migrate content to Laravel + Spatie Media Library or Strapi.
   • Rebuild eZ-specific logic (e.g., workflows) in Laravel’s policy/observer system.

Compatibility

• PHP Version: eZ Publish kernel supports PHP 8.0+ (check composer.json constraints).
• Symfony Dependencies:
  • Requires Symfony 5.4+ (eZ Platform 8.x).
  • Potential conflicts with Laravel’s Symfony components (e.g., symfony/console, symfony/http-kernel).
• Database:
  • eZ uses Doctrine ORM with a custom schema (e.g., ezcontentobject, ezcontentobject_attribute).
  • Laravel’s Eloquent cannot directly map to eZ’s tables without custom repositories.

Sequencing

1. Phase 1: Proof of Concept (2-4 weeks)
   • Set up Symfony bridge or API proxy.
   • Test CRUD operations for 1-2 content types.
   • Benchmark performance (e.g., page load times).
2. Phase 2: Hybrid Integration (4-8 weeks)
   • Integrate authentication (e.g., Laravel Sanctum + eZ’s security).
   • Build custom middleware to handle eZ-specific logic.
   • Implement caching (e.g., Redis for eZ API responses).
3. Phase 3: Optimization (Ongoing)
   • Replace eZ-specific features with Laravel equivalents (e.g., versioning via laravel-modules/versionable).
   • Monitor dependency bloat (e.g., Symfony’s EventDispatcher conflicts).

Operational Impact

Maintenance

• Dependency Management:
  • **High