Page Bundle Laravel Package

Technical Evaluation

Architecture fit — the framing is wrong before anything else. enhavo/page-bundle is not a Laravel package. It is a Symfony bundle and an auto-generated subtree split of the Enhavo CMS monorepo. It assumes registration in a Symfony kernel (config/bundles.php), compilation through Symfony's DI container, and the presence of sibling bundles (resource, routing, block, media, admin). A Laravel application cannot host it in-process: Laravel's service providers are not a substitute for bundle extension semantics, and the dependency graph (Doctrine ORM/DBAL, HttpKernel, Form, Twig, multiple enhavo/* packages) collides with Eloquent, Blade, facades, and Laravel's own pinned symfony/* constraints. The realistic architecture fit for a Laravel codebase is zero; for a Symfony estate already running Enhavo it is native.

Integration feasibility — three paths, two of them real.

• Non-starter: composer-require into Laravel and hand-wire a kernel shim. You would run two frameworks with overlapping ownership of routing, sessions, security, and caching. Reject without a spike.
• Viable: run Enhavo as a separate Symfony content service and expose pages to Laravel over JSON or a materialized read model. Isolates the framework mismatch behind a contract.
• Viable: treat this bundle as a design reference, not a dependency — mine its Page model (templated pages, slug routing, draft/scheduled publication, block composition) and reimplement in Laravel. Costs engineering time, keeps one runtime.

Technical risk. Distribution risk: the repo is explicitly read-only; issues, PRs, and release notes live upstream, and anything filed here is effectively lost. Adoption signal: 0 stars and 0 dependents on the split — the parent project has genuine usage, but the split has no independent community to catch regressions. Version coupling: tagged in lockstep with the monorepo, so pinning this package implicitly pins a large slice of Enhavo; you cannot patch it independently. Data-layer impedance: Enhavo is Doctrine-driven with its own schema tooling — sharing a database with Eloquent creates two schema owners and durable drift. Documentation risk: maturity is literally "readme"; the package-level API surface must be inferred from source and the main repo.

Key questions a TPM must close before commitment.

1. Is the target Laravel-only, or is there an existing Symfony estate this would join? If Laravel-only, this package is out of scope and the decision shifts to alternatives (Statamic, a headless CMS, or a bespoke page module).
2. Which Enhavo/Symfony/PHP versions are supported, and what is upstream's release cadence and security-patch latency?
3. What is the minimum bundle set to render a routable page — does page-bundle alone produce output, or are admin/resource bundles mandatory?
4. Is authoring in Enhavo's admin UI in scope, or do we only need the page data model? Only the latter is portable.
5. Who on the team owns upgrades, and what is the bus factor for Symfony/Enhavo depth?
6. Are there IP or supply-chain concerns in the surrounding enhavo/* packages we would unavoidably pull in?

TPM leverage point: this artifact's value is as a scoping and make-vs-buy input, not as a deliverable. It defines what "page management" means inside one vendor's stack and gives you a costed reference model; it carries no signal about ecosystem health, API stability, or CMS market position.

Integration Approach

Stack fit. No clean fit with Laravel. Adopting it means a second framework, ORM, templating engine, container, and migration system. The only clean fits are (a) an existing Symfony app where Enhavo is already the CMS, or (b) a service-oriented architecture with Enhavo as a standalone content service.

Compatibility. Requires a Symfony kernel and Doctrine. Laravel shares only low-level Symfony components, pinned by Laravel's own constraints, so Composer will frequently find no satisfiable set. Treat dependency-resolution failure as the expected outcome, not the exception — verify this in a half-day spike before any design work.

Sequencing — service-oriented path.

1. Stand up vanilla Enhavo from the main repository, not the split; consume the split only transitively.
2. Define the content contract first and keep it narrow: fields, slug/history semantics, publication states, block types. Every exposed field is a coupling point.
3. Expose it read-only (JSON endpoint or a materialized table written by Enhavo, read by Laravel).
4. Build a Laravel content client with tagged caching and a null-object fallback so Laravel renders safely when the CMS is down.
5. Only then decide whether preview, authoring UI, and workflow need deeper integration.

Sequencing — reimplementation path.

1. Write the Enhavo page model up as a spec from source: page types, route generation, slug redirects, publication windows, block composition.
2. Build an internal Laravel package: pages table, polymorphic block storage (JSON or blocks table), slug-history table for redirects, published_at/expires_at scopes.
3. Render via Blade components per block type; expose admin CRUD through Filament or Nova.
4. Bounded 2–6 weeks for a competent Laravel team, and it eliminates all cross-framework risk.

Migration path. The service-oriented option keeps Enhavo behind a contract, so leaving later is a client-swap — a bounded change. That optionality is the main argument for the service model over any in-process attempt. Note the subtree split cannot be patched locally: splits are overwritten on sync, so any customization is either an upstream contribution or a genuine monorepo fork.

Operational Impact

Maintenance. Two maintenance surfaces in the service model (Enhavo app + Laravel app) versus one in the reimplementation model. Enhavo upgrades arrive as monorepo-wide releases, and the read-only split ships no changelog, so upgrade triage begins upstream. Local patches to this bundle are not a durable option; plan for upstream PRs or a Composer patch layer.

Support. No vendor SLA. Community and upstream issue tracker only, and this repository is not a channel. For a TPM this is the decisive operational fact: you accept an unbounded support dependency on a project with no commercial backing and no independent adoption signal on the split package. Budget for internal ownership of any production usage.

Scaling. Page rendering is read-heavy and cacheable; either architecture scales with a CDN and page cache. The real cost is organizational: two runtimes mean two deploy pipelines, two observability stacks, two dependency-update cadences, and two security-patch streams. Design the Laravel client with aggressive caching so the CMS is off the critical path for anonymous traffic.

Failure modes to design against.

• Composer resolution failure on any Symfony/Laravel bump — pin hard, test upgrades in isolation.
• Container compile errors after an Enhavo release, with no split-level changelog to diff against.
• Schema drift if a shared database is used and two migration owners exist.
• Stale publication state if page windows (published_at/expires_at) are cached without TTL or invalidation on publish.
• Upstream abandonment — the split gives no early warning; the escape hatch is the contract boundary or a monorepo fork.

Ramp-up. Requires Symfony/Enhavo-specific depth that a Laravel team does not carry. Expect several weeks before a engineer is productive in the bundle's source-defined model, and note the bus factor: this is typically a one-person dependency in a Laravel shop. The reimplementation path trades that ramp-up for a bounded build in a stack the team already knows, which is usually the better TPM trade.