Media Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony3 Integration: The bundle is explicitly designed for Symfony3 (with a separate branch for Symfony2), making it a direct fit for Symfony-based Laravel-like applications (e.g., Lumen or Symfony-compatible PHP stacks). If leveraging Laravel, compatibility would require Symfony bridge components (e.g., Symfony’s HttpFoundation, Form, or Twig via symfony/bridge).
• Media-Centric Design: Focuses on upload, storage, transformation (crop/resize), and context-based access control, aligning well with Laravel’s file-upload needs (e.g., laravel/framework’s File facade but with advanced features like focus-point cropping).
• Doctrine ORM Dependency: Tightly coupled to Doctrine ORM (v2.5+), which is not native to Laravel. Workarounds:
  • Use Eloquent with custom traits/methods to mimic Doctrine behavior.
  • Abstract storage logic into a repository pattern (e.g., MediaRepository interface).
• Gaufrette for Storage: Supports local/FTPS storage via KnpLabs/Gaufrette (v0.1.9). Laravel alternatives:
  • Local: Illuminate\Support\Facades\Storage.
  • Cloud: AWS S3 (league/flysystem-aws-s3-v3), GCS (league/flysystem-google-cloud-storage).
  • Adapter: Create a Flysystem adapter for Gaufrette to bridge with Laravel’s storage system.

Integration Feasibility

• High for Symfony: Plug-and-play with Symfony’s ecosystem (Forms, Twig, Doctrine).
• Medium for Laravel:
  • Frontend (Twig): Replace Twig with Blade (or use twig/bridge for hybrid apps).
  • Forms: Laravel’s Form components are simpler; may need to wrap Symfony’s FormBuilder or use laravelcollective/html as a proxy.
  • Doctrine: Replace with Eloquent or a Doctrine-to-Eloquent mapper (e.g., doctrine/dbal for raw queries).
• Image Processing: Uses Imagine (v0.5), which has Laravel equivalents:
  • intervention/image (more maintained).
  • spatie/image-optimizer.
  • Migration Path: Replace Imagine calls with Intervention’s API via a service provider.

Technical Risk

Key Questions

1. Symfony vs. Laravel Priority:
   • Is this for a new Symfony3 project or a Laravel migration?
   • If Laravel, what’s the minimum viable scope (e.g., just uploads + storage vs. full feature set)?
2. Storage Backend:
   • Will Gaufrette be used, or should we replace it with Flysystem for Laravel compatibility?
3. ORM Strategy:
   • Can Eloquent replace Doctrine, or is a hybrid approach (e.g., Doctrine for media metadata, Eloquent for user data) needed?
4. Image Processing:
   • Should we drop Imagine in favor of intervention/image for better Laravel support?
5. Frontend Dependencies:
   • How will CKEditor/Twig integrate with Laravel’s Blade/Alpine.js stack?
6. Context Security:
   • How will context-based access control (e.g., user:12) map to Laravel’s auth (e.g., auth()->user())?
7. Performance:
   • What are the expected media volumes? Gaufrette/Flysystem may need caching layers (e.g., Redis for metadata).

Integration Approach

Stack Fit

Migration Path

Option 1: Full Symfony3 Integration (Low Risk)

1. Adopt Symfony3 Stack:
   • Use Symfony Flex, Doctrine, and Twig natively.
   • Bundle integrates out-of-the-box.
2. Leverage Existing Features:
   • Forms, security contexts, and Gaufrette work as-is.
3. Trade-offs:
   • Abandon Laravel’s Eloquent/Blade ecosystem.
   • Higher learning curve for teams unfamiliar with Symfony.

Option 2: Hybrid Laravel Integration (Medium Risk)

1. Isolate Core Logic:
   • Extract media storage/processing into a Laravel service.
   • Use Symfony components as libraries (e.g., symfony/form via Composer).
2. Replace Dependencies:
   • Doctrine → Eloquent: Create a Media model with accessors for contexts.
   • Twig → Blade: Use twig/bridge for templating or rewrite Twig logic in Blade.
   • Gaufrette → Flysystem: Build a MediaStorage facade wrapping Flysystem.
3. Image Processing:
   • Replace Imagine with intervention/image via a service provider.
4. Forms:
   • Use laravelcollective/html for basic forms or build a Symfony Form wrapper.
5. Frontend:
   • Replace CKEditor with summernote or tiptap.
   • Implement focus-point cropping via cropperjs + custom backend logic.

Option 3: Feature-Specific Extraction (Lowest Risk)

1. Cherry-Pick Features:
   • Use only the upload/storage parts of the bundle.
   • Ignore Forms/Twig/CKEditor dependencies.
2. Implementation:
   • Use Laravel’s File facade for uploads.
   • Use Flysystem for storage (local/S3).
   • Use intervention/image for resizing/cropping.
   • Implement context security manually (e.g., middleware + model policies).
3. Trade-offs:
   • Lose focus-point cropping and CKEditor integration.
   • More manual work but fully Laravel-native.

Compatibility

Sequencing

1. Phase 1: Core Storage
   • Implement upload → storage → retrieval using Flysystem.
   • Replace Gaufrette with S3/local adapters.
2. Phase 2: Image Processing
   • Replace Imagine with intervention/image.
   • Add crop/resize endpoints.
3. Phase 3: Context Security
   • Implement model policies or middleware for context-based access.
4. Phase 4: Frontend Integration
   • Add file upload forms (Laravel Collective or custom).