Filament Tinyeditor Laravel Package

Product Decisions This Supports

• Build vs. buy for rich text. Rich text editing is a commodity; nobody should be writing a WYSIWYG from scratch. This package is the "buy" option for teams that specifically want TinyMCE inside Filament, at roughly one composer line and a few Artisan publish commands. It is not the default choice — Filament ships its own first-party RichEditor — so the decision this really supports is "TinyMCE or the built-in editor?", not "editor or no editor."
• Feature justification for switching off the default. The defensible reasons to adopt: Word/Google Docs paste fidelity, heavy table editing, content templates, TinyMCE's third-party plugin ecosystem (external_plugins config), and RTL/ multilingual authoring (->rtl(), ->direction('auto|rtl|ltr')). If none of those appear in your interview notes or support tickets, you have no case to switch.
• Roadmap: RTL and non-Latin market entry. Direction is a per-field method and a config key, not a custom build. That turns "support Arabic/Hebrew/Urdu authoring" from a multi-sprint initiative into a checkbox — useful for prioritization conversations.
• Role-based authoring UX via profiles. Four built-in toolbars (default, simple, full, minimal) plus custom and none let you ship a reduced toolbar to marketers and a full one to editors, per form, without a fork. That's a cheap lever for reducing support tickets and accidental formatting damage.
• Media and storage architecture. fileAttachmentsDisk, fileAttachmentsVisibility, and fileAttachmentsDirectory force an explicit decision on where author-uploaded images land (public disk vs. S3 vs. CDN, private vs. public ACL). That's a compliance, cost, and CDN decision worth capturing in the ADR rather than letting it default.
• Platform upgrade planning. The package maintains parallel branches mapped to Filament majors (3.x→Laravel 10+/PHP 8.1+, 4.x→Laravel 11/PHP 8.2+, 5.x→Laravel 12/PHP 8.2+). That gives you a concrete upgrade path when Filament bumps — but it also means the dependency's release schedule becomes a milestone in your upgrade plan.
• Migration of an existing HTML corpus. If you're porting content authored in a previous TinyMCE instance, matching the editor reduces round-trip sanitization surprises versus re-editing in a TipTap-based editor.

When to Consider This Package

Consider it when:

• Your team or content authors have already standardized on TinyMCE and would otherwise lose muscle memory or stored content fidelity.
• Requirements include Word paste, complex tables, content templates, or a TinyMCE plugin you specifically need.
• You need per-form toolbar profiles and RTL support without custom front-end work.
• You're on Filament 3.x, 4.x, or 5.x with a matching Laravel/PHP line, and can pin to the corresponding package major.
• You have an owner — one engineer who will track upstream releases and take a patch — and a one-line abstraction layer (your own RichText field class) so a swap back to Filament's RichEditor is a single-file change.

Look elsewhere (or use Filament's built-in RichEditor) when:

• Requirements are "bold, italic, links, lists, images." The first-party editor covers this with zero third-party risk.
• Procurement or security requires a supported vendor, an SLA, or an SBOM you can defend. Signals here are thin: ~109 stars, 0 dependents, a single maintainer, and a repo whose published maturity signals are readme + releases only — no evidence of a test suite or security policy. That's a bus-factor and supply-chain conversation, not a code-quality one.
• Licensing matters to your distribution model. The MIT license covers this wrapper, not the editor assets it loads. TinyMCE's community-edition licensing has shifted across major versions, and the package also supports Tiny Cloud / API-key and self-hosted asset modes. Have legal confirm the upstream terms for the specific TinyMCE version you'll ship before it lands in a distributed or on-prem product.
• You need real-time collaborative editing — that's an upstream paid-tier capability, not something this wrapper delivers.
• You're mid-freeze on a Filament upgrade and can't absorb a third-party dependency's release cadence into the critical path.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free, MIT-licensed adapter that puts a professional-grade text editor (TinyMCE) into our admin panel instead of the one that comes with our framework. Cost is roughly a day of engineering, no new infrastructure, and no schema changes. The strategic value is that it unlocks Word-paste fidelity, table editing, and right-to-left authoring — the last of which is a prerequisite for the non-English markets on the roadmap. The honest caveat: it's a single-maintainer open-source project with a thin adoption base, so we treat it as a swappable component behind our own interface, not as foundational infrastructure. Exit cost if we abandon it: one file.

For engineering (the real pitch):

• Zero-friction integration. TinyEditor::make('content') extends Filament's Field class, so ->required(), ->columnSpan('full'), validation, and the rest of the familiar API keep working. Config and views are publishable, so behavior is tunable without forking.
• Bounded surface area. Storage is explicit (fileAttachmentsDisk / Visibility / Directory); direction is explicit (->rtl() / ->direction()); toolbars are declared profiles with pipe-separated groups. There's little hidden magic to reverse-engineer.
• Version discipline required. Pin to the package major matching our Filament major (3/4/5), publish assets in deploy, and add the config file to review so profile and external_plugins changes are visible in diffs — external_plugins loads third-party JS from URLs, which is a real CSP and supply-chain surface that should not be freely editable.
• Known unknowns to verify before the spike closes. Confirm the TinyMCE upstream license for the version we pin, confirm whether we self-host assets or need a cloud key, and confirm the editor behaves inside Filament modals (historically a rough edge in this package's changelog) and on Livewire re-renders/sortable reorders (also a past bug class — content loss on reorder). Test both explicitly.
• Timebox it. A one-to-two-day spike against one real form, wrapped in our own RichText field, answers build-vs-buy definitively and leaves us with a cheap reversal if it doesn't hold up.