Website Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Monolithic vs. Modular Fit: The austral/website-bundle appears designed for modular Laravel/Symfony applications leveraging the Austral ecosystem (e.g., tools-bundle, seo-bundle). If the target system is a traditional Laravel monolith, integration may require significant abstraction layers to avoid tight coupling with Austral’s entity interfaces (e.g., EntityTranslate, ContentBlock).
• Domain-Driven Design (DDD) Alignment: The bundle assumes a multi-domain, multi-language CMS-like architecture (e.g., DomainListener, seo-bundle). If the product lacks these patterns, custom adapters will be needed to map Austral’s abstractions (e.g., EntityFile, ContentBlock) to existing data models.
• Symfony Compatibility: While Laravel-compatible, the bundle’s reliance on Symfony components (e.g., symfony/config) and Doctrine extensions (e.g., PostgreSQL support) introduces indirect dependencies. A Laravel TPM must assess whether these are acceptable or require polyfills (e.g., Laravel’s own config system).

Integration Feasibility

• Core Features:
  • Multi-domain routing: Feasible if the app supports dynamic routing (e.g., via Laravel’s Route::domain()). Otherwise, requires middleware or service container hacks.
  • SEO and translation: Highly feasible if the app already uses Doctrine ORM and supports multi-language content. If not, the entity-translate-bundle and seo-bundle will need significant customization.
  • Content blocks: Feasible for modular content management (e.g., page builders), but may conflict with existing templating (e.g., Blade vs. Austral’s assumed Symfony templating).
• Challenges:
  • Austral Ecosystem Lock-in: The bundle is tightly coupled with other Austral bundles (e.g., tools-bundle, http-bundle). Migrating away later could be costly.
  • PostgreSQL Dependency: If the app uses MySQL/SQLite, the martin-georgiev/postgresql-for-doctrine requirement may necessitate a database migration or forked bundle.
  • Admin Panel Removal: The bundle removed auto-generated admin panels (v3.0.1), implying reliance on custom admin UIs (e.g., Laravel Nova, Filament, or Symfony UX). This may force a redesign.

Technical Risk

Key Questions for the TPM

1. Architecture Alignment:
   • Does the product’s current architecture support multi-domain, multi-language content? If not, what’s the cost to refactor?
   • Are we willing to adopt the Austral ecosystem long-term, or is this a short-term solution?
2. Dependency Risks:
   • Can we replace austral/* bundles with Laravel-native alternatives (e.g., Spatie’s Laravel SEO, Laravel Translatable)?
   • What’s the fallback plan if PostgreSQL is non-negotiable?
3. Feature Gaps:
   • How will we handle admin panel generation without the auto-scaffolded UI?
   • Does the bundle’s content block system conflict with existing CMS features (e.g., Laravel Medialibrary, Nova Resources)?
4. Testing & Validation:
   • Are there existing tests for the bundle? (Low stars/release activity suggests minimal QA.)
   • How will we validate multi-domain routing and SEO metadata generation in staging?
5. Team Skills:
   • Does the team have experience with Symfony bundles or Doctrine extensions? If not, what’s the ramp-up cost?

Integration Approach

Stack Fit

• Laravel Compatibility:

  • The bundle is Laravel-compatible but assumes Symfony-like patterns (e.g., bundles, Doctrine extensions). A TPM should:
    • Use Laravel’s Service Provider pattern to bootstrap the bundle.
    • Replace Symfony-specific components (e.g., ContainerBuilder) with Laravel equivalents where possible.
  • Recommended Stack Additions:
    • Doctrine ORM: Required for EntityTranslate, ContentBlock, etc. (Laravel’s Eloquent may need a bridge).
    • PostgreSQL: Only if the bundle’s features (e.g., JSONB fields in entity-file-bundle) are critical.
    • Symfony HTTP Foundation: For http-bundle compatibility (may conflict with Laravel’s Illuminate\Http).

• Alternatives to Consider:

  • For SEO: spatie/laravel-seo or beberlei/doctrineextensions (Laravel-friendly).
  • For Multi-Language: spatie/laravel-translatable or laravel-localization.
  • For Content Blocks: spatie/laravel-medialibrary + custom Blade components.

Migration Path

1. Phase 1: Proof of Concept (2-4 weeks)

   • Isolate the bundle in a new Laravel project to test:
     • Multi-domain routing.
     • SEO metadata generation.
     • Content block rendering.
   • Key Tests:
     • Deploy to a staging environment with multiple domains.
     • Verify translation fallback and SEO tags (e.g., OpenGraph).
     • Check performance impact (bundle may add ~200ms overhead for Doctrine events).

2. Phase 2: Incremental Integration (4-8 weeks)

   • Step 1: Core Features
     • Integrate routing and SEO first (lowest risk).
     • Use Laravel’s middleware to adapt Austral’s DomainListener.
   • Step 2: Content Management
     • Migrate content blocks to a hybrid system (e.g., store blocks in Eloquent, render with Blade).
     • Replace entity-file-bundle with spatie/laravel-medialibrary if possible.
   • Step 3: Admin Panel
     • Build a custom admin UI (e.g., Filament) to replace the removed auto-generated panel.
     • Use Austral’s ModuleListener as a data source only.

3. Phase 3: Full Cutover (2-4 weeks)

   • Deprecate legacy systems (e.g., old SEO management, static pages).
   • Train team on Austral’s entity interfaces (e.g., ContentBlockInterface).
   • Roll out in feature flags to monitor errors.

Compatibility

Sequencing

1. Prerequisites:

   • Upgrade to Laravel 9+ (PHP 8.0+ required).
   • Ensure Doctrine ORM is installed (if not using Eloquent).
   • Set up multi-domain DNS for testing (e.g., app.test, blog.app.test).

2. Order of Operations:

   • Step 1: Install bundle via Composer (composer require austral/website-bundle).
   • Step 2: Configure config/packages/austral_website.yaml (adapt for Laravel’s config structure).
   • Step 3: Register the bundle’s service provider in config/app.php.
   • Step 4: Implement custom route middleware to handle multi-domain logic.
   • Step 5: Migrate existing content to Austral’s ContentBlock entities.
   • Step 6: Replace admin panel with a Laravel-native solution (e.g., Filament).

3. Rollback Plan:

   • Database: Maintain a backup of pre-migration schemas.
   • Routing: Fallback to Laravel’s native routing if multi-domain fails.
   • SEO: Cache old metadata until new system is verified.

Operational Impact

Maintenance

• Bundle Updates: