Nova Page Builder Field Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for visual page editing. The package is essentially a thin Laravel Nova field that embeds GrapesJS inside the admin panel. That framing is the actual decision: you are really evaluating "adopt a maintained GrapesJS integration" vs. "wrap GrapesJS ourselves" vs. "buy a headless CMS / page-builder SaaS." This package is useful as a reference implementation and effort benchmark for the "wrap it ourselves" option, not necessarily as a dependency.
• CMS-lite roadmap scoping. If your roadmap includes letting marketing ops, content editors, or internal admins compose landing pages, email bodies, or content blocks without engineering involvement, this package defines a plausible MVP surface: a JSON/HTML blob persisted on a model, edited through a drag-and-drop canvas in Nova.
• Admin tooling consolidation. Supports the decision of whether page composition lives inside the existing Nova admin (one login, one permission model, one deploy) versus standing up a separate CMS. The package's core value proposition is exactly this consolidation, and it's worth pricing against the operational cost of a second system.
• Effort/estimate calibration. 31 stars and a last release in January 2019 tells you the integration layer is roughly a few hundred lines of glue. That's a useful data point for estimating an in-house spike (typically days, not weeks) and for deciding whether maintaining a fork is cheaper than licensing a commercial builder.
• Risk triage and dependency policy. A clear input for "do we allow abandoned packages in the dependency tree?" — relevant if you have a policy on maintenance status, security disclosure paths, or Nova major-version upgrade cadence.
• Prototype/demo decisions. Good fit for a time-boxed spike to validate whether editors actually adopt a freeform canvas, before committing budget to a supported solution.

When to Consider This Package

Consider it when:

• You are already on Laravel Nova (verify version compatibility explicitly — the last release predates multiple Nova majors, so expect it to require patching or a fork) and want a fast spike, not a production commitment.
• The content surface is low-stakes and internal: marketing landing pages, internal announcements, prototype screens. Not customer-facing flows, checkout, or anything with a compliance boundary.
• You are comfortable vendoring or forking the field. Budget for taking ownership: pin it, read the source, and plan to maintain it yourself.
• Your editors are trusted staff. GrapesJS produces arbitrary HTML; if untrusted users ever touch the canvas, you own sanitization, CSP, and XSS review — the package does not solve that for you.
• You need a proof of concept in days to test editor adoption and workflow before buying a commercial builder.

Look elsewhere when:

• You need supported software: SLAs, security patches, or a vendor you can escalate to. A 2019 last-release with ~31 stars and a single maintainer is a maintenance liability, not a dependency.
• You are on current Nova/Laravel versions and cannot absorb the upgrade/patch work — verify before promising a date.
• You need accessibility-compliant output, RTL/localization, design-system-constrained components, or brand-governed templates. Freeform canvas builders generally fight these requirements; a structured block/section editor or a headless CMS is usually the better product answer.
• You need multi-tenant isolation, revision history, draft/publish workflows, or content approval — this field gives you an editing surface, not a content lifecycle.
• Your real requirement is structured content modeling rather than freeform HTML; GrapesJS-shaped output (HTML blobs) is hard to query, migrate, and re-render across channels.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small open-source add-on that puts a drag-and-drop page designer inside our existing Laravel admin, so content editors could build pages without engineering time. The strategic appeal is consolidation — no second CMS, no second login, no second vendor contract. The caveat is equally simple: it hasn't been released since early 2019 and has a tiny user base, so it is not something we can depend on as-is. Recommendation: treat it as a low-cost, time-boxed spike (roughly a few days of engineering) to validate whether our editors actually want a freeform canvas. If they do, we make a deliberate build-vs-buy call — either we own a small internal wrapper around the actively maintained GrapesJS library, or we budget for a supported commercial builder. If they don't, we've spent days rather than a quarter.

To engineering (summary): It's a Nova field that mounts GrapesJS and persists the canvas output against an Eloquent model. The integration layer is thin — the real dependency is GrapesJS, which is actively maintained — so the realistic options are (a) fork and pin this field, owning the Nova-version compatibility and the GrapesJS upgrade path, or (b) reimplement the ~few-hundred-line glue in-house against a current Nova release. Either way, scope explicitly for: sanitizing stored HTML on render, CSP implications of user-authored markup, asset/media handling, and a schema for the stored payload so we aren't locked into an opaque HTML blob. Do not add it as a transitive dependency without a named owner.