Page Bundle Laravel Package

Product Decisions This Supports

• A framework-fit gate, not a feature decision. Despite being catalogued as a "Laravel/PHP package," enhavo/page-bundle is a Symfony bundle — the page-management module of the Enhavo CMS, published as a read-only subtree split of the main monorepo. It cannot be dropped into a Laravel application. For a Laravel-based product, the output of this evaluation is a scope exclusion, not a build-vs-buy input. Making that call early prevents engineering from burning a sprint on a dependency-resolution dead end.
• Build vs. buy for the content/page layer. If the roadmap includes marketing pages, structured editorial content, slug/routing management, or an authoring UI, this bundle represents the "buy" side of that decision — but only inside one vendor stack (Enhavo on Symfony). The real product question is "do we adopt Enhavo as our CMS?", and this artifact is a single module of that answer, not a standalone option.
• Roadmap scoping against the page model it implies. Its feature set is a useful checklist regardless of vendor: page entities with configurable templates, composable content blocks, draft/scheduled publishing, SEO-friendly URLs with metadata, and an admin interface. Those are the capabilities to cost out in any alternative — headless CMS, Statamic, Filament-based admin, or a bespoke Laravel module. Use it to scope the requirements, not to source the implementation.
• Dependency ownership planning if Enhavo is already in the stack. Where Enhavo exists, this bundle is a versioned component of the product: it is tagged in lockstep with the monorepo, has no independent changelog, and receives no local patches (subtree splits are overwritten on sync). Upgrades therefore need coordination with the parent project's release cadence, and the decision to extend versus fork the monorepo is a resourcing commitment owned at the product level.
• Fork-vs-extend planning. Because the split is read-only, customization has exactly two branches: contribute extension points upstream (patches flow back, maintenance shared) or fork the monorepo (permanent internal ownership). That trade-off belongs in planning, not in a ticket.
• Explicitly not a market signal. Zero stars, zero dependents, and a README that says only "see main repository" mean this repository carries no usable evidence about ecosystem health, API stability, or community support. Do not use it to benchmark the CMS landscape or to justify a framework migration.

When to Consider This Package

Consider it only when all of the following hold:

• The target application is on Symfony, not Laravel, and the team has already committed to Enhavo as the CMS or admin foundation.
• You are installing the Enhavo distribution and letting Composer resolve enhavo/page-bundle transitively — pinning it in lockstep with the parent project's release rather than version-selecting it independently.
• You need page management as part of a broader Enhavo capability set (content, routing, blocks, media, admin UI), not as a self-contained library.
• The team accepts upstream-first maintenance: issues, documentation, and pull requests belong in enhavo/enhavo; this repository is a publishing artifact only.
• MIT licensing and a subtree-split release process clear legal and supply-chain review (including the surrounding enhavo/* packages it pulls in).

Look elsewhere when:

• You are on Laravel. Evaluate Laravel-native routes — Statamic, October CMS, a Filament or Nova admin over a custom content model, or a headless CMS behind an API. Nothing here transfers, and bootstrapping a Symfony kernel inside Laravel means two containers, two ORMs, two templating engines, and two migration systems in one process.
• You need a standalone, documented, independently versioned package. There are no install steps, no documented API surface, no upgrade notes, and no visible tests or CI in this repository. The "readme" maturity rating is literal.
• You need community support or reference integrations. Zero dependents means no third-party examples and no peer-reviewed integration patterns; every question routes to the upstream maintainers.
• You want Symfony CMS capability without adopting Enhavo wholesale. Compare Symfony CMF, Sulu, Ibexa, or a thin custom content layer first.
• Vendor-risk tolerance is low. A single upstream maintainer path with no commercial backing is a concentration risk; if the parent project stalls, your only patch path is a local fork of the monorepo.
• The scope is data-model-only. If all you need is pages, slugs, publication windows, and composable blocks, a bounded internal build is usually cheaper than adopting a full distribution — and it keeps one runtime.

How to Pitch It (Stakeholders)

To executives. This is not something we can adopt as a dependency. It is one module of the Enhavo CMS — a Symfony application — automatically republished from that project's main repository as a read-only mirror, with no standalone documentation, no independent releases, and no downstream users. The only decision it informs is whether we build our content and page-management layer on Enhavo, which is out of scope for our Laravel stack. Recommendation: do not adopt. If content management is a genuine roadmap priority, fund a short, scoped evaluation of CMS options against our actual framework and editorial requirements — and treat Enhavo as one candidate that must be assessed at the parent-project level, never through this split repository.

To engineering. Treat enhavo/page-bundle as an internal build artifact, not a library. Consume it only transitively via Enhavo, pin versions through the parent project's release, and file issues and patches upstream — anything opened against this repository is effectively lost. Do not infer versioning discipline, test coverage, or API stability from this repo; none of it is observable here. If content management lands on the roadmap, the two realistic paths are (a) run Enhavo as a separate Symfony content service behind a narrow JSON contract, with a Laravel-side client and aggressive caching so the CMS stays off the anonymous request path, or (b) reimplement the page model in Laravel — pages, slug history with redirects, published_at/expires_at scopes, polymorphic block storage, and Blade components per block type behind a Filament or Nova admin. Option (b) is typically a bounded two-to-six week effort and eliminates all cross-framework risk; option (a) buys feature depth at the cost of two runtimes, two deploy pipelines, two security-patch streams, and a hard dependency on upstream cadence.

The cheap next step. Before committing either way, spend a few days spiking against the main Enhavo repository to confirm feature coverage against our page and content requirements. That spike — not this bundle — is the actual decision input.