Filament Page Builder Laravel Package

Technical Evaluation

Architecture fit The package is a Filament-native visual page builder: pages are Eloquent models whose content is stored as a JSON array of typed "blocks," edited through a Filament resource and rendered through Blade components. That makes it a strong architectural fit only if the host application already runs Filament v3 as its admin layer — it reuses Filament form schemas, policies, and Livewire rendering rather than introducing a parallel admin stack. It is not headless, not API-first, and not framework-agnostic; it presumes server-rendered Blade output. Functionally it targets CMS-lite marketing/landing pages (hero, text, image, CTA, etc.), not editorial workflow-heavy content (no first-class revisions, scheduling, or granular editorial roles implied by the surface area).

Integration feasibility Install is a standard Composer + vendor:publish flow (config, migrations, views), followed by registering the Page resource and authoring block classes that pair a Filament form schema with a Blade view. A mid-level Laravel developer can render a first page in 1–2 days; a production-grade integration — block library, caching, preview, SEO fields, content migration — is realistically 2–4 weeks of engineering plus content work. The main integration decision is whether to adopt its pages table as the system of record or map it alongside an existing Page model; running both creates a dual-source-of-truth problem that is expensive to unwind.

Technical risk

• Vendor concentration: maintained by a single small agency (Sevendays Digital), 55 stars, 0 dependents, last release September 2024. There is no observable production track record in the ecosystem and no community fork momentum. Bus factor is effectively one.
• Free/Pro split: a commercial Pro tier exists, which creates a real risk that free-tier bugs and Filament compatibility fixes lag to protect paid differentiation. Budget for a license or a maintenance fork.
• Framework churn: Filament moves through major versions quickly (v3 → v4). The package is almost certainly constrained to Filament 3.x; a panel upgrade could strand it and force an in-house port.
• Schema drift: block payloads live as JSON in the database with no evident schema version. Renaming, removing, or restructuring a block type can throw render-time exceptions on already-published pages.
• Injection surface: HTML/rich-text blocks shift XSS and layout-sanitization responsibility onto the integrating team.

Key questions

1. Filament v4 support status and the vendor's stated compatibility policy/timeline?
2. Is the page JSON schema versioned, and are block migrations supported?
3. What is gated behind Pro, and what does it cost at our expected scale?
4. Draft/publish, revision history, preview, and scheduled publishing — in free, Pro, or absent?
5. Multi-language/translatable pages out of the box?
6. Rendering cost per request and recommended caching strategy?
7. Vendor support commitment, response expectations, and willingness to accept PRs or offer a maintenance agreement?
8. How are deleted/renamed block types handled at render time — hard failure or graceful fallback?

Integration Approach

Stack fit Best fit: Laravel 10/11, PHP 8.1+, Filament 3, Livewire 3, Blade + Tailwind front end. Poor fit if the front end is a separate SPA/Next.js consuming an API, if the admin is Nova/Backpack/custom, or if content must be delivered headlessly to multiple channels.

Migration path

1. Spike (2–3 days) on a branch: install, author 3–4 representative blocks mirroring the real design system, verify rendering, route binding, asset publishing, and Filament version constraints resolve cleanly.
2. Decide the content model before writing code: adopt its pages table as the single source for a defined content segment (e.g., campaign/landing pages) rather than duplicating an existing Page entity. Scope creep into "replace the whole CMS" is the primary failure mode here.
3. Content migration: script a conversion from existing Markdown/HTML/WYSIWYG into block JSON, retaining the raw source for rollback and diffing. Treat this as the largest and least predictable workstream.
4. Render and delivery wiring: catch-all or model-bound route, full-page or fragment caching keyed on page updated_at, draft/preview route behind auth.
5. Harden: HTML sanitization on rich-text blocks, a schema_version column added by us, fallback rendering for unknown block types, and feature tests around render output.

Compatibility Pin Filament to the exact minor version in use and lock it in CI. Validate Livewire and PHP versions against the package's composer constraints before committing. Confirm the Blade view namespace and any published assets survive vendor:publish --force cleanly on redeploy.

Sequencing Run the spike after any pending Filament major upgrade is settled — never immediately before one. Then: build the block library against the design system → migrate a pilot set of pages → add caching, preview, and SEO → roll out behind a feature flag for one content team → decommission the legacy path. Parallelize content migration with block development, not after it.

Operational Impact

Maintenance Low day-to-day surface area (one package, JSON-in-a-column storage, no external services), but a real upgrade treadmill: assume one compatibility fire drill per Filament major release. Keep the option of forking — MIT license makes that legally trivial and it should be priced into the decision as the de facto contingency plan. Internal ownership must be explicit; "the vendor maintains it" is not true at this scale.

Support Community GitHub issues only, no SLA, minimal Stack Overflow footprint, and 0 dependents means no peer implementations to consult. Expect to debug rendering and Filament-integration issues from source. Factor in a paid Pro license or a small internal support budget rather than assuming free-tier responsiveness.

Scaling Page rendering is cheap but not free: block views may hit the database, media, or third-party APIs per block, so full-page caching with tag-based invalidation on publish is effectively mandatory above modest traffic. Database rows grow with block count and embedded media metadata — store media by reference, not inline base64. Admin-side Livewire editing is fine at low editorial concurrency; concurrent editing of the same page has no evident locking, so assign page ownership by convention.

Failure modes

• Removed or renamed block type → uncaught render exception on a live page (highest-severity, most likely).
• Malformed JSON from manual DB edits or a failed save → broken page.
• Missing Blade view after a deploy that adds a block but not its template.
• Stale cache after publish without proper invalidation.
• Editor publishes a broken layout — no draft preview or layout guardrails out of the box.
• Package update drifts Tailwind/JS assets from the host app's build.

Ramp-up Developers: ~1–2 days to first page, ~1 week to internalize block-authoring conventions and rendering. Content editors: a 1-hour training plus a documented, constrained block library (max blocks per region, allowed nesting, image guidance). Without those guardrails, non-technical editors can produce visually broken pages that developers then police manually.

TPM recommendation Adopt for a Filament-based Laravel app that needs a bounded set of marketing/landing pages, contingent on a successful 3-day spike and a documented answer on Filament v4 support. Do not adopt as the core CMS for a long-lived, multi-editor, multi-channel product without either a Pro license evaluation or an explicit fork-and-own decision up front.