Unlayer Filament Laravel Package

Technical Evaluation

Package: community-sdks/unlayer-filament — v1.0.0 (first tagged stable release) What it appears to be: a Filament plugin that embeds the Unlayer drag-and-drop email/page builder as a Filament form field (Livewire + Alpine + Unlayer JS SDK), persisting the design payload for a Laravel application.

Confidence caveat: the v1.0.0 release notes contain only a Full Changelog URL and no changelog body. Everything below is inferred from the package name, namespace, and Filament conventions. Treat the technical risk rating as provisional until the README, composer.json, and CI status are reviewed. Do not approve adoption on the strength of these release notes alone.

Architecture fit

• Fits naturally into a TALL-stack Laravel app already running Filament. The plugin should register via a Plugin/FilamentPlugin contract in a PanelProvider and expose a field class usable inside any form schema — low architectural intrusion.
• The heavy lifting (editor UI, HTML export) happens client-side in the browser. The Laravel side is essentially a config + asset-registration + persistence shim. That is the right boundary: it keeps PHP dependencies minimal and avoids server-side rendering costs.
• Assumption to validate: the package stores design JSON and does not server-side export HTML. Most such wrappers rely on Unlayer's JS exportHtml() callback or the paid Export API. If our app needs HTML for mailables, we own that export step.
• Coupling is to two external contracts: Filament's major version and Unlayer's JS SDK/CDN. Both are third-party release trains we do not control.

Integration feasibility

• Expected path: composer require community-sdks/unlayer-filament, register the plugin on the panel, optionally vendor:publish config/assets, add an env-backed Unlayer project/API key, add the field to a resource form. Realistically a half-day spike for a developer already fluent in Filament.
• Requires a commercial Unlayer account for production use (project ID, feature gating, and any hosted-export usage). That is a procurement item, not just a technical one.
• Unverified: Filament v3 vs v4 support, Livewire 3 compatibility, whether assets are published or CDN-loaded, and whether the field supports both create and edit hydration of existing designs.

Technical risk

Key questions to close before approval

1. Which Filament and Livewire major versions are supported (composer.json constraints)?
2. Does the field expose Unlayer's exportHtml() output, or JSON only? Is the paid Export API required?
3. Where is the Unlayer project/API key read from — config, env, per-tenant?
4. Is the editor script published locally or loaded from Unlayer's CDN?
5. Test coverage and CI status; is there a demo app?
6. License terms and whether the org is accepting maintainers.
7. Is the stored design a documented, stable schema we can migrate later?

Verdict: technically plausible and low-effort to pilot, but information-insufficient for production commitment. Approve a timeboxed spike only.

Integration Approach

Stack fit

• Target: Laravel 11/12, PHP 8.2+, Filament v3+ (confirm v4), Livewire 3, Alpine (bundled with Filament). No Node build step expected on our side — asset registration should be handled by the plugin's service provider.
• Persistence shape we should standardise regardless of the plugin's defaults:
  • design_json — LONGTEXT (or JSON on MySQL 8/Postgres) for the Unlayer design
  • html — LONGTEXT, nullable, populated on save
  • plain_text — nullable, derived
  • design_version / editor_version — small ints, cheap insurance for future migrations
• Keep the Unlayer field behind our own Blade/form abstraction (a thin wrapper component) so swapping the plugin does not ripple through every resource.

Migration path

• Greenfield (recommended first target): one net-new template type, one resource, one audience. No legacy content to convert.
• Brownfield: existing HTML/Blade email templates cannot be auto-imported into Unlayer's format. Migration means re-authoring in the editor or using Unlayer's "Custom Design JSON" import, which is a content-team effort, not a dev task. Budget content ops accordingly and keep a read-only HTML fallback for legacy templates.
• Feature-flag the new field per resource; do not globally replace existing editors in one release.

Compatibility & sequencing

1. Discovery (1–2 days): read README, composer.json, open issues, CI badge; confirm Filament version and Unlayer account tier; confirm CSP allowance for Unlayer domains in staging.
2. Spike (2–3 days, non-prod): install in a scratch Filament panel, create/save/reload a design, verify HTML export path, verify large-payload save (500 KB+ design JSON), verify behaviour on Livewire re-render and validation failure.
3. Pilot (1 sprint): one resource, one template type, behind a permission gate; add our own save/export tests and a JSON-schema check on read.
4. Rollout: expand resource coverage; publish an internal usage note; add a Dependabot/Renovate rule pinned to the plugin and watch Filament majors.
5. Pin the composer constraint to ^1.0 and record the exact installed version in the ADR; require an explicit review before any 2.0.

Operational Impact

Maintenance

• Low code surface but two upgrade clocks to track: Filament majors and Unlayer SDK/API. Assign a named owner; a stale wrapper on an old Filament major becomes an upgrade blocker for the whole admin panel.
• Watch the repository's release cadence over the next two quarters. A v1.0.0 with no subsequent activity is a signal to plan an in-house fork (small surface — a fork is genuinely viable here).

Support

• No vendor SLA for the plugin; Unlayer provides support for the editor itself under the commercial plan. Escalation paths split across two vendors plus ourselves — document which layer owns which failure.
• Budget for internal first-line support: content editors will report "the editor is blank" far more often than developers will see a stack trace.

Scaling

• Editor rendering is browser-side; server cost is storage and bandwidth only. Design JSON is heavy — assume 100 KB–1 MB per document. Size the DB column and backups accordingly; avoid selecting design_json in list queries.
• If we need HTML for outbound mail, generate and cache it at save time rather than on every send. Push heavy or bulk re-export jobs to the queue.
• Asset delivery from Unlayer's CDN keeps our app servers light; the trade-off is an external dependency in the admin critical path.

Failure modes

Ramp-up

• Developers familiar with Filament: ~half a day to first working field; ~2 days to production-ready with tests and validation.
• Content editors: 1–2 hours of Unlayer UX training plus a short internal style guide (brand colours, saved rows, merge-tag conventions) — this is where most of the real adoption friction sits, not in the code.
• Ops/on-call: brief runbook covering "editor won't load" triage (CSP → CDN → API key → plugin asset registration) and the HTML-export fallback procedure.
• Document the export pipeline explicitly: who runs it, when, and what happens to templates already sent.