Basic Page Bundle Laravel Package

Product Decisions This Supports

The first decision it forces: it isn't a Laravel package. Despite the framing, runroom-packages/basic-page-bundle is a Symfony bundle built for Sonata Admin. If our stack is Laravel, this is a non-starter and the evaluation ends here — the equivalent decision is Filament/Statamic/Novaa plus a Page model, which is a few hours of work. Treat the rest of this assessment as conditional on a Symfony + Sonata codebase.

Assuming that condition holds, it informs:

• Build vs. buy for "basic pages." Every content-driven product eventually needs editorial pages — About, FAQ, Terms, landing pages — with slug, title, body, SEO metadata, and publish/unpublish. This bundle is a packaged answer to that exact primitive. The real comparison isn't "adopt vs. not," it's "adopt vs. copy the pattern into our own Page entity in half a day."
• CMS admin standardization. Adopting it implies committing to Sonata Admin as the back-office foundation. That's a much larger architectural decision than the bundle itself, and the bundle's value depends entirely on Sonata already being present or planned.
• Roadmap scoping for marketing/brochureware surfaces. If the roadmap includes content marketing pages, this shortens the scaffolding phase — days, not weeks — but does not give us a page builder, blocks, revisions, workflow, or multi-site.
• Dependency policy precedent. It is a READ-ONLY subtree split of the Runroom monorepo. Pulling it in means accepting that issues and PRs live elsewhere and that release cadence is tied to someone else's monorepo. That's a governance precedent worth deciding deliberately, not by accident.
• Not supported: headless/API-first delivery, Laravel or non-Symfony stacks, localization depth beyond what the entity exposes, or anything requiring an SLA.

When to Consider This Package

Consider it only when all of the following are true:

• We are on Symfony with Sonata Admin and Doctrine ORM already in production — the marginal cost of a page entity is genuinely near zero.
• We need the plainest version of editorial pages and are comfortable extending the entity ourselves.
• We are willing to fork or vendor the code. At 1 star and 0 dependents there is no external validation and no meaningful community, so the fork plan is not optional insurance — it's the operating model.
• We have verified compatibility against our Symfony/PHP versions from composer.json rather than the README. Documentation and support are effectively "read the source."

Look elsewhere when:

• The stack is Laravel or anything non-Symfony. Wrong tool, full stop.
• We need an actively supported dependency, security responsiveness, or a vendor relationship. One star and zero dependents means the bus factor is one agency's internal priorities, and the split repo is a publication artifact, not a maintained product.
• The requirement is really a content platform — blocks, revisions, scheduling, multi-site, translations, editorial workflow. This bundle is a page entity, not a CMS, and stretching it will cost more than buying or building properly.
• We need API/headless delivery, or the back office is not Sonata.

Neutral read on the weak signals: Runroom is an established Symfony/Drupal agency, and a read-only split with no stars is the normal shape of an internally used package that was never marketed. The low score reflects discoverability and community, not necessarily code quality. But "probably fine for them" is not the same as "safe for us," and with zero dependents we have no third-party evidence either way.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Symfony component that provides a ready-made "basic page" content type for the Sonata back office. The upside is speed — it removes maybe a few days of scaffolding on content-heavy sites. The downside is structural: it has essentially no community, no support channel, and is published read-only from another company's monorepo. My recommendation is not to adopt it as a production dependency for anything strategic. Use it as a reference implementation: read it, copy the patterns into code we own, and move on. The cost of doing that is trivial; the cost of inheriting an unmaintained dependency in our CMS layer is not.

To engineering: Low-risk to evaluate, low-value to depend on. If Sonata is already our back office, vendor it or fork it under our namespace and pin the version — do not point production at a read-only split and expect to file fixes upstream. Treat the entity as a starting point, not a contract; expect to add SEO fields, workflow, and localization ourselves. If we're not on Sonata, skip it entirely — the Laravel equivalent is an afternoon with Filament or a hand-rolled model, and we'd own it outright.

Decision requested: Approve pattern reuse, not dependency adoption. If a team wants to formally adopt it, they should come back with the Sonata commitment, the fork ownership plan, and the version-pinning approach.