Filament Rich Editor Extra Laravel Package

Getting Started

mohamedsabil83/filament-rich-editor-extra is a companion package for Filament's RichEditor field: it ships extra TipTap extensions you attach to the editor so you get behaviour Filament doesn't bundle (mentions, rich media rendering, and — as of v1.4.0 — fullscreen mode and a sticky toolbar).

Minimal path from zero to a visible result:

composer require mohamedsabil83/filament-rich-editor-extra

1. Confirm the Filament version constraint in composer.json output — this package tracks Filament v3's TipTap build, so it must match your panel's major version.
2. Publish/refresh front-end assets after install and after every update (Filament plugin assets are copied, not served from vendor/ in all setups):

php artisan filament:assets
php artisan optimize:clear

3. Find the extension list first: open vendor/mohamedsabil83/filament-rich-editor-extra/src/Extensions/ — the class names there are the authoritative list of what you can attach, and the README shows the fluent make() signature for each.
4. Apply one extension to one field and load the page in the browser before doing anything else:

use Filament\Forms\Components\RichEditor;
use Mohamedsabil83\FilamentRichEditorExtra\Extensions\Fullscreen;

RichEditor::make('content')
    ->extensions([
        Fullscreen::make(),
    ]);

First real use case: a CMS/blog "body" field where editors write long content. Pair StickyToolbar + Fullscreen there — it's the highest-value, lowest-risk adoption, because both extensions are purely UI chrome and cannot alter stored HTML.

Implementation Patterns

Attach per field when behaviour should differ. Keep the extension array explicit on the component so a reader of the form class knows exactly what the editor can do:

RichEditor::make('body')
    ->extensions([
        StickyToolbar::make(),
        Fullscreen::make(),
    ])
    ->toolbarButtons([...])

Attach globally when it's a house style. Sticky toolbars and fullscreen are "every editor should feel like this" features, not per-model decisions. Register once in a service provider (AppServiceProvider::boot() or a dedicated FilamentServiceProvider) rather than editing dozens of resources:

use Filament\Forms\Components\RichEditor;

RichEditor::configureUsing(function (RichEditor $editor): void {
    $editor->extensions([
        StickyToolbar::make(),
        Fullscreen::make(),
    ]);
});

This is the pattern to reach for in an existing app: one diff, every rich editor upgraded.

Compose extensions per content type. A short "summary" field rarely needs fullscreen; a long-form article field needs both new extensions plus media handling. Split into small factory methods or a custom App\Filament\Fields\ArticleEditor component that returns a pre-configured RichEditor, so the composition lives in one place and forms stay readable.

Toolbar integration. The new extensions surface as toolbar buttons. If a button doesn't appear, the usual cause is a ->toolbarButtons([...]) whitelist or ->disableToolbarButtons([...]) on the same field — the explicit whitelist wins over extension-registered buttons. Decide one source of truth: either let the extension add its button, or list it yourself, but don't do both half-way.

Front-end rendering. Extensions change what the editor emits; they don't style your public pages. Render stored content through Filament's RichContentRenderer (or {!! $model->body !!}) and make sure the CSS for the emitted nodes — including anything the media extension produces — is present in your front-end build, not just in the panel.

Testing split. Fullscreen and sticky toolbar are JavaScript-only. Livewire/Pest form tests can only assert the schema (field exists, extensions attached); the actual button behaviour needs a browser check (Dusk, or a manual pass on the review checklist). Don't write a Livewire test asserting "fullscreen works" — it will pass while the feature is broken.

Upgrade routine. Because this package ships JS, treat composer update as a two-step deploy: bump the package, run php artisan filament:assets, then smoke-test one editor in staging. Add that to the release checklist next to optimize:clear.

Gotchas and Tips

• Stale assets are the #1 false alarm. After upgrading to v1.4.0 the new buttons often don't show because the previously published asset bundle is still cached. php artisan filament:assets + php artisan optimize:clear + hard browser reload, in that order, before debugging anything else.
• Sticky toolbar needs a scroll ancestor. position: sticky sticks relative to the nearest scrolling container. Inside a Filament modal, a Section/Tabs wrapper with overflow-hidden, or a custom max-h-* overflow-y-auto panel, the toolbar may appear to do nothing. Test in the exact context (page vs. modal vs. slide-over) where editors will use it.
• Fullscreen inside modals fights with z-index and body scroll. An action modal that already locks scroll can leave the fullscreen editor clipped or unscrollable. Prefer fullscreen on full-page resources (Create/Edit pages); if you need it in a modal, verify Escape exits cleanly and the modal footer stays reachable.
• Custom Filament themes. If you build a custom theme, the extension's markup may need its styles imported/purged correctly; a "toolbar renders unstyled" report almost always means the theme's CSS entrypoint is missing the panel's views/safelist.
• TipTap major-version coupling. Extensions bind to Filament's bundled TipTap version. A Filament major upgrade can break every extension in the array at once — symptom is a blank editor or a console error about duplicate/incompatible extension names. Pin the package version alongside Filament and upgrade them together.
• Duplicate-extension warnings. If you register an extension globally and per field, or the package already includes something Filament now bundles natively, the browser console shows a duplicate-extension warning and behaviour gets flaky. Check the console first; it names the offender.
• Silent no-ops. ->extensions([...]) with a class the asset bundle doesn't know about just does nothing — no PHP exception. If a feature is missing, confirm the class exists in src/Extensions for your installed version (composer show mohamedsabil83/filament-rich-editor-extra) before assuming a config problem.
• Upgrading 1.3.1 → 1.4.0 is additive and safe. Two new extensions, no removals or signature changes noted; the only real risk is asset staleness on deploy. No migration or config change required.
• Media extensions are the ones with a security surface. Fullscreen/sticky toolbar are inert UI, but anything that lets users embed images/files needs the attachment disk/directory/visibility configured deliberately (private disk for internal docs, public for marketing pages) and output sanitised on the front end — never {!! !!} raw editor HTML from untrusted authors.
• Extension ordering matters for TipTap extensions that hook the same node or keymap. If two extensions misbehave together, reorder the array before assuming incompatibility — and isolate by attaching only the suspect extension to a scratch field.
• Debugging ladder: (1) browser console, (2) confirm installed version + assets re-published, (3) reduce the field to a single extension, (4) reproduce outside the modal/tab wrapper, (5) check the toolbar whitelist. That sequence resolves nearly every report against this package.