Calendar Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Pros:

  • Modular Design: The bundle follows OroPlatform’s modular architecture, making it a natural fit for Laravel applications leveraging Symfony components (e.g., via laravel/symfony-bundle or spatie/laravel-symfony-messenger). Its entity-driven structure aligns with Laravel’s Eloquent ORM if adapted via Doctrine Bridge.
  • Extensibility: Supports custom calendar types and external sync (e.g., Google Calendar via API), which can be leveraged for hybrid PHP/Laravel integrations.
  • ACL & RBAC: Built-in authorization (e.g., Manage system calendars) integrates with Symfony’s security system, which can be mapped to Laravel’s spatie/laravel-permission or custom gate policies.
  • Event-Driven: Recurring events and cron-like scheduling (via Symfony’s CronBundle or Laravel’s spatie/scheduler) are viable for workflow automation.

• Cons:

  • Symfony-Centric: Heavy reliance on Symfony components (e.g., Twig, DependencyInjection, EventDispatcher) may require wrappers or polyfills for pure Laravel. Key dependencies:
    • oro/platform (abandoned; requires fork or alternative like api-platform).
    • doctrine/orm (compatible via laravel-doctrine or illuminate/database bridge).
  • Legacy Codebase: Last release in 2018 with minor updates since (e.g., 6.x changelogs reference 2022–2025, but no active maintenance). Risk of deprecated Symfony 3/4 patterns.
  • Monolithic Features: Tight coupling with OroPlatform’s EntityManager, Datagrid, and Search bundles may necessitate refactoring for Laravel’s simpler needs (e.g., no need for Oro’s multi-tenant Organization model).

Integration Feasibility

• Laravel Compatibility:

  • Doctrine ORM: Possible via laravel-doctrine/orm or illuminate/database bridge, but requires manual mapping of Doctrine entities to Eloquent models.
  • Twig: Replace with Laravel’s Blade or use spatie/laravel-twig-view (limited support).
  • Dependency Injection: Symfony’s DI can coexist via symfony/dependency-injection or laravel-symfony-bundle, but may conflict with Laravel’s service container.
  • Routing: Symfony’s Router can integrate via spatie/laravel-symfony-router, but requires URL generation adjustments.

• Key Challenges:

  • Event System: Oro’s event listeners (e.g., calendar.event.create) must be translated to Laravel’s events or observers.
  • Search: Oro’s SearchBundle is non-trivial to replace; consider spatie/laravel-searchable or Elasticsearch.
  • Assets: Twig templates and JS/CSS (e.g., FullCalendar) need migration to Laravel Mix/Vite.

Technical Risk

• High:
  • Maintenance Overhead: Outdated codebase (e.g., Symfony 3.x) may introduce security/compatibility risks with modern Laravel (10.x+).
  • Performance: Oro’s datagrid and search layers add complexity; Laravel’s simpler query builder may suffice for basic calendars.
  • Testing: Lack of recent activity suggests limited CI/CD or test coverage for edge cases (e.g., recurring event conflicts).
• Mitigation:
  • Fork & Modernize: Prioritize updating to Symfony 6.x/Laravel 10.x dependencies (e.g., symfony/ux for Twig/Stimulus).
  • Feature Pruning: Strip unused OroPlatform features (e.g., multi-tenancy) to reduce bloat.
  • Hybrid Approach: Use only the CalendarEvent entity and controllers, building UI with Laravel’s Inertia/Vue/React.

Key Questions

1. Scope Clarification:
   • Is this for user-only calendars, system-wide calendars, or both? (Affects ACL/complexity.)
   • Are external syncs (e.g., Google Calendar) required, or is internal storage sufficient?
2. Stack Constraints:
   • Can Symfony components (e.g., Twig, DI) coexist with Laravel, or must we use Laravel-native alternatives?
   • Is Doctrine ORM mandatory, or can we use Eloquent with a custom bridge?
3. Performance:
   • What scale is targeted? (Oro’s datagrid may be overkill for <10K events.)
4. Long-Term Viability:
   • Is the team willing to maintain a fork, or should we build a lightweight alternative (e.g., spatie/calendar + custom events)?

Integration Approach

Stack Fit

• Laravel-Centric Path:

  • Entities: Use Eloquent models with a custom bridge to map Oro’s CalendarEvent to Laravel tables (e.g., calendar_events).
  • Routing: Replace Symfony routes with Laravel’s Route::resource() or API routes.
  • Views: Migrate Twig templates to Blade or Inertia.js (Vue/React).
  • Authorization: Replace Oro’s ACL with Laravel’s spatie/laravel-permission or gates.
  • Scheduling: Use spatie/scheduler for recurring events instead of Oro’s cron system.
  • Search: Implement Laravel Scout or a simple DB query for basic use cases.

• Symfony Hybrid Path (if Symfony components are unavoidable):

  • Bundles: Install laravel-symfony-bundle to share Symfony services (e.g., DI, EventDispatcher).
  • Twig: Use spatie/laravel-twig-view for templates, but expect limited Blade integration.
  • Doctrine: Use laravel-doctrine/orm for entity management, but avoid mixing with Eloquent.
  • Assets: Bundle JS/CSS via Laravel Mix with Symfony’s Encore.

Migration Path

1. Assessment Phase:
   • Audit dependencies (e.g., oro/platform → api-platform or custom fork).
   • Identify critical features (e.g., recurring events, ACL) vs. non-essential (e.g., Oro’s datagrid).
2. Proof of Concept:
   • Port CalendarEvent entity to Eloquent and test CRUD operations.
   • Implement a basic FullCalendar/Vue.js frontend to validate UI flow.
3. Incremental Rollout:
   • Phase 1: User calendars (simplest; no ACL).
   • Phase 2: System calendars + ACL (use spatie/laravel-permission).
   • Phase 3: Recurring events + external sync (e.g., Google Calendar API).
4. Deprecation:
   • Replace Oro-specific services (e.g., oro_calendar.twig.dateformat) with Laravel equivalents.

Compatibility

• Doable but Non-Trivial:
  • Doctrine ↔ Eloquent: Possible with a custom repository or laravel-doctrine bridge, but expect query differences.
  • Symfony Events ↔ Laravel Events: Use a listener adapter to translate Oro’s calendar.event.create to Laravel’s event() helper.
  • Twig ↔ Blade: Manual migration required; consider Inertia.js for shared logic.
• Breakage Risks:
  • Symfony’s ParameterBag → Laravel’s config().
  • Oro’s Organization model → Laravel’s tenancy (if needed) or flat structure.
  • Twig filters (e.g., oro_calendar.twig.recurrence) → custom Blade directives.

Sequencing