Ezplatform Richtext Laravel Package

Technical Evaluation

Architecture Fit

• Strengths:

  • Designed for eZ Platform (a Symfony-based CMS), making it a natural fit for headless CMS, content-heavy applications, or Symfony-based projects requiring rich text editing.
  • Leverages Symfony’s form and validation components, ensuring consistency with modern PHP/Symfony ecosystems.
  • Supports WYSIWYG editing (via CKEditor/TinyMCE) while maintaining structured data storage (e.g., HTML with embedded assets).
  • Integrates with eZ Platform’s field type system, enabling seamless content modeling (e.g., custom content types with rich text fields).

• Potential Misalignment:

  • Not a standalone library: Tightly coupled with eZ Platform’s architecture (e.g., dependency on ezsystems/ezplatform-core). Requires eZ Platform or a compatible Symfony-based CMS.
  • Legacy PHP practices: eZ Platform uses older PHP (7.4–8.1) and Symfony (5.x) in some bundles, which may introduce compatibility risks with newer PHP/Symfony versions.
  • Monolithic design: The bundle bundles rich text storage, editing, and rendering logic, which may complicate extraction for non-eZ use cases.

Integration Feasibility

• Symfony Projects:
  • High feasibility if using eZ Platform or Symfony 5/6 with similar field type abstractions.
  • Can be adapted for custom Symfony bundles with effort (e.g., replicating field type logic).
• Non-Symfony Projects:
  • Low feasibility without significant refactoring (e.g., replacing Symfony dependencies with standalone libraries like paragonie/halite for encryption or spatie/laravel-medialibrary for asset handling).
• Laravel-Specific Challenges:
  • Laravel’s ** Eloquent/Query Builder** differs from eZ Platform’s repository pattern, requiring middleware to bridge data access.
  • Service container differences: Laravel’s IoC container is incompatible with Symfony’s DI; manual binding or a bridge (e.g., symfony/dependency-injection) would be needed.
  • Asset/URL generation: eZ Platform uses its own URL routing; Laravel’s asset() helper or spatie/laravel-medialibrary would need adaptation.

Technical Risk

Key Questions for TPM

1. Use Case Clarity:
   • Is this for eZ Platform migration, Symfony integration, or Laravel adaptation? The approach varies drastically.
   • Does the project need full rich text editing (WYSIWYG) or just structured HTML storage (e.g., for APIs)?
2. Dependency Trade-offs:
   • Can the team tolerate Symfony dependencies (e.g., symfony/yaml, ezsystems/ezplatform-repository)?
   • Is there a budget for custom abstraction layers to decouple from eZ Platform?
3. Performance:
   • How will rich text asset embedding (images, links) scale? eZ Platform uses a custom asset system—can Laravel’s storage handle this?
4. Maintenance:
   • Is eZ Platform actively maintained? The bundle’s last release (2024-08-14) suggests stability, but upstream risks exist.
5. Alternatives:
   • Would Laravel-specific packages (e.g., laravel-editor, beyondcode/laravel-ckeditor) suffice, or does this bundle offer unique features (e.g., eZ’s content versioning)?

Integration Approach

Stack Fit

Migration Path

Option 1: eZ Platform → Laravel (High Effort)

1. Extract Core Logic:
   • Isolate the rich text field type from eZ Platform’s monolithic bundle.
   • Replace Symfony-specific services (e.g., ezpublish-api, ezpublish-core) with Laravel equivalents.
2. Database Migration:
   • Map eZ’s ezrichtext table to Laravel’s schema (e.g., rich_text_fields with content, format, version columns).
   • Use Laravel’s migrations or Doctrine Schema for compatibility.
3. Service Abstraction:
   • Create a Laravel service provider to bind eZ’s services (e.g., RichTextFieldType) to Laravel’s container.
   • Example:

     $this->app->bind(
         \EzSystems\RichTextField\API\RichTextService::class,
         \App\Services\LaravelRichTextService::class
     );
     

4. Asset Handling:
   • Replace eZ’s asset service with Laravel’s Storage facade or spatie/laravel-medialibrary.
5. Frontend Integration:
   • Use laravel-mix or vite to bundle CKEditor/TinyMCE.
   • Example:

     // resources/js/ckeditor.js
     ClassicEditor.create(document.querySelector('#rich-text-editor'))
         .then(editor => console.log('Editor ready'))
         .catch(error => console.error(error));
     

Option 2: Symfony → Laravel (Medium Effort)

1. Leverage Symfony Components:
   • Use symfony/dependency-injection to bridge containers.
   • Example:

     $container = new ContainerBuilder();
     $container->register('ez_richtext.service', EzRichTextService::class);
     

2. Shared Logic:
   • Extract rich text validation and storage logic into a composer package reusable in both stacks.
3. Gradual Replacement:
   • Start by using the bundle in a Symfony microservice alongside Laravel, then migrate incrementally.

Option 3: Laravel-Only (Low Effort)

• Replace with Laravel Packages:
  • Use beyondcode/laravel-ckeditor for WYSIWYG.
  • Store HTML in a longtext column with Laravel’s Eloquent.
  • Example model:

    class Post extends Model {
        protected $casts = [
            'content' => 'array', // or store as HTML string
        ];
    }
    

Compatibility

Sequencing

1. Phase 1: Proof of Concept (2–4 weeks)
   • Set up a Laravel project with the bundle via Symfony’s DI container.