Laravel Nova Visual Composer Laravel Package

Product Decisions This Supports

• Content-modeling decision: Should page and section content be authored as discrete, reusable blocks stored as structured JSON on an Eloquent model — instead of freeform HTML or a single rich-text field? This package makes that model tangible enough to put in front of real editors in about a week, which is the cheapest way to find out whether your content team actually thinks in blocks.
• Build vs. adopt vs. buy: The realistic three-way call is (a) use this Nova field as a short-term accelerator for an internal block editor, (b) build a custom Nova field in-house, or (c) buy a dedicated CMS/page-builder product. With 14 stars, zero dependents, and a last release of July 2022, this is a reference implementation and spike candidate — not a platform dependency. Note that it does not change the buy calculation much; it mostly de-risks the build path by proving the content model first.
• Roadmap scoping for bounded composition: Informs MVP and internal-tool calls for landing-page sections, help-center modules, marketing pages, and reusable content blocks — admin-side composition by staff, not a customer-facing drag-and-drop builder. Scoping the roadmap around "who authors, and how often" is the deciding question.
• Admin-tooling investment: Forces the call on whether block authoring belongs in the Nova admin workflow at all, or needs its own surface (previews, scheduling, localization, multi-tenant access). Being bound to a Nova field is the constraint that surfaces this early rather than in month three.
• MVP validation of the block contract: The config-declared block registry — key, label, editor component, and the Nova fields inside each block — is the content model. Prototyping three or four block types end to end (save in Nova, render in Blade, inspect the payload) lets product confirm the authoring model before committing engineering to a custom field or budget to a commercial page builder.
• Ownership and maintenance planning: Any adoption immediately triggers a fork/vendor decision, a version-pinning plan, a named internal owner, and a recurring budget — roughly one day to internalize the field class, Vue component, and config, plus ~2–3 days per quarter and a defined task in every Nova/Laravel major upgrade. Because the block schema lives in your JSON, schema governance, backfills, and unknown-block handling are yours regardless of who maintains the code.
• Explicit buy-vs-build boundary: Useful as a seed implementation, not a strategic page-builder investment. It does not stand in for a maintained CMS where previews, versioning, scheduling, localization, accessibility guarantees, or multi-tenant authoring are requirements.

When to Consider This Package

Consider it when all of the following hold:

• You are already standardized on Laravel Nova with a commercial license, and your stack matches the era it targets (Laravel 8/9, PHP 8.0/8.1, Nova 3/4). Confirm this with a composer require --dry-run on a throwaway branch before anything else — and check whether the field component targets Vue 2 (Nova 3) or Vue 3 (Nova 4+), because that single detail determines whether the field renders at all.
• The requirement is an internal authoring workflow for bounded structured content — reusable sections, landing pages, help-center modules — not a polished builder for external customers.
• Your team can fork, vendor, patch, and test the package, and can pin compatible Laravel/Nova/PHP versions. Internalizing the field class, Vue component, and config into your own namespace takes about a day and removes most of the abandonment risk.
• You need to validate a block-based content model quickly — one resource, two block types, round-tripped end to end — before investing in a custom field or a full CMS.
• You accept schema ownership: freezing the payload shape as yours, adding a schema_version key from day one, validating on save, and skipping unknown block types on render rather than throwing.
• You can fund the surrounding operational safety: a revisions table or column backups, a decode guard for malformed JSON, a vendor:publish step documented next to migrate in the deploy runbook, and a staging check on every Nova upgrade. A field that fails to hydrate can silently save an empty payload over live content.

Look elsewhere if you need active maintenance or modern compatibility guarantees (Laravel 11/12 + Nova 5); a non-Nova or API-first content service; customer-facing drag-and-drop layout editing; previews, versioning, scheduling, localization workflows, accessibility guarantees, or multi-tenant authoring; per-block conditional fields or custom validation UX beyond what Nova fields provide (that is a Vue fork, not a config change); or if nobody on the team can own a fork — with zero dependents and a single small-agency maintainer, nobody else will file the bug you hit, and Nova support will not touch third-party fields.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, time-boxed experiment, not a platform bet. For roughly one week of engineering we can stand up a working block editor inside the admin and put it in front of the content team, which tells us whether block-based authoring is the right model before we commit to a custom build or a CMS license. The package itself is unmaintained (last release 2022, 14 stars, no dependents), so we would not run it as a dependency — we would absorb roughly a day of code into our own namespace and own it. That caps the downside: the experiment is cheap, reversible, and produces a reusable content contract either way.

For engineering: Treat it as a reference implementation. Vendoring the field class, Vue component, and config is about a day; pin the versions and own them. Before promising anything, resolve the install on a branch and confirm the field targets your Nova/Vue version. Budget for the work the package does not do: a renderer we write ourselves (with a View::exists() guard so removed block types degrade to a cosmetic gap instead of a 500), save-time validation rejecting unknown types while render skips them, a schema_version on every document, a block-count cap, a decode guard plus a repair command, and a revisions/backup path against silent overwrite. Publish assets in the deploy runbook and smoke-test the resource edit page after deploy.

For content and design: Editors get drag-and-drop ordering, nested layout, and a reusable block library without touching code, and content is stored as portable structured JSON rather than locked-in HTML. Set expectations now on what is not included: no localization out of the box (plan a per-locale column before writing blocks, not after), and no built-in previewing or scheduling unless we build it. The upside is that the block library is a product artifact we control — adding a block is a config change and a Blade partial, not a new page type.