Source Laravel Package

Technical Evaluation

Architecture Fit

• Modular & Extensible: REDAXO’s architecture is built around a plugin-based system (addons/modules), allowing deep customization via PHP classes, YAML configs, and event-driven hooks (e.g., EP_*, SLICE_BE_PREVIEW). This aligns well with Laravel’s modularity but requires a hybrid approach—Laravel’s service container can wrap REDAXO’s core classes (e.g., rex_*) for dependency injection.
• Legacy PHP vs. Modern Laravel: REDAXO’s core is procedural/OOP-mixed, while Laravel enforces PSR-12/PSR-4. A TPM must decide between:
  • Wrapper Layer: Abstract REDAXO’s classes into Laravel services (e.g., RexArticleService extending ArticleRepository).
  • Hybrid Monolith: Embed REDAXO as a sub-framework (e.g., /redaxo/ directory) with Laravel routing to its frontend/backend.
• Database Abstraction: REDAXO uses raw SQL (rex_sql) and active record patterns (rex_article, rex_media). Laravel’s Eloquent can coexist but requires custom model bindings (e.g., RexArticleModel extending Model with static find() overrides).
• Event System: REDAXO’s event points (EP_*) and hooks can be mapped to Laravel’s events/listeners or service provider boot methods, but require manual translation (e.g., EP_ARTICLE_SAVE → event(new ArticleSaved($article))).

Integration Feasibility

• High for Backend-Only Use Cases: If the goal is to leverage REDAXO’s CMS features (e.g., content management, media library) while using Laravel for APIs/auth, integration is feasible but non-trivial.
  • Example: Use Laravel’s Sanctum/Passport for auth, redirect to REDAXO’s backend (/index.php?page=...), and fetch content via REDAXO’s API addon or custom endpoints.
• Challenging for Full-Stack Replacement: Replacing Laravel’s frontend (Blade, routes) with REDAXO’s template system (Smarty-like) would require:
  • Reverse-proxy setup (Nginx/Apache) to route /admin to REDAXO and /api to Laravel.
  • Shared session/auth between Laravel’s middleware and REDAXO’s rex_user.
• Dependency Conflicts:
  • REDAXO uses Symfony 7.4, while Laravel uses Symfony 6.x/7.x. Overlapping components (e.g., symfony/console, symfony/http-foundation) may cause version conflicts.
  • Solution: Use Composer’s replace or vendor patching to isolate dependencies.

Technical Risk

Key Questions for the TPM

1. Scope Clarity:
   • Is REDAXO being used for content management only (backend) or full-stack replacement (frontend + backend)?
   • Will Laravel handle auth/APIs while REDAXO manages content, or vice versa?
2. Team Skills:
   • Does the team have REDAXO-specific expertise (e.g., YAML configs, addon development)?
   • Is there budget for custom integration work (e.g., event bridges, wrapper services)?
3. Hosting/Deployment:
   • Will this run on shared hosting (REDAXO’s traditional strength) or Laravel-friendly VPS/cloud?
   • How will shared sessions (Laravel + REDAXO) be managed?
4. Future-Proofing:
   • Is REDAXO’s MIT license compatible with the project’s licensing?
   • What’s the upgrade path if REDAXO abandons PHP 8.3 support?
5. Alternatives:
   • Would Laravel’s built-in CMS features (e.g., Nova, Filament, or custom modules) be a better fit?
   • Could Statamic or October CMS (Laravel-based) reduce integration risk?

Integration Approach

Stack Fit

• Laravel + REDAXO Hybrid:
  • Laravel: Handles APIs, auth (Sanctum/Passport), and frontend (Blade/Vue).
  • REDAXO: Manages content, media, and admin UI.
  • Shared Layer: Custom Laravel service providers to wrap REDAXO classes (e.g., RexArticleService).
• Tech Stack Compatibility:

  Component	Laravel Fit	REDAXO Fit	Integration Notes
  Routing	Excellent	Basic	Use Laravel routes for /api, proxy /admin to REDAXO.
  Authentication	Excellent	Basic	Sync users via rex_user table or custom bridge.
  Database	Excellent	Basic	Shared schema (risky) or separate DBs.
  Templates	Blade	Smarty	Avoid mixing; use REDAXO for admin, Blade for frontend.
  Event System	Events	EP_Hooks	Build a translator service.
  Dependency Mgmt	Composer	Composer	Risk of version conflicts (Symfony, PHPMailer).

Migration Path

1. Phase 1: Proof of Concept (2-4 weeks)
   • Set up Laravel + REDAXO in parallel (same codebase, separate routes).
   • Implement basic content sync (e.g., fetch REDAXO articles via API addon).
   • Test auth handoff (e.g., Laravel auth → REDAXO backend).
2. Phase 2: Core Integration (4-8 weeks)
   • Build wrapper services for critical REDAXO classes (e.g., rex_article, rex_media).
   • Implement event translation (e.g., REDAXO EP_ARTICLE_SAVE → Laravel article.saved).
   • Set up shared session handling (e.g., Laravel session driver storing REDAXO’s rex_session).
3. Phase 3: Full Stack Adoption (8-12 weeks)
   • Migrate frontend templates to Blade (if replacing REDAXO’s frontend).
   • Replace REDAXO’s media library with Laravel’s filesystem + custom upload handlers.
   • Optimize database queries (REDAXO’s raw SQL vs. Eloquent).

Compatibility Considerations

• Database:
  • REDAXO uses MySQL/MariaDB with a custom schema (rex_* tables). Laravel’s Eloquent can coexist but requires:
    • Custom model bindings (e.g., RexArticle extends Model with static find() overrides).
    • Shared migrations (risky; prefer separate DBs for critical apps).
• Dependencies:
  • Symfony 7.4 in REDAXO vs. Symfony 6.x/7.x in Laravel → isolate dependencies via Composer’s replace or vendor patching.
  • PHPMailer: REDAXO uses v7; Laravel may use v6 → pin versions or use Laravel’s SwiftMailer.
• Templates:
  • REDAXO uses Smarty-like syntax; Laravel uses Blade. Avoid mixing unless absolutely necessary.
  • Solution: Use REDAXO for admin templates, Blade for frontend.

Sequencing

1. Start with Non-Critical Features:
   • Begin with content management (articles, media) before tackling user auth or complex workflows.
2. Prioritize Shared Services:
   • Implement auth sync early (e.g., Laravel Sanctum + REDAXO rex_user).
   • Build content API endpoints before full template migration.
3. Avoid Tight Coupling:
   • Use event bridges (e.g., REDAXO EP_ARTICLE_SAVE → Laravel event