Ezplatform Kernel Laravel Package

Technical Evaluation

Architecture Fit

• Monolithic vs. Modular: The ezsystems/ezplatform-kernel package is the core MVC and Symfony integration layer for Ibexa DXP (Digital Experience Platform), a legacy enterprise CMS. It tightly couples repository, MVC, and Symfony components, making it a monolithic kernel rather than a modular microservice.
  • Fit for: Legacy Ibexa DXP applications, Symfony-based CMS/portal systems requiring Ibexa’s content repository.
  • Misalignment: Poor fit for modern decoupled architectures (e.g., headless APIs, JAMstack, or microservices) due to deep Symfony/DI coupling.
• Symfony Dependency: Acts as a Symfony bundle (v3–v5), requiring alignment with Symfony’s ecosystem (e.g., dependency injection, routing, event system).
• Repository Abstraction: Provides Ibexa’s Content Repository API (legacy eZ Publish 5/6), which may conflict with modern Doctrine/Elasticsearch-based solutions.

Integration Feasibility

• Symfony Compatibility:
  • Supports Symfony 3.x–5.x (last release 2024-08-14 suggests limited 6.x+ testing).
  • Risk: Potential breaking changes if integrating with Symfony 6/7 (e.g., PHP 8.1+ features, new DI compiler).
• PHP Version:
  • Likely targets PHP 7.4–8.1 (based on Ibexa DXP’s historical support).
  • Risk: PHP 8.2+ features (e.g., enums, readonly properties) may require backports.
• Database/ORM:
  • Relies on Ibexa’s custom repository layer (not Doctrine by default).
  • Challenge: Migrating existing Doctrine-based apps to Ibexa’s schema or vice versa.
• API/Headless:
  • No native REST/GraphQL layer; requires custom API integration (e.g., via Symfony’s serializers or Ibexa’s legacy API bundles).
  • Workaround: Pair with ezsystems/ezplatform-rest or build a separate API layer.

Technical Risk

Key Questions

1. Why Ibexa?
   • Is this for migrating from eZ Publish 4/5 or extending an existing Ibexa DXP app?
   • Are there alternatives (e.g., Symfony + Doctrine, Spatie Laravel Media Library)?
2. Symfony Version Strategy
   • What’s the target Symfony version? Will this require a parallel kernel (e.g., Symfony Flex + Ibexa bundle)?
3. Repository Strategy
   • Will Ibexa’s repository replace Doctrine, or run in parallel? How will data sync?
4. Performance/Scaling
   • Ibexa DXP is known for high memory usage—how will this impact hosting (e.g., shared vs. dedicated)?
5. Team Expertise
   • Does the team have Ibexa/Symfony bundle experience? If not, budget for ramp-up.
6. Future-Proofing
   • Ibexa DXP is end-of-life (replaced by Ibexa Cloud). Is this a temporary stopgap or long-term bet?

Integration Approach

Stack Fit

• Primary Fit:
  • Symfony 3.x–5.x applications needing Ibexa’s content repository (e.g., legacy CMS migrations).
  • Ibexa DXP extensions (e.g., custom content types, workflows).
• Secondary Fit:
  • Hybrid Symfony/Laravel projects (via Symfony’s bridge bundles, but complex).
  • PHP 7.4–8.1 monoliths with heavy Symfony dependencies.
• Non-Fit:
  • Laravel-native projects (no Symfony compatibility).
  • Microservices (kernel’s monolithic nature conflicts with decoupling).
  • PHP 8.2+ projects (unless backported).

Migration Path

Compatibility

• Symfony Bundles:
  • Conflicts likely with DoctrineBundle, ApiPlatform, or MercureBundle (Ibexa manages its own routing/events).
  • Solution: Use config/bundles.php to prioritize Ibexa bundles or create a custom bundle loader.
• PHP Extensions:
  • Requires pdo_pgsql (Ibexa’s default DB) or pdo_mysql; test with target DB.
• Composer Dependencies:
  • May pull in old Symfony components (e.g., symfony/routing:v3). Use composer why-not to audit.
• Ibexa-Specific:
  • Assumes Ibexa’s Content, Location, and User models—customize or extend via Ibexa’s event system.

Sequencing

1. Assessment Phase:
   • Audit existing Symfony/Laravel stack for conflicts (e.g., Doctrine, routing).
   • Define minimal viable integration (e.g., start with repository-only).
2. Proof of Concept:
   • Spin up a Symfony 5.4 project with ezplatform-kernel.
   • Test Ibexa’s Content API and routing.
3. Incremental Rollout:
   • Phase 1: Replace legacy content management with Ibexa’s repository.
   • Phase 2: Migrate views/templates to Ibexa’s MVC (Twig-based).
   • Phase 3: Integrate Ibexa’s workflows/permissions.
4. API Layer (Optional):
   • If headless, build a Symfony API Platform layer on top of Ibexa’s kernel.

Operational Impact

Maintenance

• Vendor Lock-in:
  • Ibexa DXP is end-of-life; future updates require Ibexa’s roadmap (now Ibexa Cloud).
  • Mitigation: Abstract Ibexa-specific logic behind interfaces.
• Dependency Updates:
  • Symfony 5.x support may end soon; plan for forking or migrating to Ibexa Cloud.
• Community Support:
  • Limited open-source community; rely on Ibexa’s paid support or legacy forums.

Support

• Debugging Complexity:
  • Ibexa’s kernel is highly opinionated (e.g., custom DI, event system).
  • Tools: Use ibexa:debug CLI commands; enable dev mode for stack traces.
• Common Issues:
  • Memory leaks (Ibexa’s repository caching).
  • Permission/ACL conflicts (Ibexa’s security model differs from Symfony’s).
• Support Channels:
  • Ibexa’s official docs and Slack community.
  • Stack Overflow (limited activity; tag ezpublish).

Scaling

• Performance Bottlenecks:
  • Ibexa’s repository layer is not optimized for high concurrency.
  • Workarounds:
    • Use read replicas for