Weave Code
Nova Unlayer Field Laravel Package
interaction-design-foundation/nova-unlayer-field
A Laravel Nova field that embeds the Unlayer drag-and-drop editor, letting you design and edit email or page templates directly inside Nova resources and save the generated HTML and JSON.
A Laravel Nova field for Unlayer to compose emails and landing pages.
Frequently asked questions about Nova Unlayer Field
- How do I install the Nova Unlayer field in my Laravel app?
- Install it with Composer using interaction-design-foundation/nova-unlayer-field, then register the field class inside the fields method of the Nova resource that should hold your email or page content. You will typically add migration columns for the stored HTML and design JSON, and publish or add the package config that holds your Unlayer project details. Check the README for the exact field class name and config keys, since the package surface is small but version-specific.
- Which Laravel Nova and PHP versions does this Unlayer field support?
- The package is a thin Nova field plus a Vue component, so the deciding factor is Nova's frontend stack: Nova 1 through 3 run Vue 2, while Nova 4 and later moved to Vue 3. Verify the composer.json constraints and the actual release tags in the repository before assuming compatibility, because the published release date looks anomalous and the project has a single-org maintainer. Install it in a staging Nova app first to confirm the component renders and saves correctly on your Nova major.
- Do I need a paid Unlayer plan to use this Nova field?
- Yes, in practice you need an Unlayer plan, because the field only embeds Unlayer's hosted editor and does not bundle an editor of its own. Free tiers typically add watermarking and limit export or API access, so production email authoring usually requires a paid plan for watermark removal, export quotas, custom fonts, and data residency or DPA terms. Treat the Unlayer subscription, key ownership, and offboarding path as procurement items separate from the Composer package.
- What does the field actually store in the database?
- The field is designed to persist two artifacts: the rendered HTML that eventually reaches the inbox, and the editable design JSON that lets you reopen the design later. You should also add a schema_version column so old content still re-renders correctly after an Unlayer editor or SDK change. Keeping both copies in your own database is what makes vendor lock-in reversible, so avoid relying on Unlayer's cloud as the only source of truth.
- Can this package send emails or publish landing pages, or is it composition only?
- It is composition only. The field gives you a drag-and-drop authoring surface inside Nova and saves the generated HTML and JSON, but it deliberately does not handle sending, landing page hosting, publishing, tracking pixels, link rewriting, unsubscribe handling, or bounce processing. Those pieces need a named owner in your application or ESP before you go live with content teams.
- How do I render the saved Unlayer HTML in a Laravel Mailable?
- Read the stored HTML from your model and pass it into the Mailable, either through a Blade view that echoes it or by calling html() on the Mailable's content. Do the rendering on a queued job rather than synchronously on save if the design is large or you need to post-process links and tracking parameters. Because editor preview and inbox rendering differ, run the output through your own sanitization and link-rewriting pipeline rather than trusting the raw editor HTML.
- Is it safe to embed the Unlayer editor inside the Nova admin panel?
- Unlayer loads third-party scripts and iframes from its own CDN inside an authenticated admin surface, so security review should happen before content teams depend on it. You will likely need Content-Security-Policy directives that allowlist the Unlayer domains, plus iframe sandboxing and a check that the editor cannot be reached by unprivileged Nova users. Also assign an owner for HTML sanitization and link handling, since those gaps surface as production incidents rather than tickets.
- Where should the Unlayer API key and project configuration live?
- Keep the key out of the repository and read it from an environment variable, exposing it through a config file or config/services.php entry that the field and your frontend component can consume. Decide up front who owns the Unlayer account and the key, and document the offboarding path if you ever drop the vendor. Rotating the key should not require a code change, so avoid hardcoding it in the Vue component or Nova resource.
- Is this package production-ready and actively maintained?
- Treat it as adopt-with-a-fork-option. The code surface is small, MIT licensed, and realistically a day or two to integrate, but adoption signals are weak: roughly 34 stars, zero dependents, single-org maintenance, and a release date that reads as anomalous. Pin a specific tag, verify against tags rather than the displayed date, and budget for the surrounding work such as sanitization, permissions, preview, and the delivery handoff, which is one to two sprints rather than a demo.
- What are the alternatives if I don't want to depend on Unlayer or this Nova field?
- You can embed the Unlayer SDK yourself with a custom Vue component, which is essentially what this package already does and gives you full control over upgrades. Other options include open-source editors such as GrapesJS, a plain HTML or Markdown field in Nova, or composing in a mature ESP editor like Braze, Customer.io, or Mailchimp if authoring already lives there. If your team is not already on Nova, buying a Nova license just for this field is hard to justify, and duplicating an existing ESP editor is usually unnecessary tooling.
Weaver
How can I help you explore Laravel packages today?