Tinymce Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony2/3/4/5/6 Compatibility: The bundle supports Symfony 2.1–5.0+, with the latest version (3.0) targeting Symfony 5.0+. If the project is on Symfony 6.x/7.x, this bundle may require customization or a fork due to deprecated APIs (e.g., AppKernel, assets:install).
• Laravel Misalignment: This is a Symfony bundle, not a Laravel package. While TinyMCE itself is framework-agnostic, the bundle’s integration layer (Twig extensions, Symfony event listeners, and asset management) is not directly portable to Laravel.
• Alternative Existence: Laravel already has mature TinyMCE integrations (e.g., spatie/laravel-tinymce, unisharp/laravel-ckeditor), making this bundle redundant unless legacy Symfony code must be reused.

Integration Feasibility

• Core TinyMCE Functionality: The bundle wraps TinyMCE’s JS/CSS assets and provides a Twig helper (stfalcon_tinymce) for embedding the editor. This could be replicated in Laravel using:
  • Laravel Mix/Vite for asset bundling.
  • Blade directives or a custom helper (e.g., @tinymce).
  • A service provider to register TinyMCE config globally.
• Symfony-Specific Features:
  • Twig Integration: Replace with Blade directives or a Laravel view composer.
  • Asset Installation: Laravel uses npm install/yarn + mix.copy or vite for assets.
  • Configuration Management: Symfony’s config.yml → Laravel’s .env or config/tinymce.php.
• Database/ORM Integration: If the bundle includes Doctrine listeners (e.g., for filtering HTML), these would need manual replication in Laravel’s Eloquent.

Technical Risk

• High Risk of Rewriting: The bundle’s Symfony-centric features (e.g., AppKernel, assets:install) are not transferable. A Laravel TPM would need to:
  • Extract TinyMCE’s JS/CSS dependencies.
  • Rebuild configuration logic (e.g., per-field editor settings).
  • Handle asset pipelines differently (no assets:install in Laravel).
• Maintenance Overhead: The bundle is unmaintained (last release 2023-05-25, no stars/dependents). TinyMCE itself is actively updated, but the bundle may lag.
• Deprecation Risk: Symfony 6/7 deprecates AppKernel and assets:install, which this bundle relies on. Laravel’s ecosystem has moved to Vite/Laravel Mix, requiring a full rewrite.

Key Questions for the TPM

1. Why Symfony Bundle?
   • Is this a legacy Symfony project being migrated to Laravel? If so, what’s the scope of reuse?
   • Are there specific Symfony features (e.g., Twig filters, event listeners) that must be preserved?
2. TinyMCE Version Lock
   • What version of TinyMCE is bundled? Is it compatible with the project’s needs (e.g., plugins like tinymce-table, tinymce-image-upload)?
3. Asset Management
   • How are TinyMCE assets currently served (CDN, local)? Will Laravel’s asset pipeline (Vite/Mix) support the same?
4. Configuration Flexibility
   • Does the bundle support per-field editor configurations (e.g., toolbar buttons, height)? If so, how is this exposed?
5. Alternatives Evaluation
   • Have existing Laravel TinyMCE packages (e.g., spatie/laravel-tinymce) been assessed? What gaps do they leave?
6. Testing and Validation
   • Are there existing tests for the bundle? How would integration be validated in Laravel?

Integration Approach

Stack Fit

• Laravel Incompatibility: This bundle is not natively compatible with Laravel. A TPM would need to:
  • Option 1: Fork and Adapt
    • Strip Symfony-specific code (e.g., AppKernel, assets:install).
    • Replace Twig extensions with Blade directives or a Laravel service.
    • Use Laravel’s asset pipeline (Vite/Mix) for JS/CSS.
  • Option 2: Build from Scratch
    • Use TinyMCE’s official JS library directly.
    • Create a Laravel package with:
      • A Blade directive (e.g., @tinymce).
      • Config published to config/tinymce.php.
      • Optional: A service provider for global initialization.
  • Option 3: Leverage Existing Laravel Packages
    • Prefer spatie/laravel-tinymce or unisharp/laravel-ckeditor unless this bundle offers unique features.

Migration Path

1. Assessment Phase
   • Audit the bundle’s Resources/public/ for TinyMCE assets.
   • Document Symfony-specific integrations (e.g., Twig filters, Doctrine listeners).
2. Asset Extraction
   • Copy TinyMCE JS/CSS from the bundle’s Resources/public/ to Laravel’s public/js/ or resources/js/.
   • Configure Vite/Mix to bundle TinyMCE (if using a module bundler).
3. Configuration Migration
   • Convert Symfony’s config.yml to Laravel’s .env or config/tinymce.php.
   • Example:

     // config/tinymce.php
     return [
         'selector' => 'textarea.tinymce',
         'plugins' => 'image code table',
         'toolbar' => 'bold italic | upload',
     ];
     

4. Template Integration
   • Replace Twig {{ stfalcon_tinymce() }} with a Blade directive:

     @tinymce
         @props(['config' => []])
         <script>
             tinymce.init({{ $config }});
         </script>
     

   • Or use a Laravel view composer to inject TinyMCE globally.
5. Backend Logic
   • If the bundle includes Symfony event listeners (e.g., for HTML sanitization), replicate in Laravel using:
     • Form request validation.
     • Eloquent observers or model events.
     • A middleware for global HTML filtering.

Compatibility

• TinyMCE Version: Ensure the extracted TinyMCE version matches the project’s requirements (e.g., plugins, themes).
• PHP/Symfony APIs: Replace:
  • Twig_Extension → Laravel Blade directives or view composers.
  • Asset\Packages → Laravel Mix/Vite.
  • DependencyInjection → Laravel service providers.
• Database Interactions: If the bundle filters HTML on save, recreate using:
  • Eloquent model events (saving).
  • Form request validation (e.g., validateHtml rule).

Sequencing

1. Phase 1: Asset and Config Extraction (1–2 days)
   • Isolate TinyMCE JS/CSS from the bundle.
   • Set up Laravel config for editor settings.
2. Phase 2: Blade Integration (1–3 days)
   • Create a Blade directive or view composer for editor initialization.
   • Test in a single form (e.g., a blog post editor).
3. Phase 3: Backend Logic (2–5 days)
   • Replicate any Symfony event listeners (e.g., HTML sanitization).
   • Update database models/forms if needed.
4. Phase 4: Testing and Optimization (3–7 days)
   • Test edge cases (e.g., nested editors, plugin conflicts).
   • Optimize asset loading (e.g., lazy-loading TinyMCE).
5. Phase 5: Deprecation of Old Code (Ongoing)
   • Phase out Symfony-specific integrations if migrating from Symfony.

Operational Impact

Maintenance

• Short-Term:
  • High Effort: Initial rewrite of Symfony-specific features (e.g., Twig → Blade, assets:install → Vite).
  • Ongoing: TinyMCE updates may require re-bundling JS/CSS or updating Laravel package dependencies.
• Long-Term:
  • Lower Risk: Once migrated to a Laravel-native solution (e.g., spatie/laravel-tinymce), maintenance aligns with Laravel’s ecosystem.
  • Dependency Management: TinyMCE’s CDN or npm package should be preferred over bundled assets to reduce manual updates.

Support

• Symfony-Specific Issues:
  • No direct support for the original bundle (unmaintained, no community).
  • Laravel-specific issues would require internal debugging (e.g., Blade directive conflicts).
• TinyMCE Support:
  • Official TinyMCE docs and community support are available, but bundle-specific quirks may need custom fixes.
• Team Ramp-Up:
  • Developers familiar with Symfony’s AppKernel or Twig may need training on Laravel’s service providers and Blade.
  • Documentation for the migrated solution should include:
    • Configuration examples.
    • Asset pipeline setup (Vite/Mix).
    • Common pitfalls (e.g.,