Admin Ui Laravel Package

Technical Evaluation

Architecture Fit

• Ibexa DXP Integration: This package is exclusively tied to Ibexa DXP (formerly eZ Platform Enterprise), a headless CMS with a PHP/Laravel-based backend. It is not a standalone Laravel package but a bundled component of Ibexa’s ecosystem. A TPM must assess whether the project aligns with:

  • Ibexa DXP adoption (enterprise CMS use case).
  • Laravel compatibility (Ibexa DXP is built on Symfony/Laravel, but this UI bundle is not a generic Laravel package—it’s Ibexa-specific).
  • Custom field validation (via BaseFieldValidator), which could be repurposed in Laravel if Ibexa’s API layer is abstracted.

• Monolithic vs. Modular: The package is tightly coupled with Ibexa’s backend APIs (e.g., NodeFactory, translation endpoints). Extracting it for Laravel would require significant refactoring to decouple Ibexa-specific logic.

Integration Feasibility

• Laravel Stack Fit:

  • Frontend (JS): The UI uses modern JS (ES6+) with a React-like component structure (e.g., BaseFieldValidator). Could integrate with Laravel’s Inertia.js or Livewire for reactivity.
  • Backend (PHP): Ibexa DXP uses Symfony bundles, while Laravel uses service providers. Bridging would require:
    • API abstraction layer (e.g., REST/GraphQL) to interact with Ibexa’s backend.
    • Custom Symfony bridge (e.g., symfony/http-client) to call Ibexa APIs from Laravel.
  • Database: Ibexa uses Doctrine ORM, while Laravel uses Eloquent. Migrating data would need custom mappers.

• Key Dependencies:

  • Ibexa DXP Core: Mandatory for full functionality (e.g., ez-field-edit-* selectors, NodeFactory).
  • Symfony Components: Uses symfony/*@7.4 LTS (e.g., symfony/ux, symfony/form). Laravel 10+ is compatible, but version alignment is critical.
  • Webpack Encore: For asset bundling (could replace with Laravel Mix/Vite).

Technical Risk

Key Questions for the TPM

1. Business Alignment:

   • Is Ibexa DXP a core requirement, or is this a one-off UI component?
   • Would a custom Laravel admin panel (e.g., Nova, Filament) be preferable to Ibexa’s UI?

2. Technical Trade-offs:

   • Can we abstract Ibexa’s API to work with Laravel’s Eloquent?
   • Should we rewrite the JS components to use Laravel’s frontend stack (e.g., Livewire) instead of Ibexa’s?

3. Team Capability:

   • Does the team have Symfony/Laravel + Ibexa expertise?
   • Is there budget for custom integration work (e.g., API bridges, UI isolation)?

4. Alternatives:

   • Are there Laravel-native admin UI packages (e.g., Filament, Nova) that could replace Ibexa’s functionality?
   • Could Ibexa’s headless API be used with a separate frontend framework (e.g., Next.js)?

Integration Approach

Stack Fit

Migration Path

1. Phase 1: API Abstraction

   • Create a Laravel service (IbexaApiClient) to wrap Ibexa’s REST/GraphQL endpoints.
   • Example:

     class IbexaApiClient {
         public function validateField(array $data): array {
             return Http::post('https://ibexa-api/validate', $data)->json();
         }
     }
     

2. Phase 2: Frontend Isolation

   • Option A: Embed Ibexa UI in an iframe or Shadow DOM (minimal coupling).
   • Option B: Rewrite JS components to use Laravel Livewire/Inertia (higher effort, better alignment).

3. Phase 3: Data Layer

   • Use read models to sync Ibexa data with Laravel’s database.
   • Example:

     class IbexaContentMapper {
         public function toLaravelContent(IbexaContent $content): array {
             return [
                 'title' => $content->getTitle(),
                 'body' => $content->getField('body')->value,
             ];
         }
     }
     

4. Phase 4: Hybrid Workflow

   • Use Ibexa for content management and Laravel for business logic (e.g., e-commerce).
   • Example:
     • Ibexa Admin UI → Laravel API → Ibexa Headless → Laravel Frontend.

Compatibility

• Symfony 7.4: Laravel 10+ supports Symfony 7.2+, but some components (e.g., symfony/ux) may need adjustments.
• JavaScript: Ibexa’s JS uses ES6+ modules; ensure compatibility with Laravel’s frontend stack.
• CSS: Ibexa uses custom styles (e.g., .ez-field-edit-*). Override or extract into a CSS module.

Sequencing

1. Proof of Concept (PoC):

   • Test Ibexa API calls from Laravel (e.g., Http::get('ibexa-api/endpoint')).
   • Validate BaseFieldValidator in a Laravel form.

2. Incremental Rollout:

   • Start with read-only Ibexa UI integration.
   • Gradually add write operations (e.g., content creation).

3. Fallback Plan:

   • If integration is too complex, replace Ibexa UI with Filament/Nova and keep Ibexa as a headless backend.

Operational Impact

Maintenance

• Dependencies:

  • Ibexa releases quarterly; Laravel follows its own cadence. Version skew may require frequent updates.
  • Symfony bridge adds maintenance overhead (e.g., dependency conflicts).

• Support:

  • Ibexa-specific issues (e.g., IBX-11376) require Ibexa’s support team.
  • Custom integration bugs fall to the Laravel team.

• Tooling:

  • Webpack Encore → Replace with Laravel Vite for consistency.
  • Doctrine → No direct maintenance needed if using API abstraction.

Support

• Team Skills:
  • Requires Symfony + Laravel + Ibexa expertise. Gaps may need training or hiring.
• Vendor Support: