Weave Code
Nova Froala Field Laravel Package
pathfindermediagroup/nova-froala-field
A Laravel Nova field that integrates the Froala WYSIWYG editor for rich text content. It provides an easy-to-use, configurable editing experience for creating and managing formatted HTML in Nova resources.
A Laravel Nova Froala WYSIWYG Editor Field.
Frequently asked questions about Nova Froala Field
- How do I install pathfindermediagroup/nova-froala-field in a Laravel Nova application?
- Install it with Composer using composer require pathfindermediagroup/nova-froala-field inside a Laravel app that already has Nova installed, then publish the package config and assets with php artisan vendor:publish. The package registers itself through Laravel package auto-discovery, so no manual service provider entry is normally required. After publishing, reference the field in your Nova resource and render it in the form. Check the repository README for the exact publish tags and field namespace before wiring it in.
- Which Laravel and Nova versions does this Froala field support?
- Because this is a Nova presentation-layer field, support is bounded by your Nova major version and the PHP and Laravel versions that Nova itself requires. Laravel 9 through 11 on PHP 8.x is the realistic range for current Nova releases, but verify the composer.json constraints in the repository rather than assuming. The Nova major version matters more than the Laravel minor version, since Froala ships as a bundled front-end dependency. Test against your actual Nova release before rolling it out.
- Do I need a paid Froala license to use this package?
- Yes, in practice. This package is an open-source wrapper; the Froala editor it loads is commercial software with its own licensing terms. You need a license tier that covers every domain and environment where the editor runs, including staging, subdomains, and any multi-tenant domains. Licensing is the most common reason teams reject this package, so confirm coverage with procurement before writing code.
- How do I customize the Froala toolbar and editor options in Nova?
- Publishing the package config gives you a place to set the options passed to Froala when the field renders, including toolbar buttons, plugins, and height. Froala 4.x renamed several 3.x option keys, so confirm the shipped config uses 4.x names and that any plugin you enable is actually bundled. Keep the toolbar minimal for your authors and version the config file so changes are reviewable. Verify option behavior against the upstream Froala 4 documentation.
- Is content saved by this Froala field safe from XSS?
- Not by itself. The editor produces attacker-controlled HTML, and client-side editor configuration is not a security control. Sanitize on the server at the point of persistence and again at render using an allowlist-based HTML sanitizer, and escape anything that is not intentionally rich text. Treat stored editor output exactly as you would treat any other untrusted user input.
- How should I handle image uploads with this Nova Froala field?
- The wrapper relies on an upload endpoint that Froala calls when an author inserts an image, so you own the route, storage, and validation. Put the endpoint behind Nova's auth middleware, validate MIME type by sniffing file contents rather than trusting the extension, cap file size, and store uploads outside the public web root or on an isolated disk. Decide whether uploads are served directly or through signed URLs. Never ship a demo upload route to production.
- Should I load the Froala assets from a CDN or publish them locally?
- Both work, but they have different operational consequences. A CDN keeps your build small but requires CSP allowlisting for that origin and rules out air-gapped or offline deployments. Publishing assets into your build keeps CSP tighter and helps guarantee the deployed editor matches the Composer-installed version, but you must remember to republish after every upgrade. Record the decision along with the CSP changes it implies.
- Does the package version track the bundled Froala editor version?
- No. The wrapper's semver tracks the package itself, not the editor, so a patch release like 4.0.5 can bump Froala under the hood without signalling an editor upgrade in the version number. In this case 4.0.5 moved Froala to 4.0.14 with a one-line release note and no API changes indicated. If you need to patch the editor independently of the wrapper, check whether froala/wysiwyg-editor is pinned in composer.json or whether the assets are vendored. Pin exact versions and read the upstream Froala changelog whenever releases land.
- Can I use this field with Inertia, Vue, or React instead of Blade?
- This is a Nova field, so it is designed for Nova's own admin UI rather than as a general-purpose editor component for Inertia, Vue, or React front ends. For headless or SPA applications, a native editor component on the front end avoids a PHP-side wrapper entirely. If your authors work inside Nova, the Blade-based integration is the intended path. Confirm how your Nova version initialises custom fields before assuming bundler-based init is supported.
- How does this compare to TinyMCE or CKEditor fields in Nova, and what does switching involve?
- All three wrap a rich text editor into a Nova field, so the decision comes down to licensing, bundle weight, and the sanitization and upload work you still own. Froala is commercial, which is the biggest differentiator, while TinyMCE and CKEditor have their own license terms you should read the same way. Content stays as HTML in existing columns, so there is no data migration, but budget a content QA pass because a new editor normalizes markup differently and will rewrite existing content on first save. Run the new field behind a feature flag alongside the incumbent editor before switching everything over.
Weaver
How can I help you explore Laravel packages today?