Filament Advanced Rich Editor Laravel Package

Product Decisions This Supports

• Build vs. buy on the authoring surface. The editor is a feature every content-driven product ends up rebuilding; this package collapses that work into a configuration task. It's the cheapest way to test whether richer authoring actually moves activation or content throughput before committing engineering to a bespoke editor — and v1.7.0 widens the surface you get to test with (glossaries, invisible-character and block-outline views) without adding build cost.
• Roadmap sequencing. Feature parity items that would otherwise each be their own ticket — callouts, find & replace, slash menu, browser drafts, media browsing, definition lists, invisible-character inspection — arrive as one dependency. That frees a release cycle for differentiators instead of table-stakes editing UX.
• Scaling authoring to heavy admin pages. v1.7.0 is largely a performance release, and it changes where this package is safe to deploy. Twenty editors in a repeater now reach first frame in 3.6s instead of 5.1s; five editors went from 430ms to 172ms server-side and from 355ms of long tasks to none. Editing UIs that embed an editor per row, per block, or per translation locale — previously a reason to limit adoption to one editor per page — are now viable. Treat this as the release that unlocks repeater and multi-locale layouts, not just a polish pass.
• International and regional rollout. Ten more languages (Czech, Danish, Dutch, French, Italian, Norwegian Bokmål, Polish, Brazilian Portuguese, Spanish, Swedish) alongside English and German, plus accent-insensitive slash-menu search (/enum finds énumération). This turns localization from "we'll ship English UI and hope" into something you can put in front of regional editorial teams. The caveat is explicit and belongs in the decision: the new translations are AI-generated, only English and German have had a native speaker read them. Plan for native review before an editorial team depends on the chrome.
• Role- and tenant-specific authoring. A toolbar you arrange yourself is a permissions/product lever, not cosmetics: give marketers the full set, give junior or regional editors a reduced set, ship different toolbars per panel or plan tier without branching code. New toggles (invisibles, descriptionList) follow the same pattern — capability flags, not forks.
• Content operations and asset governance. Replace-in-place that preserves the file's id means one price list, policy PDF, or brand asset is updated once and every document referencing it re-renders correctly — no per-page relinking, no stale copies. Delete and replace dialogs that name affected entries turn a silent breakage risk into a reviewable decision. This is a real answer to "who changed the logo on 40 pages?"
• Editorial QA and content review. "Show invisible characters" and "Show blocks" give reviewers a Word-style ¶ view and named block elements (P, H2, LI) without touching the stored HTML, clipboard, or undo history. That's a support-and-training lever for non-technical authors and a debugging lever for whoever owns the content model — cheap to ship, and it reduces "why does this paragraph look wrong" tickets.
• Content modeling for structured reference material. Definition lists (<dl>/<dt>/<dd>, /glossary, Markdown round-trip, off by default) let glossaries, spec sheets, and term/definition content be modeled properly instead of faked as bolded bullets. Relevant if you're deciding whether your CMS can hold reference content — but it's a per-field opt-in and a published config must be re-published to see the new key.
• Compliance roadmap. A built-in accessibility check lowers WCAG/ADA/EU Accessibility Act exposure and shortens security-and-compliance questionnaires in public-sector and enterprise procurement. Treat it as risk reduction, not a guarantee — it's a lint, not an audit.
• Editor resilience and support cost. Browser-side drafts reduce lost-work tickets and abandonment on long-form authoring, which is disproportionately expensive for editorial teams.
• Migration and content hygiene. Find & replace supports rebrands, terminology changes, and post-migration cleanup without one-off scripts or DBA time.
• Activation and onboarding. Slash menu plus callouts let non-technical authors produce structured content without knowing markup — fewer training hours and a faster path to first published page.

When to Consider This Package

Good fit when:

• You are already on Filament v5 and the editor lives inside an admin/back-office panel, not a customer-facing surface you'll need to theme from scratch. v1.7.0 includes fixes for Filament 5.10 behaviour (toolbar pickers and dropdowns), which reinforces that the package tracks the framework closely — and that your version pair matters.
• You need many editors on one page: repeaters, block builders, per-locale tabs. The v1.7.0 performance work is aimed squarely at that case and is the strongest single argument in this release for adoption.
• The team is PHP-first with no appetite for owning a ProseMirror/TipTap front-end build.
• You specifically need the bundle — media library, accessibility check, drafts, slash menu, find & replace, glossary, editorial inspection views — rather than just bold and italic.
• Your editors work in non-English locales and you can absorb a native-review pass on the AI-generated translations before relying on them.
• Spatie Media Library is (or can be) your asset layer, so the attachment integration is upside rather than a coupling you'd fight.
• You can treat it as a vendored dependency: pin the version, wrap it behind your own field abstraction, keep contract tests on the stored HTML.

Look elsewhere when:

• You're not on Filament v5, or you're hedging toward a different admin stack — this is a deep, framework-specific bet.
• You need real-time co-editing, inline comments, or version history with audit trails. Still out of scope; nothing in this release changes that.
• You require vendor SLA, indemnification, or a support contract, or your dependency review demands a maintainer base larger than one person.
• Your content model depends on a custom node schema or a strict document tree you need to own end-to-end — the package's stored-HTML rewriting behavior becomes something you work around, not with.
• A hosted editor (Tiptap Cloud, CKEditor) is cheaper than the maintenance you'd absorb.

Operational note for adopters (new in v1.7.0): assets are now split into two stylesheets — filament-advanced-rich-editor.css on every panel page and filament-advanced-rich-editor-overlays.css loaded on demand via x-load-css. The overlays sheet must be published: php artisan filament:assets is now mandatory after every update, and skipping it renders pickers, menus and dialogs unstyled. Several scripts (menu-position.js, image-panel.js, color-picker.js, font-size-picker.js, and the new invisibles script) are now Alpine components loaded at runtime. Put the publish step in your deploy pipeline and in your upgrade runbook, and budget a smoke test of the overlay UI after each bump. Published config files also need re-publishing to receive the new invisibles key and the fourth lists entry.

Honest read on the signal: still a young, single-maintainer, MIT-licensed package with negligible adoption evidence. What v1.7.0 changes is the quality of that signal: this is a dense, self-aware release — real profiling numbers, an explicit fix for a current framework version, and a changelog that tells you what it broke and how to recover. That's a meaningfully better maintenance signal than a feature-drop, and it should raise your confidence in the fork path. It doesn't change the structural risk. Price it as a tactical adoption with a fork budget, not a strategic platform dependency, and assume you may be the one fixing it.

How to Pitch It (Stakeholders)

To executives: We can deliver a modern, Notion-class authoring experience — self-arranged toolbars, slash commands, media browsing, accessibility checking, autosaved drafts, glossary support, and twelve-language UI — in one integration instead of a multi-sprint build. It's MIT-licensed, so there's no per-seat cost and no lock-in. The latest release also removes the performance ceiling that would have forced us to limit editors to one per page: pages with twenty embedded editors now render roughly a third faster, and the whole stylesheet payload dropped from 128 KB to 80 KB on pages that don't use an editor. The honest caveats: it's an early-stage open-source project with a single maintainer, and the newly added translations are machine-generated and not yet native-reviewed. So we adopt it deliberately: pinned version, isolated behind our own interface, a deploy step to publish its assets, a review pass on translations for any non-English team, and an escape hatch back to the stock editor. Downside risk is bounded to a few days of engineering; upside is a release cycle of editor work we don't have to staff.

To engineering: Drop-in replacement for Filament v5's RichEditor — PHP configuration, no JS build pipeline to own, no new runtime services. Media handling rides on Spatie Media Library where present. What changed in v1.7.0 and what you should review before committing: styles are split into a base sheet plus a lazy-loaded overlays sheet, and per-widget scripts are now Alpine components loaded via x-load-src/x-load-css — so the upgrade path includes php artisan filament:assets and a config re-publish for published configs. Performance work targets per-editor hot paths (:has() scoping, deferred font-size measurement, one menu-position.js instead of one per menu), so repeater and multi-locale layouts are now in scope. The parts still worth owning tests on: how it persists and rewrites stored HTML (including the new <dl> round-trip and Markdown serialization), the replace/delete fan-out to referencing documents, and the extension points (MediaSource, ReplacesMedia) if we plug in our own asset pool. Note that picker behaviour is now tested as JavaScript rather than asserted as strings in PHP — our smoke tests should exercise the overlays, not just the field.

The ask: a short timeboxed spike to validate fit against our content model — including a repeater page and one non-English locale — then adoption behind an abstraction layer with a pinned version, a documented asset-publish step, and a documented fork path.