Nova Froala Field Laravel Package

Product Decisions This Supports

• Whether to enable self-serve rich-text authoring in the admin panel. This package answers a concrete product question: can marketing, support, or ops staff create formatted content — headings, lists, links, images — without an engineer shipping HTML by hand? For an existing Laravel Nova back office, it is a same-day wiring job: one field class, one longText column, plain HTML out.
• Build vs. buy for editor UX. Rich text is expensive to build properly: toolbar behavior, paste-from-Word handling, image uploads, localization, sanitization, and accessibility. This package is a “buy” shortcut for Nova-based internal tools. It belongs on the comparison sheet next to TipTap, CKEditor 5, Quill, and Nova’s native Markdown/Textarea fields — with the explicit caveat that it buys you integration, not a supported editor product.
• Editor licensing and procurement. The wrapper is MIT, but Froala itself is commercial and licensed by domain. Adopting this package forces a real procurement decision: license cost across dev/staging/prod, renewal ownership, and legal review. The MIT badge covers only the Nova bridge — not the editor — and that distinction must be surfaced before budget approval.
• Admin roadmap sequencing and platform choice. Because the package is pinned to Nova 3.x / Vue 2 and has been archived since January 2021, it directly informs whether rich-text authoring is a phase-one admin capability or a post-launch enhancement — and whether Nova remains the back-office platform. If a Nova 4/5 upgrade is on the roadmap, this dependency is a dead end; the decision becomes “replace,” not “adopt.”
• Dependency-investment policy for internal tooling. Archived, 113 stars, zero dependents, no releases since 2021, no maintained fork. It is a useful case study for the recurring PM question: how much do we invest in unmaintained third-party admin-field dependencies, who owns them when they rot, and what are the exit criteria?
• Content risk posture. The editor emits raw HTML, which is untrusted input to every downstream renderer. Choosing this package implies a companion decision about sanitization at the write boundary, upload validation, and whether the authoring surface stays internal/low-exposure or flows into public-facing or compliance-sensitive pages. If content crosses that line, the correct move is to replace the editor, not harden the wrapper.

When to Consider This Package

Consider it only when all of the following are true:

• You are already on Laravel Nova 3.x / Laravel 7–8 / PHP 7.4–8.0 / Vue 2, and a Nova 4+ upgrade is not scheduled or is far enough out that a tactical dependency is acceptable.
• The authoring surface is internal, low-exposure admin tooling — not public-facing pages, regulated content, or anything where a sanitization failure or editor CVE becomes a compliance event.
• You need basic rich-text formatting fast and can accept a pinned, archived editor build. The integration is per-field fluent options; there is no service provider, config file, migration, or maintained upgrade path.
• You have budget and ownership for a Froala commercial license keyed by domain, and legal/procurement can approve it before production.
• You can sanitize at the write boundary (e.g., mews/purifier in a model mutator or observer), validate uploads with your own endpoint, and enforce column-size rules (TEXT vs LONGTEXT, max:65535, etc.).
• You can pin laravel/nova, the Froala package, PHP, and Laravel minors, assign a named owner, and define an explicit re-evaluation trigger — next Nova upgrade, Froala CVE, or replacement date.
• You have a fallback and exit plan: subclass the field once (e.g., App\Nova\Fields\RichText) so swapping editors later is a UI change, keep content as plain HTML in a longText column, and feature-flag the field with a native Textarea fallback.

Look elsewhere — or do not adopt — when:

• You are on Nova 4+. Nova 4 moved to Vue 3 and reworked field asset registration; a 2021 Vue 2 component will not mount, and there is no maintained fork.
• Content flows to public-facing, customer-visible, or compliance-sensitive surfaces. The bundled Froala JS is pinned to a 2021 build with older-editor XSS/sanitization advisories; there is no patch path for the wrapper.
• You need maintained security updates, vendor support, or a support contract. A paid Froala plan supports the editor, not this Nova integration; the field itself has no support contract and no upstream compatibility work happening.
• You need custom editor behavior expressed as JavaScript callbacks (events, custom upload handlers, dynamic params). ->options([...]) is serialized to JSON, so JS functions do not survive the wire; you would be forking the Vue component.
• You cannot fund a commercial Froala license, or legal cannot accept an archived dependency with a commercial editor embedded.
• Rich text is a core product differentiator rather than an admin convenience. In that case, choose a maintained editor and budget the frontend work properly.
• You need modern accessibility, active localization, or long-term framework compatibility. This package is a 2021 snapshot, not a platform bet.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, fast-to-wire rich-text field for existing Nova 3.x admin panels. It lets non-technical staff publish formatted content without engineering tickets and avoids weeks of custom editor work. But it is a tactical buy, not a strategic platform bet: the wrapper is archived, the editor is commercially licensed by domain, and the integration has no support path. Approve it only for internal, low-risk admin screens, with a named owner, a Froala license budget, server-side sanitization, and a documented exit plan. If the Nova 4+ upgrade is scheduled or the content is public-facing, replace the editor rather than adopt this package.

For engineering: Treat it as a thin Nova Field subclass that hands a PHP options array to a compiled Vue 2 component. Keep all configuration in one subclassed field, not repeated ->options([...]) arrays. Store plain HTML in longText — that is the cheap-exit property — and prove the round trip before building more. Sanitize at the write boundary, build your own upload endpoint returning { "link": ... }, send CSRF via requestHeaders, validate MIME/size, and prefer upload URLs over base64 paste. Pin everything, feature-flag the field with a native Textarea fallback, and do not let it become load-bearing. If you need custom JS callbacks or a patched editor build, budget for forking the Vue component or replacing the editor outright.

Bottom line: Use this package as a short-term admin convenience for Nova 3.x internal tools where the license is approved and the content risk is contained. Do not pitch it as a maintained rich-text platform, and do not adopt it for new builds, Nova 4+, or any surface where unsanitized HTML or an unpatched editor would be a business risk.