Core Laravel Package

Technical Evaluation

Architecture Fit

• Modularity Alignment: REDAXO’s plugin architecture (rex_addon) mirrors Laravel’s service providers and package structure, enabling seamless modular integration. The CMS’s event system (rex_event) can be mapped to Laravel’s event system via custom listeners, reducing boilerplate for cross-stack communication.
• Database Compatibility: REDAXO’s MySQL schema is rigid but can be abstracted via Eloquent models or a data access layer (DAL). For hybrid setups, consider a shared database with namespaced tables (e.g., redaxo_articles, laravel_users) to avoid conflicts. Laravel’s migrations can extend REDAXO tables without full schema replacement.
• PHP Version Synergy: Both stacks support PHP 8.1+, but REDAXO’s legacy patterns (e.g., global rex() functions) may require refactoring to Laravel’s DI container for maintainability. Use facades or service providers to wrap REDAXO’s procedural functions.
• Frontend Decoupling: REDAXO’s templating system (YAML/HTML) is not natively Blade-compatible, but a templating bridge (e.g., custom Blade directives or a middleware layer) can render REDAXO content in Laravel views. For headless use, REDAXO’s REST API (rex_api) integrates cleanly with Laravel’s HTTP client or API resources.

Integration Feasibility

• API-First Strategy: REDAXO’s REST/GraphQL plugins can serve as a headless backend for Laravel, decoupling content management from frontend logic. This approach minimizes direct integration but may introduce latency for tightly coupled workflows (e.g., real-time previews).
• Authentication Sync: REDAXO’s user system (rex_user) can be synchronized with Laravel’s auth() via:
  • Custom Guard: Extend Laravel’s Authenticatable to fetch users from REDAXO’s database.
  • Passport/Sanctum: Use Laravel’s OAuth packages to proxy REDAXO’s auth endpoints.
• Asset Pipeline: REDAXO’s static assets (CSS/JS) can be integrated into Laravel Mix via:
  • Webpack Plugins: Use copy-webpack-plugin to include REDAXO’s assets in Laravel’s build.
  • CDN Proxy: Serve REDAXO assets via a CDN with Laravel’s asset() helper.
• Caching Layer: REDAXO’s caching (rex_cache) should leverage Laravel’s cache drivers (Redis, Memcached) via a facade wrapper to avoid duplication. Example:

  // In a Laravel service provider
  Cache::extend('redaxo', function () {
      return Cache::repository(new RedaxoCacheStore());
  });
  

Technical Risk

• Schema Conflicts: Merging REDAXO’s schema with Laravel’s (e.g., users, sessions) risks data corruption without a phased migration. Use Doctrine Migrations or custom scripts to handle schema changes incrementally.
• Performance Overhead: REDAXO’s legacy components (e.g., YAML configs, procedural code) may introduce runtime bottlenecks. Profile with Laravel’s debugbar or Blackfire to identify and optimize hotpaths.
• Plugin Ecosystem Gaps: REDAXO plugins (e.g., rex_media) may lack Laravel compatibility. Wrapper classes or composer packages (e.g., laravel-redaxo/media) can bridge this gap but require upfront development.
• Testing Coverage: Limited Laravel-specific tests for REDAXO core functions could expose unexpected failures. Prioritize:
  • Unit Tests: Mock REDAXO services in Laravel’s PHPUnit tests.
  • Integration Tests: Validate API responses and auth flows.
  • E2E Tests: Use Laravel Dusk or Cypress for hybrid workflows.

Key Questions

1. Architectural Scope:
   • Will REDAXO replace Laravel entirely, or is this a hybrid migration (e.g., REDAXO for CMS, Laravel for business logic)?
   • Are there feature parity gaps (e.g., missing Laravel packages) that could block migration?
2. Team Expertise:
   • Does the team have experience with REDAXO’s procedural patterns or Laravel’s DI container?
   • Are resources allocated for refactoring legacy code (e.g., converting rex() calls to service providers)?
3. Performance SLAs:
   • What are the acceptance criteria for latency (e.g., API response times, page load speeds) post-integration?
   • Is caching strategy (e.g., Redis vs. file-based) aligned between stacks?
4. Rollback Plan:
   • How will the team revert to REDAXO-only if Laravel integration fails?
   • Are there critical dependencies (e.g., plugins) that cannot be replicated in Laravel?
5. Long-Term Roadmap:
   • Will REDAXO’s plugin ecosystem be deprecated in favor of Laravel packages?
   • Are there plans to native Laravelize REDAXO’s core (e.g., convert hooks to events)?

Integration Approach

Stack Fit

• Laravel as Frontend/Service Layer:
  • Use REDAXO’s API (rex_api) to fetch content, then render via Blade templates or a SPA (Vue/React).
  • Leverage Laravel’s routing (routes/api.php) to proxy REDAXO endpoints or extend them with business logic.
  • Example: A Laravel controller consumes REDAXO’s API and adds metadata:

    public function show(Article $article) {
        $redaxoData = Http::get('http://redaxo/api/articles/' . $article->id);
        return view('articles.show', [
            'article' => $article,
            'redaxoContent' => $redaxoData->json(),
        ]);
    }
    

• REDAXO as CMS Backend:
  • Keep REDAXO for content editing, while Laravel handles authentication, business logic, and frontend delivery.
  • Example: REDAXO manages articles; Laravel handles subscriptions (via Laravel Cashier) and payment workflows.
• Hybrid Architecture:
  • Shared Database: Use a single database with Laravel’s Eloquent models extending REDAXO’s tables via custom traits or accessors.

    class RedaxoArticle extends Model {
        protected $table = 'redaxo_articles';
        public function getContentAttribute() {
            return $this->content; // Custom logic
        }
    }
    

  • Separate Instances: Run REDAXO and Laravel as microservices, communicating via API (e.g., GraphQL with Laravel GraphQL + REDAXO’s REST).

Migration Path

1. Phase 1: API Decoupling (Low Risk)

   • Goal: Validate data flow without schema changes.
   • Steps:
     • Expose REDAXO content via its REST API (rex_api).
     • Build Laravel controllers to consume the API (e.g., ArticleController@index fetches from /api/articles).
     • Use Laravel’s HTTP client for requests:

       $articles = Http::get('http://redaxo/api/articles')->json();
       

   • Tools: Postman, Laravel HTTP client, API testing (Pest).
   • Validation: Ensure data integrity (e.g., no missing fields, correct serialization).

2. Phase 2: Shared Auth & Services (Medium Risk)

   • Goal: Sync users and core services between stacks.
   • Steps:
     • User Sync: Write a migration script to copy REDAXO users to Laravel’s users table:

       // In a Laravel Artisan command
       $redaxoUsers = DB::connection('redaxo')->select('SELECT * FROM rex_user');
       foreach ($redaxoUsers as $user) {
           User::create([
               'name' => $user->username,
               'email' => $user->email,
               // Map REDAXO roles to Laravel permissions
           ]);
       }
       

     • Custom Guard: Extend Laravel’s Authenticatable to fetch users from REDAXO’s database:

       class RedaxoGuard extends Guard {
           public function user() {
               $user = DB::connection('redaxo')->table('rex_user')->find($this->id);
               return new User($user);
           }
       }
       

     • Service Wrappers: Create Laravel service providers to wrap REDAXO functions (e.g., rex_media):

       // In a service provider
       $this->app->singleton('redaxo.media', function () {
           return new RedaxoMediaService();
       });
       

   • Tools: Laravel Passport, custom middleware, PHPUnit for auth tests.

3. Phase 3: Database Integration (High Risk)

   • Goal: Merge schemas or create a hybrid data layer.
   • Approach A: Shared Database (Tight Coupling)
     • Use Laravel’s migrations to extend REDAXO tables (e.g., add Laravel-specific columns):

       Schema