- Is rmzamora/page-bundle actually a Laravel package?
- No. Despite how it is listed on Composer, the repository is a fork of the Symfony SonataPageBundle, so it ships as a Symfony bundle rather than a Laravel package. It has no Laravel service provider, facade, config publish command, or bundle loader that a Laravel application could consume. Treat any Laravel framing of this package as inaccurate and verify the source yourself before adding it to composer.json.
- Can I install this package inside a Laravel application?
- There is no practical integration path. Sonata's page layer is tightly coupled to Symfony bundle registration, service container tagging, Doctrine ORM entities and repositories, the Symfony event dispatcher, Twig, KnpMenu, and the Sonata Admin and Block stack. None of those map onto Laravel's Eloquent models, Blade views, or container conventions. Trying to bridge them would mean reimplementing the bundle, at which point you should build a Laravel-native solution instead.
- Which Laravel and PHP versions does it support?
- There is no Laravel version support at all, because there is no Laravel integration. The dependency graph targets Symfony 2 and 3-era components and likely pins PHP and Doctrine versions that are already end-of-life or close to it. Before considering it anywhere, resolve the full constraint matrix in a throwaway sandbox and check every transitive package's support status.
- How would I install it with Composer?
- The fork has no Packagist metadata, no signed tags, and only mutable branch references, so you would have to add a VCS repository entry pointing at a personal GitHub remote. That means no release provenance and no reproducible installs across environments. For a Laravel project this is effectively a supply-chain risk with no corresponding benefit.
- What does this fork change compared to sonata-project/page-bundle?
- That is undocumented. The fork has zero stars and zero dependents, and no published diff or changelog explains what it adds over upstream. Before trusting it, compare git log and git diff against the upstream branch point to isolate bespoke commits and determine whether any of them are load-bearing for your requirement.
- What should I use in Laravel instead for CMS-style pages?
- Model pages as Eloquent entities with slug, parent_id or tree path, published_at, and version columns, render them through Blade, and manage them with Filament or Nova. If editors need richer authoring, front a headless CMS over HTTP and cache the responses. Both routes are maintained, testable, and avoid adopting an abandoned Symfony admin surface.
- Is it safe to run in production?
- The risk is high on every axis. You would be exposing an unpatched CMS admin surface covering page editing, uploads, block rendering, and rich text, with no CVE response path and no maintainer committed to fixes. Combined with an unpinned personal fork and no release provenance, adopting it means your team becomes the sole maintainer by default.
- Can I run it alongside sonata-project/page-bundle?
- Do not. Bundles from that generation share service IDs and PHP namespaces, so installing both in one Symfony application risks collisions and unpredictable container behavior. Pick one: the maintained upstream Sonata bundle if you are on Symfony, or nothing at all if you are on Laravel.
- How should I evaluate or test this package before adopting it?
- Spin up a disposable sandbox and resolve the complete matrix: PHP version, Symfony minor, Doctrine DBAL and ORM, Twig, KnpMenu, and the Sonata Admin and Block versions the fork requires. Expect friction from abandoned transitive dependencies and record exactly what resolves. In a Laravel target there is nothing meaningful to test, because the bundle will never boot.
- What is the migration path if we already depend on it?
- Work upstream-first. Identify the upstream commit the fork branched from, diff fork against upstream to isolate custom commits, then reproduce the required behavior on a maintained upstream release. If that fails, internalize the code into a repository your organization controls with CI, static analysis, dependency pinning, and a tagging policy, and never point production at the personal GitHub remote.