Nova Froala Editor Laravel Package

Getting Started

Start by checking the package’s composer.json for Nova and Laravel version constraints, then install it with Composer:

composer require <vendor>/<package>

Look first at:

1. The package README for the exact field class namespace and required publish steps.
2. config/ for editor defaults, upload disk/path settings, and asset configuration.
3. resources/js/ to confirm how the Vue field component is registered.
4. src/ for the Nova field class and any upload/request handling.

Publish any config or assets if the README instructs it:

php artisan vendor:publish --provider="<Vendor>\\<Package>\\<Provider>"

The first practical use case is replacing a plain Nova Textarea with a rich-text field for a blog post, page, or product description:

use Vendor\Package\Froala;

public function fields(Request $request)
{
    return [
        Froala::make('Content')
            ->rules('required')
            ->help('Rich text content for the public page.'),
    ];
}

After registering the field, open the Nova create/edit form and confirm the editor loads, toolbar buttons work, and content is saved and reloaded correctly. If the editor does not appear, check browser console errors and whether the package assets were published/loaded.

Implementation Patterns

Basic resource integration

Use the field like any other Nova field. Keep the field name aligned with the model attribute:

Froala::make('Body')
    ->rules('required', 'max:50000')
    ->placeholder('Write the article body...')

Toolbar and editor configuration

Most Froala wrappers expose an options array or fluent methods. Prefer configuring only what you need per field rather than changing global defaults:

Froala::make('Content')
    ->options([
        'toolbarButtons' => ['bold', 'italic', 'underline', '|', 'formatOL', 'formatUL', '|', 'link'],
        'heightMin' => 300,
    ])

If the package supports global config, put shared defaults in config/froala.php or the package config file and override per field only where necessary.

Image and file uploads

Rich-text fields often need upload handling. Check whether the package provides a built-in upload endpoint or expects you to configure Froala’s imageUploadURL. If built in:

• Configure the disk and upload path in the package config.
• Restrict accepted MIME types and maximum file size.
• Store uploads outside executable/public script paths where possible.
• Return the expected JSON shape from the upload endpoint.

If not built in, add a small authenticated Nova route or controller and point the editor options at it. Validate every upload server-side; never rely on the editor’s client-side filters.

Displaying content outside Nova

Store HTML as-is only if you trust the authors and sanitize on output. A common pattern is to sanitize before saving or before rendering:

$post->content = strip_tags($request->input('content'), '<p><br><strong><em><ul><ol><li><a>');

Alternatively, use an HTML sanitizer package and render sanitized HTML in Blade with {!! $sanitized !!} only after sanitization. Do not use raw {!! !!} on unsanitized editor output.

Index and detail screens

Rich text is usually too large for Nova index tables. Use onlyOnForms() or hideFromIndex(), and show a short excerpt instead:

Froala::make('Content')
    ->onlyOnForms(),

Text::make('Excerpt', function () {
    return Str::limit(strip_tags($this->content), 80);
})->onlyOnIndex(),

Validation and model events

Treat the editor as a normal form input for validation. If you normalize HTML, do it in a form request, model mutator, or Nova field fillUsing/resolveUsing hook rather than in the Vue component.

Testing workflow

For feature tests, submit the field name as a normal request parameter. For browser tests, be aware that Froala uses contenteditable/iframe structures, so interacting with it may require editor-specific selectors or setting the underlying value through JavaScript.

Gotchas and Tips

• Froala licensing: Froala is a commercial editor. Confirm the package’s license expectations and whether your use requires a Froala license. Do not assume the Laravel package includes an editor license.
• Asset publishing: The editor often fails silently or renders a plain textarea if CSS/JS assets are missing. Re-run the package’s publish command after upgrades and clear caches.
• Nova compatibility: This is a Nova field package, so Nova major-version compatibility matters more than Laravel compatibility alone. Check the release constraints before upgrading Nova.
• Hidden/conditional fields: Editors inside hidden tabs or conditionally displayed fields may initialize with the wrong size or not at all. Trigger a Froala refresh/resize when the field becomes visible if the package does not handle it.
• HTML sanitization: Rich text is an XSS risk. Sanitize on save or render, especially if non-admin users can access Nova or if content is displayed publicly.
• Upload security: Validate file type, size, and extension server-side. Avoid trusting the editor’s accepted-file settings. Consider randomized filenames and private storage plus signed URLs for sensitive content.
• Large content payloads: Very large HTML documents can slow Nova forms and requests. Set validation limits and consider a separate detail/edit screen for huge documents.
• Config caching: If the package reads config at runtime, run php artisan config:clear after changing upload or editor settings during development.
• Upgrade path: This is a 1.0 release with brief notes. Pin the version in composer.json, review the package changelog/source diff before upgrading, and test editor initialization, uploads, and saved HTML round-tripping.
• Debugging checklist: Check browser console for missing assets, inspect network requests for upload failures, confirm the field class resolves to the package component, and verify the model attribute is actually being saved.
• Extension points: Prefer the package’s config and field option methods first. If you need deeper changes, inspect the published Vue component and field class before forking; overriding the component may be cleaner than modifying vendor files.