Weave Code
Page Bundle Laravel Package
enhavo/page-bundle
Enhavo Page Bundle is a subtree split of the Enhavo CMS, an open-source PHP content management system built on the Symfony framework. It provides page management functionality for building flexible content structures with a clean, usable interface. See the main repository for full documentation.
[READ-ONLY] EnhavoPageBundle
Frequently asked questions about Page Bundle
- Can I install enhavo/page-bundle in a Laravel application?
- No. This is a Symfony bundle that expects registration in config/bundles.php, compilation through Symfony's DI container, and Doctrine ORM/DBAL for persistence. Laravel service providers are not a substitute for bundle extension semantics, and the dependency graph collides with Eloquent, Blade, and Laravel's own pinned symfony/* constraints. Composer dependency-resolution failure should be treated as the expected outcome.
- What is enhavo/page-bundle and is it a standalone package?
- It is the page management foundation of the Enhavo CMS, an open-source PHP CMS built on the Symfony fullstack framework. The Composer package is an auto-generated subtree split of the main Enhavo monorepo, so its history and metadata are derived rather than independently maintained. The README explicitly points to the main repository for documentation.
- Which Symfony and PHP versions does Enhavo Page Bundle support?
- Version support is defined upstream in the main Enhavo repository and reflected in the split's composer.json, not in package-level documentation. Tags are released in lockstep with the monorepo, so pinning this package implicitly pins a large slice of Enhavo and its sibling bundles. Check the main repository for the current supported Symfony and PHP matrix before committing.
- What other packages does page-bundle need to actually render a routable page?
- The bundle is designed to sit alongside sibling Enhavo packages such as resource, routing, block, media, and admin, plus Doctrine, HttpKernel, Form, and Twig. Page entities, flexible content blocks, URL generation, and template rendering are spread across that set rather than contained in page-bundle alone. Confirm the minimum bundle set with a spike before estimating effort.
- How would I use Enhavo page management with Laravel?
- There are two realistic paths. Run Enhavo as a separate Symfony content service and expose pages to Laravel over JSON or a materialized read model, which isolates the framework mismatch behind a contract. Alternatively, treat the bundle as a design reference and reimplement its Page model, slug routing, draft and scheduled publication, and block composition natively in Laravel.
- Where do I report bugs or contribute fixes to Enhavo Page Bundle?
- Issues, pull requests, and release notes are handled in the main enhavo/enhavo repository; the split repository is explicitly read-only. Anything filed against the split is effectively lost. If you need a patch, target upstream and expect it to flow down to this package on the next split.
- Does the page bundle support drafts, scheduled publication, and slug-based routing?
- Yes, the bundle provides templated pages, slug routing and URL generation, draft and scheduled publication states, and composable content blocks. The exact API surface has to be inferred from source and the main repository documentation, since package-level docs are minimal. Verify each feature against the version you intend to use.
- Why does composer require fail when I add this to a Laravel project?
- Laravel pins its own versions of symfony/* components, while Enhavo requires a full Symfony kernel plus Doctrine, Twig, Form, and multiple enhavo/* packages. Composer will frequently find no satisfiable dependency set, and forcing resolution leaves two frameworks with overlapping ownership of routing, sessions, security, and caching. A kernel shim is a non-starter without a formal spike.
- What are the alternatives for page management if my application is Laravel-only?
- If the target stack is Laravel-only, this package is out of scope and the decision shifts to a Laravel-native option. Common directions are a flat-file or database-backed CMS such as Statamic, a headless CMS consumed over API, or a bespoke page module modeled on Enhavo's concepts. Each keeps a single runtime and a single schema owner.
- Is this subtree split safe to depend on in production?
- Treat it with caution. The split shows no independent adoption signal, has no separate community to catch regressions, and its maturity is essentially a readme, so the API surface must be read from source. Production use is defensible only inside an existing Enhavo Symfony estate where upgrades are owned and the release cadence is tracked upstream.
Weaver
How can I help you explore Laravel packages today?