Page Layout Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for page composition. This package pre-answers the "can we build a drag-and-drop page builder?" question: yes, and the layout half is commodity work. The roadmap conversation should shift to what content model sits behind the layout — blocks, revisions, scheduling, localization — because that is the non-commodity 80%.
• Scope-splitting: layout vs. content. The genuinely reusable idea is separating layout (rows, columns, widget positions persisted as structured JSON) from content (what each block renders). Adopt that split even if we never touch the code; it keeps CMS/block-rendering work independent of the editor UI and lets either side be replaced later.
• Ecosystem-fit finding that changes the plan. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle built for Sonata Admin — no Laravel service provider, config, or Blade integration. For a Laravel product the real decision is "do we port the concept?" not "do we install it?" Settle that before anyone estimates engineering effort.
• Surface routing. Gridstack-style free-form positioning fits back-office/admin surfaces and staff-assembled marketing pages. It is a poor fit where responsive reflow, accessibility, or SEO-critical markup are acceptance criteria. Route those requirements to a constrained section/template picker instead.
• Roadmap sizing signal. Five stars and zero dependents mean this is a reference implementation, not an ecosystem bet. Fund it as a 1–2 day spike to mine the JSON layout schema and editor UX — never as a release-plan line item.

When to Consider This Package

Consider it only when all of these hold:

• The stack is Symfony with Sonata Admin already in production — the bundle's only real value is that it plugs into an admin you already run.
• You need an admin-facing drag-and-drop layout composer for a bounded internal audience (staff, ops, marketing).
• You are prepared to vendor or fork the code. With 5 stars and 0 dependents, treat it as source you own, not a dependency you upgrade. Budget to pin the version and read the source before shipping.
• Bootstrap grid markup is an acceptable output contract — your front end renders Bootstrap rows/columns and isn't locked to another design system.
• Layouts persist as a JSON blob your own renderer consumes, keeping exit cost low if you replace the editor later.

Look elsewhere when:

• You are on Laravel. There is no adapter here. A Filament/Nova field wrapping gridstack.js directly, or a block-based content package, is cheaper than maintaining a Symfony-to-Laravel port.
• You need a maintained dependency with a support path, changelog cadence, or security responsiveness. Zero dependents is a warning: nobody has hit the edge cases, and there is no bug trail to read.
• Content modelling is the actual hard problem. This package addresses layout only — not blocks, revisions, scheduling, or localization. If those are in scope, the editor is the easy 20%.
• Accessibility, mobile reflow, or Core Web Vitals are acceptance criteria. Free-form grids create markup order and responsive behaviour you will fight; a predefined section/template picker outperforms on every one of those metrics.
• Layouts are developer-authored, not editor-authored. If templates change per release rather than per campaign, a fixed set of Blade/Twig partials is simpler and cheaper.

How to Pitch It (Stakeholders)

For executives: A small open-source component providing a drag-and-drop page-builder UI for Symfony/Sonata admin panels. It is not adoptable as-is on our stack — it is a validated pattern and a possible two-day spike. Its strategic value is de-risking the "marketing builds pages without engineering" roadmap item: it demonstrates the layout editor is commodity work, so we should scope and staff the content model, not the drag-and-drop. Evaluation cost is negligible; adoption cost is real — single maintainer, essentially no user base. If we use any of it, we fork it and own it.

For engineering: Symfony/Sonata bundle, MIT licensed, gridstack.js over a Bootstrap grid, layout persisted as JSON. No Laravel integration — porting means wrapping gridstack.js ourselves in a Filament/Nova field: days, not weeks. Recommendation: read the source for the JSON layout schema and editor UX; do not add it to composer.json. Assume unmaintained, pin or vendor. Flag the responsive/accessibility limits of free-form grids early — that is where the real cost lands, not in the editor itself.

Bottom line: Evaluate as a reference, not a purchase. The idea is worth a spike; the package is not worth a dependency.